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!
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.
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.
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.)
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.
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!
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.
Did 16.2 fix the problem for anyone of you? Not for me.
Not for me, too
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.
In Workstation 16.2.0, have you tried changing the Hardware Compatibility version from 16 to Beta? Did that fix anything?
I just tried "from 16 to Beta", still the same error for me.
Yes. I upgraded the existing to Beta compatibility and created two new ones with it and with 16 compatibility.
Nothing works.
Ditto: No success with 16.2 and selecting Beta.
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
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;
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.
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:
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?
I tried this myself and it doesn't work.
No, I can not find lsaiso.exe in my task manager.0
(I found I made a mistake, please refer to the Edit below.)
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. 😓