To review, about 80% of the time Windows 10 would crash with various errors on boot. Once it could get past that it was generally stable.
That was an inconvenience, but the problem came to a head when Windows decided to install the feature update to version 1607.
The first problem was when Windows rebooted to install the update. It went into a reboot loop: it would reboot, the windows logo would appear, and then a few seconds later it would reboot again. Over and over, forever.
The only solution I could find was to force it into the advanced boot settings, by powering off at the start of the boot 3 times in a row, and then choosing Troubleshoot > Advanced > Go back to the previous build. That put me back to what it was before it tried installing the feature update. But of course there's no stopping Windows 10 once it decides it wants to install an update...
I removed the VMware Tools and let it try the feature update install. This time it could reboot and do the install.
My theory is that the reboot loop is at the point where Windows was trying to change the video mode; for some reason it couldn't do that with the VMware Tools installed. I don't know if this has anything to do with the other problem, or if it affects anyone else.
So, feature update problem solved, right? Wrong. Windows went through the entire hours long process of performing the update, and got to the very last reboot.. the one that would login as the new build. And remember, boots into Windows 10 are only successful about 20% of the time. So sure enough, that boot got a BSOD.
But rather than just trying again, it appears that when WIndows is doing a feature update, it takes a BSOD as a showstopper issue. So it immediately backed out the entire update! Putting me back to square one. Which means, the BSOD problem must be fixed.
So thinking it might be something in this VM's VMX file, I compared it to the one created in the 7/25/2016 test, and guessed at which of the 22 differences could be significant.
First I tried removing:
acpi.mouseVMW0003 = "FALSE"
acpi.smbiosVersion2.7 = "FALSE"
Result: DRIVER_CORRUPTED_EXPOOL
Then I tried changing ethernet0.virtualDev = "e1000" to "e1000e".
Result: DRIVER_CORRUPTED_EXPOOL
Then I tried changing vmotion.checkpointFBSize = "4194304" to "67108864".
Result: no BSOD! Nor has there been any boot crash since then!
Except this doesn't make any sense, because as it turns out, Fusion sets this value itself each time the VM is started. So my changing of the value doesn't stick, it is back to what it was before.
So what's going on here? I can think of several possibilities:
- It isn't actually fixed, I've just been very lucky on the many restarts I've tried since then.
- It was fixed by one of the other changes, but it had a delayed effect for some reason. Maybe Windows didn't refresh some cache until it had crashed a certain number of times in a row.
- Changing the vmotion setting really did fix it, but by affecting something not in the VMX file, such as something in the NVRAM.
And there's a possibility that it wasn't fixed directly by the VMX changes but as a side effect. Right now if I compare the current VMX to a backup from before I meddled with it, I see 4 differences: the acpi and ethernet0.virtualDev changes above, plus two more:
- The backup has softPowerOff = "TRUE", but the current VMX has "FALSE". This may be a reflection of the current VM state.
- The ethernet0.pciSlotNumber changed from 33 to 192, which I see is also what the 7/25/2016 test VM had. Maybe that slot number goes with the e1000e device.
If what I did had (or has) not fixed the BSODs, next on my list to try was:
- My VM has a floppy device enabled, the test doesn't. Note that the floppy device does not work for some reason.
- My VM is missing some ehci:0 entries related to a video deviceType.
- My VM has the CD ROM set to autodetect = "TRUE".
- The test VM had a bunch of sensors set to pass-through.
I'm crossing my fingers that the instability problem is in fact fixed, even if it isn't clear what fixed it.
