Running into a very frustrating issue using Shared Drives in Fusion 11.5.x.
Consistently, when manipulating files, attributes, etc in WIN10 on a VMWare Fusion Share Drive, I get a BSOD with the mup.sys driver indicating SYSTEM SERVICE EXCEPTION.
This issue can be easily reproduced.
I have removed and reinstalled VMWare tools -- removed and recreated the drives and still the issue remains.
My setup:
I did some digging into the issue and found no matching issues or resolutions.
What I learned and helped to isolate the issue:
Mup.sys is a file associated with the Windows Multiple Universal Naming Convention Provider process and is responsible for handling queries for remote file I/O operations.
When an application tries to access a shared resource using a UNC path, the request first goes to the I/O Manager, which forwards it to the Multiple UNC Provider (MUP). The MUP then queries the installed redirectors to determine which one can access the shared resource. It then passes the request to the redirector.
So I am not sure if the issue is Windows or Fusion....
Any help would be appreciated.
This (in my case) is specific to Microsoft Office products. If I save a text file, pdf through Adobe or other file I do not BSOD. However, if I save an Excel spreadsheet this happens consistently on one of my VMs.
Exact same experience, only Excel causes the BSOD. A macro I run in Excel which uses COM to invoke access to Word and Outlook and builds out my daily status reports is almost 100% of the time causing this issue (a little less for a short time after a complete host reboot, but no difference after a guest reboot even if I restart the VMWare process in-between). Working in Outlook, PowerPoint, Visio or Word are perfectly fine. I actually store my home folder and my Outlook database on the shared folder rather than in the vmdk and that does a lot of I/O.
Curious, what build of Windows 10 are you using and what version of VMware Tools are installed in the VM?
Fusion (and Workstation, for that matter) shared folders are known to be... well..... let's just say somewhat less that robust. They've been known to have issues under high I/O circumstances and when applications (such has MS Office) perform certain file operations in the guest. People have found better luck with using plain old SMB file sharing (i.e.configuring macOS to share folder with Windows file sharing) in those situations.
I recall an old issue where excel couldn’t write directly to a shared folder…but it’s been a while, so don’t remember the details.
