VMware Workstation 16 Shared Folder BSOD Problem

[Lodec]

I am running into BSOD of the guest each time file transactions (read/write actions as during move to with crc, copy to, zipping and unzipping etc.) towards the shared folders on the host machine are carried out.

Host machine:

Intel i9, 32GB RAM, VMs stored on SSDs, shared folders on HDD, OS Windows 10 Pro x64 (latest 21H2, up-to-date)

Impacted guests OS:

Windows 7 Pro x64, Windows 10 Pro x64, Windows 11 Pro x64 (all up-to-date)

The problem first occurred after I upgraded to Workstation Pro 16. It never happened with older Workstation Pro 15 or earlier versions on the same host with the same VMs (except for Windows 11 guest which was not used before).

What I've tried so far to find a workaround:

• Deactivating hardware acceleration and setting fixed screen resolution -> It still happens.
• Changing the CPU cores to 1 cpu & 1 core, 1 cpu & multi-core, multiple cpus & 1 core -> It still happens.
• Upgrading some of my VMs from Win 7 to Win 10 to Win 11 -> It happens with all of these Windows versions the same.
• Upgrading and downgrading to try all the 16.x versions up to 16.2.3 -> The problem persists with all 16.x versions.
• Manually upgrading the VMware Tools up to current 12.0.0 -> The problem persists with all of the different VMware Tools versions.
• Fully Setting up new, clean VMs with Windows 10 x64 and Windows 11 x64 -> It still happens.
• Set shared folders to the antivirus ignore list in either the host or the guest AV tool (so that only one AV checks the shared folder contents to make sure there is no overlapping av monitoring) -> It still happens.
• Tried Windows Defender and different third-party AV tools -> It still happens with either of them (Windows Defender, Bitdefender, Comodo).
• Checked host OS with sfc /scannow -> No problems on host system.
• Checked that none of the shared folders overlap -> It still happens although no overlapping shared folders.
• I even get the same BSOD, if I completely deactivate shared folders in VMware and instead mount the according folders as network drive inside my VMs (i.e. access via network instead of VMware shared folders).

• Also adding 

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

  to the vmx file of the according VMs does not help. The bug persists.

As of now, there seems to be NO working workaround to this problem. Not having shared folders or at least something equivalent that allows to access folders on the host is not acceptable and for sure not to be considered as a "solution" to this problem.

I'm tired of auto-rebooting VMs all the time and wasting all this time to no avail. I need to share folders between host and guest! Vmware Workstation is not usable for me any longer as long as this problem persists.

I cannot believe that VMware isn't aware of this massive problem. And still I am not aware that they did confirm or fix this problem in all the updates that came out since Workstation 16.0.0. It has not been addressed in one of the updates since then.

If anyone has a clue what is going on, why VMware does not seem to want to fix or even recognize this, what might be the problem behind the symptoms (I guess it is an unfixed VMware driver issue) and what other workarounds could solve the problem: Please let me know.

If this does not get fixed, or if not even a practicable workaround is discovered, I will have to go with other virtualization solutions for the future - and they will for sure not be branded with "VMware"! This bug is a game changer that renders VMware unusable.

[continuum]

If you use Windows Host and Windows VMs why dont you simply use regular Windows file-sharing instead of the makeshift unreliable VMware-shared-folders ?

Ulli

[SurplusGadgets]

Glad to see your post.  I went to bed bleary-eyed 3AM also.  After being forced to upgrade Workstation from 15 to 16 by Windows Update on the host.,  The update would not install with VMWare 15 installed; saying it causes a BSOD in the host.  But ever since, I have the same issue in 7 VM guests.  The only thing I have not yet tried is downgrading back to 15.  But, according to Microsoft, I will make my host Windows11 unstable if I backgrade VMware Workstation.  So not sure what to do.  Have not tried all your techniques but did many over the past 10 hours of fighting this.

Intel(R) Core(TM) i9-9900 CPU @ 3.10GHz 3.10 GHz
40.0 GB (39.8 GB usable)
Windows 11 Pro
22H2, OS Build 22616.1

VMWare Workstation 16,2,3 build 19376536
Guest OSs (for release check and install development of MIT/GPL license bioinformatics software package):
Ubuntu 18.04, 20.04, and 22.04; MacOS 10.14, 10.15, 11, and 12.

The drives I am trying to share / mount are all located on the host (SSDs; either NVMe or USB-C attached)
VMWare and the guest VMs are a bit rot, waste of space on the disk right now.  One thing I have not tried but will now is uninstall 16 since the upgrade.  I was forced to do the upgrade before I installed the Windows Update.

@continuum  I think the OP mentions he tried network drives and faced the same issue.  I am still struggling since the upgrade with network services. Available to apps like the browsers but OS software update and disk access says the network is down.  So I have not even been able to try that route. Have never seen where user applications have network access but not OS services. Perplexing. But an aside; not trying to hijack a thread but add to the information.

[continuum]

@SurplusGadgets 
Better dont mention that you run MacOS guests here in the forum - that is considered to be illegal.
And I have not seen where OP mentions that he tried regular Windows filesharing.
I use Workstation since 20 years and I never understood why users are so fond of VMware shared folders - the complaints about them beeing unreliable is one of the constants in this forum.

If I really need a VM without network access I share files using iso-files - or via USB-sticks.

Ulli

[Lodec]

What do you mean by "regular windows filesharing"? Do you mean network folders/network shares that can be configured in Windows by setting "Share" options in the folder dialog?

If so, I already tried this kind of network shares configured on the host machine (while completely deactivating VMware shared folders). When accessing the network shares on the host machine with file transactions like the ones stated in the original post from within the VMs, exactly the same BSOD problem occurs. So this does not seem to solve the problem.

Any other hints or ideas?

[continuum]

If regular Windows file shares also crash the host then there is something deeply wrong with your Workstation installation.
Is switching to WS 16.1 an option ?

[Lodec]

You missunderstood me: The host is not crashing. The guests are crashing.

I already tried downgrading to 16.1 to no avail (with full uninstall and re-install). The problem persists.

And I repeat: The problem first occurred when I upgraded to Workstation 16. It did not occur with WS 15, nor with any version prior. The configuration of my network or machines has not changed since then - except for some machines were upgraded to Windows 11, which is the reason I cannot switch back to WS 15 anymore. But Windows 11 on individual guests cannot be the origin of the problem, as it also happens with the Windows 7 and 10 guests - with exactly identical BSOD message pointing to mup.sys.

[SurplusGadgets]

@Lodec are you seeing odd networking behavior?  Meaning, browsers and even apt work inside the guest, but any access to file networking resources does not?

I downgraded back to WS15 last night and my BSOD went away. But the network problem persists. Which was introduced with the WS16 upgrade / install. So I still cannot access file shares whether through Vmware tools or standard network access methods.  Am wondering if the Windows update that made me uninstall VMware also changed network settings for the program; maybe firewall settings, etc.  Still investigating myself but at least the guest BSOD is gone and I have not run into any host BSOD that Microsoft mentioned would happen and why they forced me to uninstall to get their upgrade. A third update to windows in 3 days has come through again today though.  So maybe they are discovering problems with their release.

Now at Windows 11 Pro 22H2, OS Build 22616.100 ; VMware Workstation 15.5.7 build-17171714

UPDATE: For whatever it is worth, after backporting to WS15, then reinstalling WS16. and having the 3rd Windows update today -- the BSOD in the guest seems to have disappeared.  Still having some networking and network share issues but finding work arounds as I try to get productivity back (can only connect by direct entering smb://server/ whereas before they used to show up as available, can no longer have aliases on the desktop for the mounted shares, etc).

[Lodec]

As of now, I re-tried regular Windows network file sharing as an alternative to VMware shared folders with most current Workstation 16.2.3 and this time it seems to work out - no more guest VM crashes so far (since 3 days).

It did not work with prior 16.x.x subversions (caused the same guest VM crashes too), but it seems with 16.2.3 the problem must have been fixed somehow at least regarding Windows network file sharing. So I am able to fully replace VMware shared folders by regular Windows network file sharing. This can be seen as workaround and in my personal case as a solution as long as VMware does not break it again.

It is not a solution for the original topic of VMware shared folders causing BSODs in guest VMs. But as long as it works out, I am happy with it. I hope that this can help others with the same problem.