Please be careful as Workstation 16.2.2 went out before my fix. That should be in the next following that one.

It might be that it is harder to hit in 16.2.2 but err on the side of caution until the next release.

Yes, even with version 16.2.2 build-19200509 the problem still exists in different scenarios. If it takes too long until a paused machine is resumed, the error occurs. The same applies if the disk is compressed in a Linux machine (vmware-toolbox-cmd disk shrink /). Even the workaround

isolation.tools.hgfs.oplockmonitor.enable = "FALSE"

does not help in this case. Only

mks.sandbox.socketTimeoutMS = "1000000"

helps.

---

@fipsy wrote:

Yes, even with version 16.2.2 build-19200509 the problem still exists in different scenarios. If it takes too long until a paused machine is resumed, the error occurs. The same applies if the disk is compressed in a Linux machine (vmware-toolbox-cmd disk shrink /). Even the workaround

isolation.tools.hgfs.oplockmonitor.enable = "FALSE"

does not help in this case. Only

mks.sandbox.socketTimeoutMS = "1000000"

helps.

---

By Linux machine, you are referring to the virtual machine and not the host, right?
When you set the above setting in the virtual machine's VMX file, it was powered off at the time, right?

The issue described and addressed by the workaround only applies to Windows hosts.

If the workaround does not prevent your issue, then you are running into a different issue, possibly with similar symptoms.

If you hit the issue do the following:

1. Start the Task Manager 
2. Select the Details tab
3. Find and select the vmware-vmx.exe process for your virtual machine.
4. Right-click and select "Analyze Wait Chain"

Report here the details of the dialog box shown.

(See Wait Chain Traversal for more details.)

@banackmand @steve_goddard, FYI, I tried the previously recommended fix of adding to the .VMX file:

mks.enableX11Presentation = "TRUE"
mks.enableVulkanPresentation = "FALSE"

while retaning:

mks.enable3d = "TRUE"

This fixed my mkssandbox hang (wherein the mkssandbox process pins one host CPU core at 100% with no discernible trigger, freezing the Win10 client, including Task Manager and VMware Tools (preventing Player termination other than via system reset), indefinitely) for about two weeks until today, when the behavior resumed  and recurred randomly and with increasing frequency.

The setup is W10 on Player 16.2.1 on Ubuntu 20.04, fully patched.  Hwr is a four-core Xeon with 16GB RAM, three cores and ~11.5GB RAM allocated to the guest.  Ancient nVidia adapter and two monitors.  vmnet8, no folder sharing but the host serves SMB natively via Samba to the guest and machines on local physical subnets..

I'll diddle and fiddle with some of the subsequent suggestions re timeouts, etc., but you need to know the Vulkan approach fails.

Morning all,

I see this morning version 16.2.3 build-19376536 of VMWare Workstation 16 Pro (Windows) has been released.

@steve_goddard - Can you confirm if this version contains your fix?

Regards,

Kevin.

@steve_goddard  and @banackm , FYI, the link for the Linux version of Player v. 16.2.3 pops up a message box to download the Windows .EXE file, not a Linux .BUNDLE, as is the case normally and for the corresponding Pro version.

Also, attempting to upgrade via the application upgrade prompt fails, with the message that the upgrade is unavailable.

Hi @banackm, may I know how I can access my vmx file? Thanks in advance. I'm trying to add the command mentioned in regards to solving the VMware Workstation unrecoverable error: (mks) issue.

mks.sandbox.socketTimeoutMS = "200000"

You should be able to just open it in a text editor like notepad, and then add that line.

ISBRendererComm: Lost connection to mksSandbox (2878) is STILL occurring under Workstation 16.2.4

VMware seems to lack the QA and quality product it used to have!  After two years of display related and other serious bugs, VMware has made LITTLE progress.  That is UNACCEPTABLE.

The issue affects VMWare Workstation 17.0 as well:

https://github.com/vmware/open-vm-tools/issues/624