I had a very hard time getting rid of Hyper-V in my setup, on a Windows 11 Pro host. The "normal" steps I found all over the web weren't enough! Web sleuthing finally got me what I needed, and for posterity and future searchers I want to document what I did to achieve the coveted CPL0 monitor mode and improved VMWare virtualization performance under Win11.
So, what's going on with this OS that creates this new problem for Type 2 (hosted) hypervisors like VMWare Player/Workstation or VirtualBox? Windows 11 Pro, by default, doesn't have the Hyper-V features enabled (to actually run Hyper-V guests), but it (like Windows 11 Home, btw) does use the Hyper-V hypervisor for certain new "Virtualization-Based Security" (VBS) features. These include Device Guard, Credential Guard, and core (memory) isolation. Basically, with VBS the entire host operating system is actually not running as the host at all, it's running as a Hyper-V guest on top of the Hyper-V platform. This has some detrimental performance impact (mostly unnoticeable in normal use, except in gaming), but the advantage is that with the OS running as a "guest," with all hardware access having to cross the virtualization boundary, all kinds of additional security features become possible to prevent/mitigate modern attack vectors. Microsoft deems these protections to outweigh the performance hit, so as of 22H1 or 22H2 update, memory integrity protection, Device Guard, and Credential Guard are enabled by default on a new OS install, if the EFI settings have the CPU virtualization capabilities (VT-d, etc.) enabled. An existing install that's upgraded to 22H? will honor the existing settings btw.
OK, so what's the problem? It's actually not a problem at all, in a way, at least not since Workstation/Player 17 I believe, which introduces "play nice with Hyper-V" capability. If the Hyper-V hypervisor is active on the system, VMWare's product sets aside its own virtualization platform and uses the Hyper-V APIs to create the virtualized environment on which to run a guest. In a way, Hyper-V is running the virtual "hardware" for VMWare, while VMWare provides some of the value-added features like USB capture, 3D-accelerated graphics, etc. Same goes for VirtualBox's newer versions. The price to pay, though, is that this "referred" virtualization is slower than VMWare's own implementation would be, if only it could run in full-privilege mode, access VT-d directly, and operate its own virtualization stack.
The user/admin/operator of the Windows 11 host must make a decision as to which is more important: the new and enhanced bulletproofing against attacks provided by virtualization-based security features, plus the interoperability with Hyper-V (VMWare can coexist alongside Hyper-V features; one can run a Hyper-V guest and a VMWare guest at the same time!), and let's not forget that Hyper-V is necessary for the Sandbox/WSL feature...or ditching the Hyper-V platform altogether, and the extra security features, and the ability to run WSL, to get the best possible performance out of VMWare Player/Workstation.
If you're wondering for your Win11 host whether Workstation/Player 17 is running its own virtualization stack or not, first take a look at System Information app (search for it in Start menu). The System Summary page has an entry near the bottom of the list named "Virtualization-based Security". As long as that doesn't say "Not enabled", the Hyper-V hypervisor is pulling the strings, and the host OS you're looking at is actually a well-disguised guest OS. To see what VMWare has to say on the subject of current state, run any VM and take a look at the VMWare.log file that gets put alongside the VMX and other files for the VM. Search for "Monitor Mode:" and see the value after the colon. If the value is "CPL0", the VMWare engine is running. If the value is "UML", the slower Hyper-V API is in use.
OK, so let's say you've decided to go ahead and remove the hypervisor and let the host OS run without virtualization. Here is a sequence of actions to take. Some people seem to have luck with the first set, but if the first set is not enough, I've also got the final silver bullet that will definitely get that VBS value in System Information to change to "Not enabled," and VMWare (or VirtualBox) to be able to run with full hardware access and its own engine.
Phase 1:
Some people seem to succeed by doing just that. Check System Information. Is the VBS feature no longer in running stated? If not, let's try Phase 2, which throws several more kitchen sinks at the problem.
Phase 2:
Still not there? That's what happened to me, but there's one more thing to do, luckily assisted by a tool (script) provided by Microsoft, which in my experience finally takes that last step toward the nirvana of seeing the "disabled" value for VBS:
Phase 3:
There is a manual way to do this, and I found the instructions, but they're a bit scary. It involves using bcdedit to modify the boot configuration to apply a configuration change that sets a "DISABLE-LSA-ISO" option. Lots of opportunity for something to go wrong if the instructions I found are flawed, or if a mistake is made (typo, missed a command). So, I'm strongly recommending (and providing instructions for) the method that uses the Microsoft-provided script. I've tested it, it worked for me, and the same script provides a way to undo the whole thing later if desired, too. Power users are welcome to find the instructions I found on their own, or to simply open the script file and examine what it does for any manual implementation activities.
I hope somebody finds this long writeup useful, either while searching this forum, or maybe when finding this post via a web search someday. It's based on what I documented during 2 days of web searches and frustration, and maybe it will save someone some headaches and time.
Hi svenmerget
Test the guide all 3 step to let my system working (lenovo P16 gen2).
After running the PowerShell script (more instruction in the Readme.txt from the downloaded zip file), the reboot will prompt and just need to press F3 to disable both the DG/CG.
Check and test vmware is working fine until a reboot.
When reboot the system Hyper-v service is running again....
Any idea?
Great walk through. Thank you for providing this, I was able to get it up and running.
Same thing happened to me as with @QBTech :
Only managed to get rid of hyper-v after all 3 steps, and a reboot. BUT... after another reboot then hyper-v reverts. So frustrating! Any ideas?
I thought it might be something like Credential Guard which is re-enabling hyper-v on the 2nd reboot. So I did the following:
Run "regedit" and created DWORD at "HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\DeviceGuard\LsaCfgFlags" [2] and set it to "0" (zero).
Run "regedit" and created DWORD at "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\LsaCfgFlags" [2] and set it to "0" (zero).
So with phases 1, 2, and 3, and these regedit changes then I can reboot often and hyper-v is never re-enabled.
I also found this post [3] which attempts to explain what's going on.
Hope this helps somebody else.
[1] https://answers.microsoft.com/en-us/windows/forum/all/how-to-disable-windows-11-defender-credential/...
[2] https://learn.microsoft.com/en-us/windows-hardware/customize/desktop/unattend/microsoft-windows-devi...
[3] https://community.meraki.com/t5/Wireless-LAN/Windows-11-Cannot-Connect-to-Wifi/m-p/182699/highlight/...
QBTech,
For a Lenovo laptop, it might be the case that "Kernel DMA Protection" is turned ON at the laptop UEFI.
Go to the laptop UEFI and turn off the "Kernel DMA Protection". It can be verified also from msinfo32 at Windows whether Kernel DMA Protection is on or off.