VMware Communities
dsesdg
Contributor
Contributor
Jump to solution

Workstation 16.1.2 Pro, under Windows 11 host, Windows guest in VM crashes on startup

This Reddit post sums up this issue well:  https://www.reddit.com/r/vmware/comments/ph590g/vm_does_not_start_on_workstation_1612_pro_windows/

Basically using Workstation Pro 16.1.2 on a Windows 11 host, if you create a Windows guest VM, and the host system has Hyper-V enabled in any form (in my case its present because I have WSL2 enabled in the host), and if you have more than one processor and/or one core per processor selected for the guest, the Windows guest VM crashes at boot:

VMware Workstation unrecoverable error: (vcpu-0)

Exception 0xc0000005 (access violation) has occurred.

A log file is available in "C:\Users\test\Documents\Virtual Machines\Windows 10 x64\vmware.log".

You can request support.

To collect data to submit to VMware support, choose "Collect Support Data" from the Help menu.

You can also run the "vm-support" script in the Workstation folder directly.

We will respond on the basis of your support entitlement.

In my case, I'm running this all on the released Windows 11 using an AMD Ryzen 5950x.  This same host configuration works without issue under Windows 10 (multiple processors, multiple threads per processor, etc.)  Also, if I disable and remove all instances of WSL2/Hyper-V on the Windows 11 host, then everything works fine in the guest with multiple threads enabled.

A similar issue appears to have been reported here back three months ago as well:  https://communities.vmware.com/t5/VMware-Workstation-Pro/VMWARE-16-1-2-on-Windows-11-host/m-p/285495...

It may be interesting to note that I also have several Linux guests running in the same host, and they work without issue (one processor, 32 threads per processor).  So this appears to be related only to Windows guest operation in this host configuration.  It doesn't matter if the guest installation is Windows 10 or Windows 11, the crash is the same.  

It'd be great to learn if VMware is working on this issue for an update soon...it's unfortunate that I can only run Windows guests using one core + one thread, on a 32 thread machine...

Thank you!

1 Solution

Accepted Solutions
Mikero
Community Manager
Community Manager
Jump to solution

Thanks for everyone's patience on this issue.

We have identified the root cause and will be issuing an update to Workstation to address it. Will go out next week at the latest.

Breakdown:

During power-on when using Windows User Level Monitor (i.e. when Hyper-V is enabled on the Host in some shape or form), we set the Windows Hypervisor Platform processor features based on what features we actually want to expose to the guest.
This is done by iterating through a known list of WHP features and querying guest CPUID to determine if that feature is exposed to the VM.

Unfortunately, this didn't account for unknown WHP features. If Workstation (in ULM mode) is running on a version of Windows that supports processor features our software is not aware of, those features are not properly cleared, and the result can be an exception/crash like the one described in this thread.

 

-
Michael Roy - Product Marketing Engineer: VCF

View solution in original post

127 Replies
VTRInc
Contributor
Contributor
Jump to solution

I’m seeing the same issue on an i7-11370H running 11 Pro 10.0.22000 Build 22000.

Reducing to 1 CPU/1 Core does let it boot. 

I’ve tried to dig out all the references and instances of Hyper-V I can find. But, I’m not finding them all since I cannot get the CPU above 1/1. Is there a reference for verifying all of the Hyper-V is disabled?

At this point I’m considering downgrading to Windows 10 Pro. Nobody seems to have any issues with that combination. 

0 Kudos
dsesdg
Contributor
Contributor
Jump to solution

Yes, I'm currently using WSL2 (which uses Hyper-V virtualization underneath the hood), and I am able to temporarily disable Hyper-V by opening an Administrator command prompt, and using this command:

bcdedit /set hypervisorlaunchtype off

After issuing this command, then reboot the system.  Following reboot, I'm able to start the Windows guest under Windows 11 with 32 cores per processor enabled, and all works well in the guest (all cores appear, etc.)

To re-enable Hyper-V, you can issue this command:

bcdedit /set hypervisorlaunchtype auto

and then again reboot for the change to take place.

While this is a workaround, it is rather painful as I can't use WSL2 when I need to use the Windows guest in VMware.  (Not to mention it requires a full reboot each time one turns Hyper-V on and off.)

 

 

monkeybagel
Contributor
Contributor
Jump to solution

In my testing, yes, Virtualization-Based Security has been a large part of Windows 10, and is increasingly so in Windows 11, utilizing the virtualized environment to add an additional layer between the protected components and the other components of Windows that are the most likely to be compromised.

I think the revelation that VMware Workstation (and other desktop hypervisors) would coexist with Hyper-V and its hypervisor was a bit of a compromise, utilizing the Side Channel Mitigations and the performance penalty that is inherent with is for the "second level hypervisors" including VMware Workstation and Player.  Yes, it allows them to run, but it still cannot access the hardware that it needs to run optimally that we are used to seeing with Hyper-V loading at startup thus taking those resources first before they could be used by another hypervisor with the Windows environment.

As other have said, instead of playing whack-a-mole trying to get Windows do disable its own hypervisor from loading upon boot is frustrating at best, I have found that editing the BCD entry of the OS that is affected to instruct it to no load the hypervisor generally works.  This is actually a Windows-To-Go instance of Windows 11 x4 Enterprise RTM, and its respective BCD has no reference of the hypervisor loading.

 

 

 

Windows Boot Manager
--------------------
identifier              {9dea862c-5cdd-4e70-acc1-f32b344d4795}
device                  partition=\Device\HarddiskVolume1
path                    \EFI\Microsoft\Boot\bootmgfw.efi
description             Windows Boot Manager
locale                  en-US
inherit                 {7ea2e1ac-2e61-4728-aaa3-896d9d0a9f0e}
default                 {9f0f2862-26e4-11ec-919e-38f3ab956351}
resumeobject            {9f0f2861-26e4-11ec-919e-38f3ab956351}
displayorder            {9f0f2862-26e4-11ec-919e-38f3ab956351}
toolsdisplayorder       {b2721d73-1db4-4c62-bf78-c548a880142d}
timeout                 30

Windows Boot Loader
-------------------
identifier              {9f0f2862-26e4-11ec-919e-38f3ab956351}
device                  partition=C:
path                    \Windows\system32\winload.efi
description             Windows 11
locale                  en-US
inherit                 {6efb52bf-1766-41db-a6b3-0ee5eff72bd7}
recoverysequence        {906ca5be-26fe-11ec-95ce-ec52456d4bc6}
displaymessageoverride  Recovery
recoveryenabled         Yes
isolatedcontext         Yes
allowedinmemorysettings 0x15000075
osdevice                partition=C:
systemroot              \Windows
resumeobject            {9f0f2861-26e4-11ec-919e-38f3ab956351}
nx                      OptIn
bootmenupolicy          Standard

 

 

 

Using bcdedit to query the hypervisorlaunchtype value and setting it to "off" from "always" generally prevents the hypervisor from launching thus freeing these resources from being used that prevents VMware and other hypervisor applications from running normally without a performance penalty, at the expense of the VBS-based security that it enables.

0 Kudos
Supernatant
Contributor
Contributor
Jump to solution

I'm seeing the same thing. Just wanted to add to the thread so hopefully it gains some traction. 

Strange thing - works on my Ryzen 3800X home computer and Ryzen 4900 laptop, just not my 5800X at work... where it's most important. I'm thinking it has to do with the number of threads? Looks to be a Microsoft issue? 

On my trouble machine I'm seeing:

Linux VMs work fine.

Windows VMs work fine if you set it to 1 virtual CPU with 1 thread. 

Everything VMWare works if you use the BCDEDIT command shown in this thread, but you lose Docker/WSL2/HyperV. 

This needs fixed. Badly. It's affecting my work productivity!

0 Kudos
redsolja
Contributor
Contributor
Jump to solution

I have the exact same issue with AMD Ryzen 5800HS.

In addition, when running Windows 10 with 1 processor and 1 core, whenever I reboot, I get the same error message. However, you can say it runs.

Disabling HyperV disables all the security (and utility such as WSL2, which I use all the time, daily) Windows 11 has to offer and was built around. You are much more vulnerable to contemporary attacks.

0 Kudos
redsolja
Contributor
Contributor
Jump to solution

Did 16.2 fix the problem for anyone of you? Not for me.

0 Kudos
lzy19990117
Contributor
Contributor
Jump to solution

Not for me, too

0 Kudos
KenR2
Contributor
Contributor
Jump to solution

Just a heads up, my PC does the same exact thing and I do NOT have Hyper-V enabled or even installed on Windows 11.

0 Kudos
Qlippoth
Contributor
Contributor
Jump to solution

In Workstation 16.2.0, have you tried changing the Hardware Compatibility version from 16 to Beta? Did that fix anything?

0 Kudos
KenR2
Contributor
Contributor
Jump to solution

I just tried "from 16 to Beta", still the same error for me.

0 Kudos
redsolja
Contributor
Contributor
Jump to solution

Yes. I upgraded the existing to Beta compatibility and created two new ones with it and with 16 compatibility.

Nothing works.

0 Kudos
petesmst
Contributor
Contributor
Jump to solution

Ditto:  No success with 16.2 and selecting Beta.

0 Kudos
gkobler
Contributor
Contributor
Jump to solution

Same to me, desktop-pc with W11, WSL2 and active Hyper-V not working with VM-WS V16.2 When i disable Hyper-V it still works. But strange: on my notebook it works with Hyper-V enabled

0 Kudos
petesmst
Contributor
Contributor
Jump to solution

I have now tried various "Settings" configurations of VMWare Workstation Pro (16.2.0)   (16.2.0 build-18760230) with the latest build of Windows 11 (and also of Windows 11 Insider "Dev"; and Windows 11 Insider "Beta").

I can now no-longer get ANY of them to even install in VMWare Pro (16.2.0)

 

Attempts to open earlier builds of the same three versions of Windows 11 VMs that did open (in VMWare 16.1.2 Pro) are now also unsuccessful.

Edit:  My rig:  AMD Ryzen 9 5900X 12-Core CPU; ASUS Cross Hair VIII Formula Mobo; Win 11 Pro (21H2  -OS Build 22000.258); 32GB RAM; MSI GeForce RTX 3090 VENTUS 3X 24G OC; 

0 Kudos
Qlippoth
Contributor
Contributor
Jump to solution

I noticed what seemed like VM file corruption, but that could be due to Workstation itself crashing on some attempts. VMware would request the location of the VMDK every time after a few attempts to launch a Windows VM.

0 Kudos
a45s67
Contributor
Contributor
Jump to solution

I updated to windows 11 a few days ago and meet the same problem.

In my case, I accidently solve this problem with just follow steps. But I don't know why.

1. Go to "Turn windows features on or off" turn off my Hyper-V setting then restart.

2. Then go to "Turn windows features on or off" turn on my Hyper-V setting again. 

Then this issue solved, everything works well again. 

This is my environmet:

  • Dell laptop 5420
  • Cpu: i7-1185G7 
  • Memory 32GB
  • Windows 11 Pro, build 22000.282
0 Kudos
redsolja
Contributor
Contributor
Jump to solution

At your W11 host, can you open a task manager (ctrl + shift+ esc) and go to "details" and search for "lsaiso.exe" ? Is it there?

redsolja
Contributor
Contributor
Jump to solution

I tried this myself and it doesn't work.

 

0 Kudos
a45s67
Contributor
Contributor
Jump to solution

No, I can not find lsaiso.exe in my task manager.0

(I found I made a mistake, please refer to the Edit below.)

a45s67_0-1634989033709.png

Edit

God. I found I could start VM but could not start wsl2. After doing some research. It's because I had ran the command previously.

 

 

 

 bcdedit /set hypervisorlaunchtype off

 

 

 

Maybe that was why everything worked well, although I have turned on Hyper-V feature, my Hyper-V did not start actually, I thought...

After running the command below to turn on Hyper-V. I can open wsl2, but the VM show "unrecoverable error: (vcpu-0)" again. And "lsaiso.exe" appears in my task manager this time.

 

 

 

 bcdedit /set hypervisorlaunchtype auto

 

 

 

So, it seems that I made a mistake. I did not solve my case either. Sorry to disturb everyone. 😓

0 Kudos