zhanglin999's Posts

Hi, Jay, We have heard similar issue recently, and suspect that it may be related to different CPU models of Apple Silicon, so it would be helpful if you can share more details about your CPU and GPU, because MacBook Pro 14 inch, 2023 has 2 CPU types.  Also you can try this workaround to see if it works in your case: Open terminal from /Applications/Utilities/Terminal.app or /System/Applications/Utilities/Terminal.app Run "defaults write com.vmware.horizon kDisableMetal YES" in terminal Re-launch Horizon Client to see if the issue still happen. --zhanglin

Hi Michiel, I think we find possible root cause from code. In some special environment, the mouse scroll event is sent to out window of remote desktop, which cause the remote desktop is un-grabbed. I attached a vmware-remotemks which can fix the problem.  I attached it here because I think there may be other people encounter same issue so they can try this fix too. You can rename the vmware-remotemks.exe in [INSTALL_DIR]\x64 and copy attached vmware-remotemks.exe to same folder. The default location should be "C:\Program Files (x86)\VMware\VMware Horizon View Client\x64" if you don't change the install directory. --zhanglin

Hi, Michiel, Thanks for your clarification. Then I think the fact should be: SOME THING causes the remote desktop un-grabbed while mouse move, but I don't know what's it now. My colleague and I spend several hours to duplicate this issue but no luck. I will try to see if I can find any clue from code level.  Also we can try to give you a build with more debug information so that we can get more information about issue, do you want to try it? --zhanglin

Hi, Michiel, Thanks very much for your detailed investigation. From your description, it seems a native application(Google Chrome on your Win10 Pro 2004) steal focus from the Horizon vdi desktop window while scrolling, so the vdi desktop window is un-grabbed. Yes, this can explain why the content scroll one time( because the first move event is sent to vdi desktop) and then stop( because the vdi desktop is un-grabbed, so mouse event is not sent to vdi desktop). If you keep moving the mouse inside the vdi desktop, the vdi desktop will try to grab again and again, so the scroll mouse event can be sent to vdi desktop and you can see the scroll can work in this scenario. The interesting things is: 1. I guess native Google Chrome wants to be focused because it gets scroll event, so why it gets scroll event if vdi desktop is front most, it's strange. And it doesn't steal focus from Windows Server 2008R2, hmm, weird. 2. Do you install url redirection on your Window Server 2019? Not sure this can affect the native Google Chrome's behavior. 3. Another point is, if the native Google Chrome isn't launched, can the scroll work? --zhanglin

Hi, Michiel, We try to duplicate this issue in lab, but no luck. Could you provide more details to help us identify the issue? 1. Are you using a desktop or remote application? 2. If it's a desktop, what's the application you try to scroll in it? If it's a remote application, what it is? 3. What's the protocol you are using, PCoIP or Blast or RDP? 4. I try to describe the step to duplicate the issue, please correct me if it's not same with your step exactly. 4.1 Move the mouse to desktop or remote application. 4.2 Is there any mouse click happen? (If you click here, does scroll work in next step?) 4.3 Scroll the mouse button, nothing happen. 4.4 Move mouse, the scroll happens. 4.5 What happen if you scroll again here? --zhanglin

Hi, solgae, Thanks for your log, developer team have found some clue about this issue, but we still need your help to confirm something: 1. Which type of network interface you used on your macbook air? wireless or usb ethernet adapter? Can this issue be reproduced on both type of network? 2. Could you provide the log when VMware View Client works well? Per the post before, I think only the version 2.0 works, right? If so, please provide the log of 2.0 client. Thanks very much. zhanglin

Hi, solgae, Developer team had analyzed the logs carefully and found the vmware-remotemks process exit unexpectedly so that it cause view client crashed, but team cannot reproduce this issue in local env and there is no rmks log in provided log, so it's very hard to dig out what's the root cause. Could you kindly help us to do some verify step and collect log again when this issue reproduced? Thanks in advance. 1. Please clean the log directory "~/Library/Logs/VMware/" and "~/Library/Logs/VMware Horizon View Client/" first. 2. Please make sure there is no zombie process with name "vmware-remotemks" before launching view client. 3. Add following two lines into "~/Library/Preferences/VMware Fusion/config", if this file doesn't exist, you can create it by yourself: log.stderrMinLevel = 145 log.logMinLevel = 145 4. When view client crashed, run "ps -ef | grep vmware-remotemks" to verify the rmks process status and paste output here. 5. Attached the log files in  "~/Library/Logs/VMware/" and  "~/Library/Logs/VMware Horizon View Client/"