Hi,
Have you checked the event viewer in the Windows 10 guest?
Also can you define crash? It means different things for many people.
Since it happens at night, it could be something that is triggered by the current power plan in your guest OS, but that's a random thought and might not actually help.
What version of macOS are you running?
--
Wil
Hi Wila!
It is the local logs that I have been inspecting. The system just seems to stop writing and when it starts again, it is after the manual reboot. The only report I can find here is something like "an unexpected shutdown has occurred". 
By crash here i mean BSOD (or the modern version of it, which is no longer that very blue).
MacOS version is 10.14.6
No power plan exists in this guest machine. First I thought that it might be a local backup (which is scheduled to run every night to a shared folder) that was the trigger, but turning it off didn't help, so it can't be. Are there possibly any VMware logs that might help me finding the "evil"?
Twice now, these crashes have corrupted the guest's file system and I have been forced to restore a Vimalin backup (lucky me to at least have that software 
).
/LS
Lennart,
Hmm... "an unexpected shutdown has happened' is not very helpful indeed.
As you mentioned that it is an issue for the past few months, it can't be related to the current problem that is happening with 10.14.6 (see https://planetvm.net/blog/?p=67185 )
Just to make sure, there's also no Vimalin backup running around the time of the crash? (not that I expect a Vimalin backup to somehow trigger a BSOD, but if it did happen then I'd be the one who wants to know about it)
The best logs to inspect at the VMware side are the vmware.log files that are in the VM's folder.
If you have logs of that and a date/time that indicates on when the crash happened then I'd be interested to take a look at that.
Most likely in the guest there will also be some crash dump files that might help.
See also: https://windowsforum.com/threads/where-are-dump-files-dmp-saved-after-crash.39784/
It's also possible that your VM folder has crash dump files logged by VMware.
--
Wil
Hi,
OK, let me try again, hopefully with a bit more clear cut instructions.
There's a few ways to get the logs.
1. create a support bundle (help menu -> Collect Support Information), this gets a lot more details though. So you'll have to tell me which VM this is about.
or
2. The vmware.logs. You can locate these logs via the VMware Fusion library. Right click the VM -> Select "Show in Finder" which will open Finder on your VM file location. Then right click that VM bundle and select "Show Package Contents". In the folder you get to see now, you will find a few vmware.log files. (vmware.log, vmware-0.log, vmware-1.log etc...)
Those are the files I would like to take a look at.
You can attach them to a reply here via the attach link at the bottom right of this edit window you type your replies in.
Just the files from step 2) are sufficient for me, but otherwise all the files via step 1) will work too.
If there's crash dump files, they'd either be in that same folder (file with file extension .dmp) or in your VM in folder C:\Windows\Minidump
If there are crash dump files then also please attach those as well as they will help in isolating the root cause.
Please note that once you provide the files that I'd also still would like to know last date/time when the crash happened, so that it won't take me as long to locate the data we're looking for.
--
Wil
Great!
I just got back from work and now I have a smoking hot/crashed guest VM (the failure must have occured last night or today, 19-20 August). If you have some time over, feel free to take a look at the attached log files.
All the best!
/LS
Hi,
Sorry for the delays. Too much work over the past week and as a result your post simply drowned out.
The .dmp file indicates that the crash happened on ntoskrnl .. which is the Windows kernel itself.
It does have an additional tip though as the crash details are:
082019-80078-01.dmp 8/20/2019 4:18:37 PM DRIVER_POWER_STATE_FAILURE 0x0000009f 00000000`00000003 ffffab8f`e500d970 fffff807`0de6ec00 ffffab8f`e2ed8010 ntoskrnl.exe ntoskrnl.exe+1bfcc0 x64 ntoskrnl.exe+1bfcc0 082019-80078-01.dmp 2 15 18362 913,068 8/20/2019 8:19:00 AM
IOW that's an error while trying to change power state
More details from Microsoft on that here: Bug Check 0x9F DRIVER_POWER_STATE_FAILURE - Windows drivers | Microsoft Docs
Param1 = 3 aka: "A device object has been blocking an IRP for too long a time."
I looked at your vmware.log file and it has this line over and over:
vmx| I125: E1000: E1000 rx ring full, drain packets.
The vmware.log file is garbled around the actual crash, so that part does not help.
With the line above I was about to suggest to go to an e1000e network device, but your .vmx file already has the line:
ethernet0.virtualDev = "e1000e"
You could try changing that into a vmxnet3 device though and see if that helps.
ethernet0.virtualDev = "vmxnet3"
Unfortunately the crash details do no tell us WHICH object/device was blocking for too long.
--
Wil
Thanks Wil!
It's certainly not an easy thing to debug these kind of errors. I have a feeling though that VMware's Shared Folders might have something to do with the crashes. I have turned off the service now, so lets see if the machine keeps failing. 
/LS