For quite a while now (years) there had been reports of users having problems with the Shared Folders feature in VMware Fusion and a newer version of Windows (Windows Vista / Windows 7 / Windows 8). After clicking around on a shared folder in the tree of Windows Explorer the CPU would go to 100% and lock your VM up for a minute or more.For example one such report can be found here: Shared Folder Issue in Fusion 5
I saw the same issue in Fusion 4 too and was at first suspicious at a subversion integration called Tortoise with Explorer, but could never pin it down on that. Even an uninstall of the tortoise to no avail.
Installing a brand new version of Windows 8 and sharing the same folder… had the same issues! Really a brand new windows VM and locking up for a minute or more while navigating a Fusion Shared Folder. That’s nuts!
Last week the guy who started this thread: Dr Gary mentioned that he had seen Windows Defender pop up in his task manager running at 100%.
Wait a second.. It’s always Windows Explorer that I see chewing up all the CPU, but YES, Windows Defender does integrate with Windows Explorer in a way that it might hide the real problem.
So I started Processmonitor from Sysinternals (Microsoft) and had it monitor all my file access while bringing Windows Explorer to its knees on a Shared Folder. I got to see this (but repeated many times and a lot of other zip files in there as well)
The clue there is that it tries to open and read zip files. Many of them and over and over again. Wait a second!
Before Windows 8 the Windows Defender tool is a malware scanner. My antivirus is allowed to look into zip files, I’m not sure if it is such a good idea for Windows Defender AND my antivirus to look into these files at the same time.
So I went to the settings of Windows Defender to stop scanning zip files and can’t believe the problem is fixed. Wow.. that’s 2 years of annoying lockups that could simply have been prevented.
Disabling the zip background scanning by Windows Defender did remove most of the high CPU for me.
However while using Outlook and trying to save an attachment in the shared folder I noticed high CPU again…
As the zip integration in Windows now was my direct suspect I decided to completely remove the integrated zip handling by windows explorer.
For me acceptable as I strongly dislike windows explorer’s behavior to treat zip files as a folder. Already used 7zip for opening/creating zip files, so nothing is lost by doing this for me.
So I used the steps as laid out here:
Restarted my VM to apply that change.
…and that indeed now also seems to fix the high CPU in the “save as” dialog.
Of course not having to take any of these workaround steps would be nicer, but I personally am at least happy to have a responsive VM.
Will let you all know if the problem does come back again (hopefully not)
1. According to Steve Goddard -the developer from VMware who knows EVERYTHING about this feature- the zip folder integration with Windows is unrelated and should only affect local disks, not VMware Shared folders.
2. As you can see in the linked forum thread above, another user reported this problem and his symptoms apparently had to do with the provider order in the network stack.
In the registry check the following setting:
Value Name: ProviderOder
It will say something like:
The vmhgfs setting should be the first in the list, so in this example it should be changed into: