banackm's Posts

The same fix that was in the Technology Preview also shipped in Workstation 14.1.3 today.  So if you upgrade to that build, and set the config option, that seems to resolve some of these issues. We're continuing to work on a more comprehensive solution that can be on by default, and catch the remaining cases.

One easy work-around here, is that if you disable 3D graphics in your guest, the crash will probably go away.  (If a no-3D guest is still usable for you.) You might also try the Workstation Technology Preview 2018 , which I believe has some improvements in this area that may or may not help.

We have some changes in the "VMware Workstation Technology Preview 2018" that have helped some of these mouse cases internally. If you run that build, and set the config option: mks.win32.processWin32MouseInput=TRUE The fix unfortunately breaks Drag and Drop out of the guest so it's not on by default yet, but we're still working on the problems. We would be very curious which of the problems people are hitting that are/aren't fixed by that option.

You might try launching SnagIt as an Administrator, and I suspect that will avoid the problem. Otherwise, Windows is skipping the SnagIt hook before we're even involved, due to some changes in our hypervisor between WS 12 and WS 14.  I don't think we can change that in the near future without causing other more serious issues.

The WS14 changes were unfortunately made to prevent other more serious issues, which is why this has been so difficult for us to try and unravel. There are a couple different variants of this that we've identified (as far as what the 3rd-party software is doing) some of which we've managed to reproduce internally, and they're quite possibly going to require separate fixes on our end. But the screen-overlay/screen-capture angle is entirely new to us, and honestly more alarming than the previous interactions with 3rd-party mouse software we identified.

I mean, there's two concurrent goals here: fixing Workstation, and helping users find an immediate work-around. We're aware of an entire class of related issues, that seem to be triggered by some changes in WS 14, and are working towards fixing them. But it's also clear that not all users are hitting the exact same issue.  So if any of the immediate work-arounds are useful (like disabling 3D, launching WS or 3rd-party applications as Administrator, or exiting 3rd party applications), we'd love to know, because it will help us narrow down how many different specific issues there are, what might be affecting them, and what other users might want to try if they run into one of these issues. On the fixing Workstation front, I don't think anyone is blaming the 3rd-party mouse or screen-capture software.  It just happens that they way they work is interfering with the way Workstation gets mouse input, and we're working on finding a way to resolve that.

Is the issue that the mouse-clicks stop, or that the entire guest console display freezes?  Like, can you still see things updating on the guest screen in the local window when this occurs? If you see a total screen freeze, does it still happen if you disable 3D on your VM?  (You'll have to do a full VM PowerOff/PowerOn for that to take effect, suspend/resume or rebooting is not sufficient.) We've been chasing this as a mouse issue in line with some of our other mouse issues, but it's possible some of you are actually running into a graphics problem.  Because Fraps and other screen capture/overlay software don't normally do much to the mouse stack, but do interfere with the graphics side of things.

I don't believe there is any UI for that, but you can hard-code the "Gaming Mouse" setting on a per-VM basis by setting config options in your vmx file.  These will override the UI policy for gaming mouse, and can force the motion grab/ungrab support to be disabled. The "mks.gamingMouse.policy" vmx-file entry will override the UI's "Gaming Mouse" policy, and can be set to any of the following: # Equivalent to "Automatic" in the UI mks.gamingMouse.policy = "dynamic" # Equivalent to "Always" in the UI mks.gamingMouse.policy = "gaming" # Equivalent to "Never" in the UI mks.gamingMouse.policy = "absolute" # Doesn't have a UI equivalent, but disables motion grab/ungrab while keeping the accelerated cursor (like "Never") mks.gamingMouse.policy = "absgaming" # Doesn't have a UI equivalent, but forces the unaccelerated mouse (like "Always") without disabling motion grab/ungrab mks.gamingMouse.policy = "relative" So, if you turn motion grab/ungrab on in the UI, you can set the gaming mouse in each of your VMs with that setting to do what you want.  Or if you have VMs that you still need to be able to toggle the "Gaming Mouse" state (ie for application compatibility) you can leave them with no extra config settings and the global UI "Gaming Mouse" state will keep working.

One other idea that came up, is that you might also try making the VM a "Shared VM" and run that and connect a console to it (with no other VMs running on the system). Although I think that loses some features in the VM (like 3D graphics support).

You might try enabling or disabling the "MacOS Shortcuts" option. (I think these instructions are still accurate: VMware Fusion 7 Documentation Center  ) In some cases that option will change our keyboard handling path enough that it might perturb this, particularly for key-combinations involving Ctrl/Alt or the function keys.

You might try enabling or disabling the "MacOS Shortcuts" option. (I think these instructions are still accurate: VMware Fusion 7 Documentation Center  ) Leaving that on will sometimes cause us to delay key-events as we wait to make sure that you weren't entering a key-combo that we have to handle specially. Although I think the "Fn" key specifically is handled by the hardware or OS before it makes it to us, so this might be a change in MacOS.

The deeper problem here might be why your guest's mouse is particularly slow when grabbed? I would try to make sure that your VM: (1) Has a USB controller attached to it (2) Has VMware Tools installed properly (3) is upgraded to the latest "Hardware Compatibility" (4) Try changing the "Gaming Mouse" setting to "Never" (Normally "Automatic" is the right setting for most users, but something odd might be happening in your guest that's confusing the heuristics) That will normally ensure that you have the most efficient mouse experience, and generally we are able to accelerate the guest's mouse cursor all the way up to the host, so the "guest cursor" you see is actually set as the host's mouse image. If for some reason the guest doesn't have full mouse support (ie because we're missing one of the VMware drivers in the guest, or the guest is moving it's cursor completely on it's own), then we fall back to other methods of drawing the cursor which can be much slower. So to answer your question, normally the cursor you see is actually the host's cursor, and in the rare cases that it isn't, then the guest and host think the cursor are in completely separate places (so we don't have anything remotely accurate to show you). Although if you do want two explicit cursors to display/control, then bluefirestorm's suggestion of using a USB passthrough mouse is probably the best way.

We've gotten a number of similar reports about mouse issues on Windows hosts when upgrading to Workstation 14.  They appear to be host-side issues with our input stack, so they only happen on some host machines, regardless of the guest tools or guest configuration.  Our best guess at this point is that it's a permissions issue related to our interfacing with certain 3rd party mouse software/drivers, particularly on laptops. Some users have reported that launching Workstation as an Administrator (either by being logged in as an Administrator, or using the "Run as Administrator" option in the Windows right click menu) resolves the issue, but it hasn't worked for everyone. We're still looking into ways to reproduce this in-house.

The actual crash you're hitting there is a timeout in our code, where we think your session has hung.  But the mouse-thread that we're trying to reach is clearly still responding, because a few seconds into the Panic it prints into the log. I also see a couple messages that GuestInfo collection took 10x longer than it was supposed to.  So I can only guess that your system is hitting some kind of a temporary stall/load, and you're just getting unlucky.  (The cause of which could be the Windows bug mentioned by bluefirestorm, so I'd recommend trying to update Windows past that fix?) I'm not sure what the underlying cause of the stall is, but we have a config option you can set to make us wait longer before Panicing. If you set the line: mks.inputThreadRetries = 10 Into your config file (or vmx file), we'll wait twice as long before we'll give up trying to signal our thread.  The option measure the number of 5-second waits that we'll do trying to signal the thread, and it defaults to 5, so normally we'll wait a total of 25 seconds.  With mks.inputThreadRetries set to 10, we'll wait up to 50 seconds for a grab-request to complete before Panicing.  You can also set it higher if you need to, but the trade-off there is that if you're in the middle of trying to grab/ungrab, you might not be able to use the mouse/keyboard on your host for that long until it either completes successfully, or hits that timeout.  (That's why we were so strict on time-limits here.)

Yeah, I think there may have been some confusion there. I would expect that config option to solve the problem for you after a clean PowerOff/PowerOn.  If it doesn't, then we need to take another look at it with your log and see what's going on. (So if you can re-open the support ticket, that's a good way to get back in our tracking system and get information back and forth.  Alternatively, if you can just post the log here or send it to me a private message that works too.  I'll take a look either way.)

The VESA driver ships with the BIOS/firmware (normally as part of the ROM on the motherboard, although in our case it's virtualized)  and is what allows any operating system to get basic display functionality before a driver is installed.  So yeah, if you're using the built-in Linux framebuffer, it's internally using the BIOS support driver that we ship. We have a bug filed internally that I'm looking at.  If you could work with the support team to send me a new vmware.log file (with that "svga.minVRAM8MB" option applied), we'll try and figure out what's going on.