Disabling Hyper-V hypervisor on Windows 11 Pro host (to get VMWare 17's CPL0 vs. ULM monitor mode)

[svenmerget]

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:

1. In Start menu search for "core isolation" to find the Core isolation page in Settings app. Turn off the Memory integrity protection, which will also disable the Kernel-mode Hardware-enforced Stack Protection. If Windows wants to restart, tell it "not yet" because there're some features to turn off, first.
2. In Start menu search for "windows features" to find and open the Windows Features control panel. Turn off Hyper-V and all its subfeatures, and also Windows Hypervisor Platform, Virtual Machine Platform, and Windows Sandbox. The OS should ask to restart, let it.

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:

1. In Start menu search for "command" to find Command Prompt, right-click it, and run as administrator (elevated). It has to be elevated, otherwise the command you're about to type/paste won't work.
2. Run command
   bcdedit /set hypervisorlaunchtype off
3. Close the command prompt window
4. Hit Win+R to get the Run dialog, and run:
   regedit
5. After a UAC/elevation prompt, the Registry Editor opens. Right below the menu bar there's a texbox where you can paste this path and hit Enter:
   HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\DeviceGuard
6. The tree view below the textbox (on the left) should have taken you to the path you pasted, and the values in this registry node should be shown in the right pane. Find the value named "EnableVirtualizationBasedSecurity", double-click it to edit the value, and in the dialog box that appears type 0 in the "Value data" field, unless of course that's already the value that's set. Hit OK to save the change and close the Registry Editor.
7. Hit Win+R again to get the Run dialog, and run:
   gpedit.msc
8. The Local Group Policy Editor should open. There's no convenient textbox to paste a path into, so you'll have to painfully expand nodes to find this path:
   Computer Configuration -> Administrative Templates -> System -> Device Guard
9. Find and double-click a setting in the right pane named "Turn On Virtualization Based Security", and in the dialog that appears, select the "Disabled" radio button, then OK button, and close the Local Group Policy Editor.
10. Restart the OS and again check System Information to see if the VBS value has become "disabled."

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.

1. Go to Download Device Guard and Credential Guard hardware readiness tool, provided by Microsoft to check Device Guard and Credential Guard capability, and to turn on/off the features. There's no setting anywhere in Settings app or control panel for this, and this "tool" is actually a PowerShell script, but it provides the necessary functionality. Find the Download button and click it, and your browser will download a ZIP archive.
2. Find and extract the folder contained in the archive. Don't try to run the script from within the archive. If you're using Windows Explorer, it can make a ZIP archive look like just another folder, but it isn't. You need to drag out the "dgreadiness_v3.6" (version as of when I wrote this post) folder from the archive into a real folder, e.g. onto your Desktop.
3. Search for "powershell" in Start menu to find Windows PowerShell, right-click it, and run as administrator (elevated). You must run it elevated or the script won't work.
4. You need to change the current drive and directory to the one where the script is. If you're not command prompt savvy: type "C:" for example (no quotes) if the folder is on the C: drive, or "D:" if it's on the drive, etc., and hit Enter, which should change the active drive to the correct one; next, open the folder you extracted the script files into, copy the address from the address bar into the clipboard (highlight and Ctrl-C), then type the following command (replacing <path> with a Ctrl-V to paste the path you just copied), and hit Enter:
   cd "<path>"
5. The prompt in front of your blinking cursor should now match the folder where the script file is located, meaning your "current directory" is the correct one.
6. Unless you know that you've already set this policy (power user), run this command next, to allow the script to be run:
   Set-ExecutionPolicy Unrestricted
7. You'll have to respond to a security prompt by typing "y" (if I remember correctly), possibly followed by Enter. It should then say it has successfully changed the execution policy.
8. Now we can run the script. Type/paste (if the version number has changed since I posted this, adjust according to the filename of the .ps1 script file in the extracted folder):
   DG_Readiness_Tool_v3.6.ps1 -Disable
9. The script will do some stuff, and then you'll get to restart, and during restart you will get a full-screen prompt asking you to confirm you want to opt out of Device Guard and Credential Guard. Answer in the affirmative. I don't have precise instructions for the exact sequence of events and prompts/actions after running the script, because I ran it several days ago and didn't document what I saw.
10. Once Windows has restarted with these features "opted out of," fire up System Information and check that VBS value again. For me, this was the final step that did the job, and when I ran a VMWare Workstation VM, it gave me the coveted Monitor Mode value of "CPL0"!
11. By the way, for the sake of security, you might want to change the PowerShell script execution policy back to the more restrictive default one after these steps. If so, launch Windows PowerShell again, as administrator, and execute:
    Set-ExecutionPolicy Default

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.

[svenmerget]

Woops, "D" plus colon got interpreted as a smiley of course, so as a correction, where the smiley is it's supposed to say D<colon>, as in drive D.

[csc007]

Thank you for the guide! I almost gave up on my recently purchased workstation pro 17. You're phase 3 definitely helps since none of Phase 1 and 2 works on Windows 11 Pro 22H2. 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.

[filefreak]

Hey!!! This works like a charm! thanks for the "Phase 3", this was the only step who solved my issues with Workstation 17.

[Zohaib99]

I am on step :

Now we can run the script. Type/paste (if the version number has changed since I posted this, adjust according to the filename of the .ps1 script file in the extracted folder):
DG_Readiness_Tool_v3.6.ps1 -Disable

 

And when I run command DG_Readiness_Tool_v3.6.ps1 -Disable I get the following error:

 

How do I get past this? 

[svenmerget]

First, does "C:\Users\Zohaiali\Downloads\dgreadiness_v3.6\dgreadiness_v3.6" directory contain a file named "DG_Readiness_Tool_v3.6.ps1", exactly the same as what you're typing?

If this exact file does not exist, why not? Is the name slightly different, or the ZIP was not fully extracted, or what?

If the exact file does exist, try putting period and backslash in front of the filename, to make sure PowerShell knows you're referring to a file in the current directory and not to an internal command:

.\DG_Readiness_Tool_v3.6.ps1 -Disable

[Zohaib99]

yes the script file is in the folder:

 

[svenmerget]

OK, then did executing with period and backslash in front of the script filename work? If not, something else is wrong that I can't see from the provided information. If your admin PowerShell prompt's current directory is the one containing the file, and you reference the file by its exact filename, PS should try to execute it, or at worst give an error about not being able to due to something like an execution policy setting.

[cynar]

FWIW, for me running the following on Windows 11 Professional will enable CPL0 for the VMware hypervisor

bcdedit /set hypervisorlaunchtype off
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity" /v "Enabled" /t REG_DWORD /d 0 /f

by disabling two Windows features. Running

bcdedit /set hypervisorlaunchtype auto
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity" /v "Enabled" /t REG_DWORD /d 1 /f

restores that.

Nothing else is required.

[TimothyHuckabay]

Hi cynar!  Did you have to do any of phase 1, phase 2 or phase 3 in the above instructions, before your suggested solution?  Also, I wonder if your solution is as performant as doing phases 1 to 3 above, given that VBS would ostensibly still be operating in the Windows 11 host OS, so would that be worth checking, by comparing a VMs performance under both scenarios?

[cynar]

I only exactly run the two above commands (I occasionally flip back and forth, playing with WSL2 - which requires the Microsoft virtualization stack -, so I am confident that all of this works just fine.).

The first command explicitly prevents the Windows Hyper-V hypervisor from being used.

The second command explicitly also makes sure that the hypervisor will not magically come back.

The effect of both commands combined is that the VMware hypervisor can run at the lowest (i.e. the best) privilege level, resulting in the CPL0 entry in the VMware logs. With the VMware hypervisor at CPLO, I expect that none of the Microsoft tooling sitting on top of _their_ virtualization layer will work (or interfere).

With respect to performance, I can easily tell on my system when the VMware Workstation hypervisor is not running at CPL0. I have not felt the need to scientific benchmarking after having identified the required steps to get to CPL0.

I carefully chose my hardware to not have a BIG-little CPU (I am on a simple Intel 11800H CPU), so any of the challenges of asymmetric CPU core performance scheduling do not affect me.

[mrnr]

Hi,

I have tested your (cynar) two line solution on my HP ZBook Power 15.6" G10 A Mobile Workstation PC, preinstalled with Windows 11 Pro (currently updated to 10.0.22621), but unfortunately it didn't work.
Checking VMWare.log for VMware Workstation 17.x Player after rebooting the host still shows "Monitor Mode: ULM".

This laptop has SecureBoot enabled by default and I guess perhaps that hinders the changes to take effect?

The "Device Guard and Credential Guard hardware readiness tool" suggested in svenmerget's great post seems designed for Windows 10 and therefore I haven't tried that (yet).

I registered a support request at VMware Technical Support on november 8 and have had a long Zoom session with a "Technical Support Engineer-EUC" without any luck.
The request is still "active" and hopefully this will render an official solution from WMware...

[svenmerget]

Secure Boot has nothing to do with this.  Secure Boot is a BIOS mechanism that verifies that any OS that tries to boot has a trusted certificate that's stored in the BIOS database, with a default database populated by the mainboard manufacturer. It's a security measure to prevent e.g. some strange USB stick from booting up a malicious Linux portable distro to gain access to the machine and its drives and start doing malicious things on the machine. The problem we're concerned with in this thread and with VMWare's virtualization engine vs. the Hyper-V engine being used, is whether the host Windows OS itself is running on the Hypervisor virtualization layer or not. This used to be simple. If Hyper-V was installed/enabled, the host OS was also virtualized since Hyper-V is a Type 1 Hypervisor. Now, though, in the Win11 days, the number of scenarios where the Hypervisor is active has been multiplying, and in any new/clean Win11 install it is the default state. There are clear security advantages to running even the "main" OS in a virtualization environment, in terms of isolating its CPU, memory, and other hardware access. If the Hypervisor mediates all hardware access, it can prevent some of the more sophisticated attack vectors that are out there.

Anyway, assuming you're willing to forego the security advantages in favor of performance, want the host OS to run "directly" on the hardware, and want VMWare software to have direct access to VTd and the ability to run its own Type 2 hypervisor alongside the host OS ("CPL0"), the instructions I provided do work on Win11. Win11 is where I worked out my instructions and met success using them.

[VMware Community Member]

Well, that sounded quite useful, but in the end the microsoft script failed with DISM not recognizing the "Microsoft-Hyper-V-Online" option, therefore it just failed. Googling around showed that this is indeed a valid function/feature, but why on earth does DISM fail on my brand new Windows11 PC?

Edit: I found out that "Microsoft-Hyper-V-All" is a valid option for the DISM command, unfortunately this doesn't work either. No matter how hard I try, the system will always come up with Hyper-V running.

[svenmerget]

Maybe this is a Pro vs. Home problem. Home has a more limited features set, and maybe something the script is trying to do fails because of it. Does this machine have Home edition? If so, maybe it has to be upgraded to Pro before the script/procedure will work, although there may be some other way to get the desired result without upgrading. If it has Pro edition already, sorry, no further ideas to contribute.

[VMware Community Member]

No, this is a Win11 Enterprise system.

[VMware Community Member]

rewrite post accidental purged of first message.
I have Windows Sandbox currently, running on windows 11 Version 22H2 (OS Build 22621.1194),
on "native boot" (if that's the right term. - "vhd on bare metal" - now vhdx on uefi to be precise)

1. I tried Windows Sandbox without optional "required" features... and it works!
systray says "no network" but network works: normal? ; just me? 

Current optional features (classic) - NB no containers, Hyper-V things...

2. With Windows Sandboxes you can't have multiple instances, or spawn a box within a box...
Is either of these possible via other providers like docker or other vm_things? Any bests?

3. Just in case... anyone tried or managed to remove the single-instance limiter on Windows Sandbox?!
I know it's probably virtually impossible... but we have curiosities.

Asking for a friend. Thanks for the reading material! This threads gonna take a while to peruse!

 

 

[VMware Community Member]

I did Phase 1 and it seems to have worked.

I'm running Windows 11 22H2 (22621.3007).

When I checked the VMware.log, Monitor Mode was CPL0.

[VMware Community Member]

Does your sandbox network config (in system tray) also incorrectly indicate no-net?

I suspect it's incorrect, as even the Start Menu's bing search-provider returns results!

 

Biggest Usability Issues

This may be normal (can you confirm?) I wouldn't be surprised if this is just me -

alt+tab in host doesn't work, even in window mode, when sandbox window is focused

Expected: able to switch to other apps
Observed: sandbox "add" consumes all "alt+tab" or winkey+number or ctrl+shift+esc 

Workaround: ctrl+alt+del then alt+t to focus task manager, or use mouse KB4EVA!

 

[VMware Community Member]

Great Information thank you! ...

I was able to do everything via Phase 1 and Phase 2 ... I had to manually create the 'EnableVirtualizationBasedSecurity'  key as it was not there but no big deal ... am now running ... my installation already said it did the Hyper V part on its own but it didn't ... VM seems a lot more snappy now...

 

 

[QBTech]

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?

[QBTech]

[SimonHF]

Same thing happened to me as with  :

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/8ed83adc-56e9-4b6a-ac79-39803bbdfb07
[2] https://learn.microsoft.com/en-us/windows-hardware/customize/desktop/unattend/microsoft-windows-deviceguard-unattend-lsacfgflags
[3] https://community.meraki.com/t5/Wireless-LAN/Windows-11-Cannot-Connect-to-Wifi/m-p/182699/highlight/true#M24486

[bluefirestorm]

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.

[shneidr2168]

Great walk through. Thank you for providing this, I was able to get it up and running. 

[Ed Stafford]

Thanks or this. After a few hours of searching and finding nothing that worked, Phase 2 cleared things up for me and all is working now. Thank you!

[Cemre Seher]

You re a GOD amongst men my friend. I researched for 3 whole days. Your Phase 3 tutorial with the PowerShell Script finally did the job! I cant thank you enough

[mike horist]

you sir are a gentleman and a scholar!

I switched to Pro (had been Pro in the past on Windows 11 but I didn't find this article.... ended up hacking up my registry and just reinstalling the base home version my computer came with) and kept checking to see what systeminfo would show (because I knew if I saw the dreaded last line about hypervisor I'm screwed...  and vmware workstation pro told me (strangely after I enabled JUST older versions of samba support) )

Following this , (I made 2 adjustments, not sure if it contributed...    EnableVirtualizationBasedSecurity wasn't there so I added it as a 32 bit DWORD with value 0, also I changed Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\SystemGuard "Enabled" to 0)

I just had to go to phase 2 !   I owe you a virtual diet coke (or a beer of your choosing lol)

[Deepu Thomas]

Arrgh .. Thank you for this enlightening post but it is driving me nuts...  I want to use full VMware workstation features and not rely on Windows Hypervisor platform etc.

I did the Phase 1 - but no change in "System Summary" -> "Virtualization-based Security"

Proceeded to Phase 2 - Added "EnableVirtualizationBasedSecurity" in HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\DeviceGuard- but no change in "System Summary" -> "Virtualization-based Security"

Optimistically, proceeded to Phase 3 and it worked for the 1st recommended reboot. But after further reboot/shutdown/startups, "System Summary" -> "Virtualization-based Security" is back to Running :(

I tried @SimonHF's suggestion by adding the ones below:

"HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\DeviceGuard\LsaCfgFlags" [2] and set it to "0" (zero).
"HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\LsaCfgFlags" [2] and set it to "0" (zero).

But that did not help too - coz after redoing Ph 3, again, after 1st reboot, "System Summary" -> "Virtualization-based Security" is back to Running :(

Has anyone overcome this issue?

[Enrico Dolama]

There is one more step that fixed it for me after following the Phase1-3 and the suggestion by @SimonHF, it was still reappearing for me after rebooting.

The last step I did was to go into Services and manually disable, important: not stop the "HV Host Service" it was running even though I had it set to Manual before. Will report if it comes back but it didn't after the second reboot.

[Mohamed Eltantawi]

You are a saver! only phase 3 is what worked for me. Thanks a lot.

[Jayaker Nagamalla]

I tried both phases 1 and 2 mentioned above and checked Hyper-V, but it shows that it is not installed. Still, I am getting a fig 1 error. What am I doing wrong? I have explored the help section of the internet, but I have had no luck. Can someone assist me? I installed VMware Workstation Pro. Has anyone encountered the same issue below?

Fig 1

Fig 2