Virtual Machine BSOD for Different Versions of VMware

[imaginary_CPU]

Hello all,

I am having trouble with my virtual machines where when I boot them up I will get the BSOD. I have upgraded from VMware Workstation Pro 15 Pro (15.1.0) to VMware Workstation Pro 16 (16.2.3). I am moving my 15.1 version VM to run on the new VMware 16.2.3, and I have been getting BSOD all the time. Sometimes the VM will boot just fine, other times the VM will try to repair itself and boot up, or continuously get BSOD. Things that I have tried:

-updated VMware Tools if the VM booted up correctly

-Windows and VMware updated to latest versions

Stop code: SYSTEM_THREAD_EXCEPTION_NOT_HANDLED

Could there be a compatibility issue running a VMware 15.1 VM on VMware 16.2.3? How would I remedy this?

[scott28tt]

Your thread needs moving to the area for Workstation Pro so it is seen by the correct audience.

I have reported it to moderators, so they know it needs moving.

The {code} area is for SDK matters.

[RDPetruska]

Host OS and version?

Guest OS's?

You may want to try Workstation 16.1.2 - many users have experienced multiple issues with the 16.2 branch.

[imaginary_CPU]

Host/Guess OS: Windows 10

Host Version: 16.2.3

Would I have to get another license key to revert to older versions?

[continuum]

Do you prefer simple questions that dont require long answers ?
Fine with us - it is still early in the year - not even august ...
Ok.
Do you store your VMs in directories that are synced with OneDrive ?

Ulli

[RDPetruska]

No, a Workstation license is good for any version with the same major number (i.e. 16.x)

[continuum]

The vmware.logs probably show useful details to figure out what caused the BSODs.
Did you ever read one of them ?

[bluefirestorm]

I have had this happen and (still happening) with 2 Windows 10 Pro VMs. One runs on Workstation Pro and the other on Fusion Pro. The problem does not occur on newly created Windows 10 VMs; or other Windows VMs created from OVA downloads. I think for Workstation, it started with 15.5.x (Ubuntu host). Fusion started with 10.x. It still happens with 16.2.3 and Fusion 12.2.3. I don't know if your situation is similar to mine.

Problem occurs when 4 or more vCPUs are assigned.
Previous workaround is enable Hyper-V inside the guests (This doesn't work when host is running on battery power at least with Fusion 10.x/12.x).

This is an explanation of my current and somewhat strange workaround

When you power up the problematic VM, imagine the Windows 10 VM screen real estate that it will occupy on the host screen when it gets to the logon screen. Make sure you don't have the host mouse pointer in that space, no applications (e.g. browser, text editor) should be in that space during the power up phase. Anytime the host mouse pointer or any application window is visible in that screen space during power up, it will result in SYSTEM_THREAD_EXCEPTION_NOT_HANDLED. I tend to just put the host mouse pointer on the lower right hand side of the host screen after initiating VM power up.

If the host is a laptop, running on battery has the mouse pointer/app window workaround no longer apply (at least with the MacBook Pro running Fusion). I just have to reduce it to 2 vCPUs. But the workaround with the no mouse pointer, no application windows in that VM screen real estate works if it is plugged in to main power.