I've been getting the problem for about a week, ever since changing which directories are shared (removed one, added a different one). Nothing unusual about the directories that I can think of.
It does not happen every single time, but often enough that it's mega-annoying, and very dangerous both in lost work, and in near-destruction of the VM, which has already happened to me twice this week. I end up having to re-create the VM from scratch, and then move the original's hard drive into the new one and using that as the new one's boot drive. Attempting to start the old one results in a "Failed to power on '/Volumes/SSD2/VMs/Windows 10 x64.vmwarevm/Windows 10 x64.vmx'" error. Nothing I have attempted by way of repairing the broken VM has ever worked. There's no choice so far but replacing the VM and moving the original virtual HD into it.
Host: macOS 10.13.6 on a 2010 Mac Pro 12-core box.
Guest: Windows 10 x64, v1903 (build 18362.657); VMWare Hardware Version 16 (granted 4 cores and 8 GB of RAM).
VMWare Fusion 11.5.1 (15018442)
Using the shared directories themselves isn't a problem; it's the virtual directory "Shared Folders" which contains them that is the problem. Half the stuff I do with this VM actually lives in those shared directories (though I have to be careful about deletion – it'll be permanent, since deleted files and directories on these shares, when done in Windows, go to neither Windows's Recycle Bin nor to macOS's Trash, but are just wiped).
My work-around so far to prevent triggering this VM-destructive crash problem has been to avoid going into that "Shared Folders" pseudo-directory at all. I symlink (not shortcut – use mklink in Command Prompt) each of the shared directories onto my Windows Desktop. This has the benefit of not putting me into "\\Network\vmware-host\Shared Folders" if I go into one of these shared directories via a symlink and try to go up a directory (doing so puts me back in Desktop instead of in Shared Folders, which is where I would end up if I'd gotten into the shared directory in question via a shortcut. There's still a danger of entering "Shared Folders" via "This PC" > "Network locations", and other avenues.
PS: "\\Network\vmware-host\Shared Folders" in this case is also mounted as drive-letter "Z:".
It would be a good idea to start by attaching a vmware.log to this thread, so somebody can have a look if there's something out of the ordinary.
Your experience here with this issue certainly is not normal.
If it happens again, I'll consider it, after going over the log and seeing what it contains and redacting as necessary. I don't just blindly post such things to public forums. At this moment, I can't anyway, since VMWare Fusion stores the log inside the .vmwarevm package, and the package in this case is long gone, since I created a replacement VM, moved the virtual HD over, and threw out the corrupted VM.
Thanks for posting the logfile. I believe I have found the defect causing the failure, and I will make sure it is promptly directed to the attention of the relevant engineering team. Sorry you ran into this ugly failure.
Hmmm... It looks like I found a defect, but it was actually a separate issue from the crash you are encountering, so a bit more investigation is required, I'm afraid.
Did the failure leave a crash report file from vmware-vmx in /Library/Logs/DiagnosticReports on your host? If so, could you provide it?
Not crash logs, but some logs from the same day. I've attached them. I don't see any VMWare-related crash logs at all in there. The only .crash and .hang files in there are much older and pertain to other processes (Kiwi for Gmail, Keychain Access, Lingon X, coreaudiod, Activity Monitor, mds_stores; and most of them seem to date to a day on which I ran out of application memory due to a particular mal-behaving application, a since-fixed dev version of Keka). The last Kernel_*.panic file in there is four days earlier, March 4. Also attached is a list from `unzip -l` on the VMware Fusion Problem Report 2020-03-08 at 19.53.12.zip file (which has way more stuff in it than VMware ought to be grabbing a copy of, I would think, but I could selectively provide some of it if it's needed).
PS: Twice in the last week I have managed to get VMWare Fusion stuck in a mode in which it will not respond to keypresses or mouse clicks and cannot be quit (normally). The only safe way I have found to recover from this is to use the command-line utility to suspend any running VMs, then force-quit VMWare Fusion when those operations have completed. This seemed to happen under circumstances that involved drag-and-drop, but I've not managed to precisely replicate it. I suspect it's when you're doing a drag-drop in Windows in full-screen mode, then use Cmd-Tab or Cmd-LeftArrow to get out of that space and go to the Mac desktop or another Mac app while still holding down the mouse button; but I'm not entirely certain. Sorry that's not very precise (and it's off-topic for this thread). I'm just kind of reminding myself to try to pay attention to the details if it happens again. I'm loath to try to induce this on purpose since my luck in recovering via command-line might not be 100% reliable. Still, if those conditions are correct then this is a semi-serious issue, since a 100% perfect rate of remembering the difference between Mac's Cmd-Tab and Windows's Alt-Tab to switch between windows/apps is not likely for anyone to maintain. 🙂