open-vm-tools
open-vm-tools copied to clipboard
vmware
"VMware Workstation unrecoverable error: (mks) ISBRendererComm: Lost connection to mksSandbox (2878)" at end of disk shrink on Windows 10 host Fedora guest
I believe since VMware Workstation 16.2 or a recent Windows 10 update (host) that disk shrinking, in my case on a Fedora 34 or 35 guest, causes an mksSandbox core dump at the end of the process on the VMware Windows application side. It didn't used to ever do this.
As per usual within the guest I run:
sudo vmware-toolbox-cmd disk shrink /
The Linux side completes successfully to 99% and then the Windows popup to shrink the vmdk comes up and that progress bar goes to the end. It stays open at 100% progress for a long while because looks like the Windows Security antimalware needs to scan the resized vmdk in full again and it takes some time as it's doing it using a single thread. (this is a separate issue that's been happening since the last couple versions of VMware Workstation on Windows 10 host and it didn't used to, but wasn't a big deal to me as it did always eventually finish)
But now instead of eventually finishing and renaming the shrunken tmp vmdk back to it's original name I get a Windows popup from the VMware application:
This crashes the running VM and the VMware Windows app. Since it happens right at the end I tried manually renaming the tmp vmdk to original after the crash and it comes back up. Seem like no damage is done other than the crash.
FYI my Fedora VMs are always standard partitions using ext4
This issue is also reported in https://communities.vmware.com/t5/VMware-Workstation-Pro/VM-Crash-16-2-1-build-18811642/m-p/2878409/highlight/false#M172530 , a fix is made in the next major VMware Workstation release. Please disable 3D in the VM config as a workaround for now. Thanks for reporting the bug!
This issue is also reported in https://communities.vmware.com/t5/VMware-Workstation-Pro/VM-Crash-16-2-1-build-18811642/m-p/2878409/highlight/false#M172530 , a fix is made in the next major VMware Workstation release. Please disable 3D in the VM config as a workaround for now. Thanks for reporting the bug!
Thanks for highlighting this reported issue. Separate from the mks disconnect issue, would you know something about the separate issue I mentioned regarding the very slow completion of disk reshrink because of what appears to be Windows needing to fully antimalware rescan the resized vmdk file using a single thread and this seeming to happen synchronously blocking the vmdk resize from finishing until it’s done? (many minutes later)
It stays open at 100% progress for a long while because looks like the Windows Security antimalware needs to scan the resized vmdk in full again and it takes some time as it's doing it using a single thread. (this is a separate issue that's been happening since the last couple versions of VMware Workstation on Windows 10 host and it didn't used to, but wasn't a big deal to me as it did always eventually finish)
Please try excluding the VM folder from Windows antimalware real-time scan while you are performing disk shrinking. https://docs.microsoft.com/en-us/microsoft-365/security/defender-endpoint/configure-extension-file-exclusions-microsoft-defender-antivirus?view=o365-worldwide
Same issue right here, though it occured randomly without any disk shrink or something like that. Disabled 3D acceleration and it works fine. Is this issue still being worked on?
We have a fix internally that will go out with a future version of Workstation, but it's too large for a quick fix on the released version.
We have a fix internally that will go out with a future version of Workstation, but it's too large for a quick fix on the released version.
I have this issue too on a Debian 11 host with the latest VMWare Workstation. According to Google, lots of people have the same mksSandbox issue while starting VMs or shrinking vmdk starting with 16.2.
I think you will lose a significant amount of your clients if you continue to fix critical bugs like this one in the "planned in the next major release" manner. It's a showstopper kind of bugs, either fix it ASAP or revert the change if you can't fix the bug.
Also, disabling 3D acceleration or mks.*-workarounds in .vmware/preferences is NOT a good temporary solution as it affects VMs performance very badly.
now i use 16.2.4 but i still have this error, disabe 3D is not a good idea so please fix it in fast
The error is happening on Windows 10 x74 Host with Intel graphics + Windows 7 32Bit guest.
The error is happening on Windows 10 x74 Host with Intel graphics + Windows 7 32Bit guest.
i want try Windows 7 64 bit if u tried it or have any info about it ??
