Windows 11 Pro for Workstations – Hypervisor starts despite Hyper-V and VBS being disabled

Question

Windows 11 Pro for Workstations – Hypervisor starts despite Hyper-V and VBS being disabled

Chris Nelis 0

I am experiencing a persistent virtualization issue on a new Dell Precision 7960 Tower running Windows 11 Pro for Workstations (Build 26200.9711).

The Microsoft hypervisor continues to start automatically, despite Hyper-V, Virtualization-Based Security (VBS), Memory Integrity and related virtualization components being explicitly disabled.

This prevents VMware Workstation 25.0.1 from providing nested Intel VT-x/EPT virtualization, which is required to run Cisco Modeling Labs (CML).

System details:

Hardware: Dell Precision 7960 Tower

Processor: Intel Xeon w7-3555

Operating system: Windows 11 Pro for Workstations, Build 26200.9711

BIOS: Dell 2.22.0

VMware Workstation: 25.0.1

Device: Personal workstation, not domain-joined

Troubleshooting completed:

Disabled all Hyper-V Windows optional features, Virtual Machine Platform, Windows Hypervisor Platform, Windows Sandbox and WSL.

Disabled Memory Integrity through Windows Security.

Disabled Virtualization-Based Security through Group Policy and registry settings.

Explicitly configured the following boot settings:

hypervisorlaunchtype    Off
vsmlaunchtype           Off

Confirmed that Intel hardware virtualization is enabled in BIOS.

Uninstalled VMware Workstation completely and confirmed that no VMware services remain.

Performed multiple restarts and verified that the disabled settings persist.

Current diagnostic results:

Despite the above changes, Windows continues reporting:

HypervisorPresent                      : True
VirtualizationBasedSecurityStatus      : 2
SecurityServicesConfigured             : {0}
SecurityServicesRunning                : {0}
CodeIntegrityPolicyEnforcementStatus   : 2
UsermodeCodeIntegrityPolicyEnforcementStatus : 2

Relevant registry settings are:

EnableVirtualizationBasedSecurity = 0
RequirePlatformSecurityFeatures   = 3
SystemGuard Enabled               = 0
HypervisorEnforcedCodeIntegrity Enabled = 0

Windows Event Viewer confirms that the hypervisor starts successfully.

On 23 October 2026 at 16:04:05, the Microsoft-Windows-Hyper-V-Hypervisor provider recorded:

Event ID: 1
Hypervisor successfully started.

Additional events include IDs 2, 129, 156 and 165, confirming hypervisor initialization and configuration.

Potentially relevant enforced policy:

Using CiTool.exe -lp -json, I identified the following enforced policy:

FriendlyName : Microsoft Windows Virtualization Based Security Policy
PolicyID     : a072029f-588b-4b5e-b7f9-05aad67df687
IsEnforced   : True

I appreciate that the presence of this policy does not necessarily establish that it is responsible for launching the hypervisor.

Impact:

VMware Workstation reports:

Virtualized Intel VT-x/EPT is not supported on this platform.
Feature 'hv.capable' was 0, but must be at least 0x1.
Module 'FeatureCompatLate' power on failed.

The VMware diagnostic log also contains:

IOPL_Init: Hyper-V detected by CPUID

Request for Microsoft support:

Could Microsoft please investigate and advise:

Why does the Microsoft hypervisor successfully initialize when hypervisorlaunchtype and vsmlaunchtype are both explicitly set to Off?

Could the enforced Microsoft Windows Virtualization Based Security Policy be contributing to this behaviour?

Is this a known issue with Windows 11 Build 26200, particularly on Intel Xeon workstation hardware?

What supported diagnostic procedure can identify the component or policy responsible for initiating the hypervisor?

Is there a supported method to completely disable the Microsoft hypervisor and VBS so VMware Workstation can access Intel VT-x/EPT directly?

This behaviour persists even after VMware has been uninstalled, indicating that the Microsoft hypervisor is operating independently of VMware.

I would appreciate a technical investigation rather than further recommendations to disable the standard Hyper-V features, as those steps have already been completed and verified repeatedly.I am experiencing a persistent virtualization issue on a new Dell Precision 7960 Tower running Windows 11 Pro for Workstations (Build 26200.9711).

The Microsoft hypervisor continues to start automatically, despite Hyper-V, Virtualization-Based Security (VBS), Memory Integrity and related virtualization components being explicitly disabled.

This prevents VMware Workstation 25.0.1 from providing nested Intel VT-x/EPT virtualization, which is required to run Cisco Modeling Labs (CML).

System details:

Hardware: Dell Precision 7960 Tower

Processor: Intel Xeon w7-3555

Operating system: Windows 11 Pro for Workstations, Build 26200.9711

BIOS: Dell 2.22.0

VMware Workstation: 25.0.1

Device: Personal workstation, not domain-joined

Troubleshooting completed:

Disabled all Hyper-V Windows optional features, Virtual Machine Platform, Windows Hypervisor Platform, Windows Sandbox and WSL.

Disabled Memory Integrity through Windows Security.

Disabled Virtualization-Based Security through Group Policy and registry settings.

Explicitly configured the following boot settings:

hypervisorlaunchtype    Off
vsmlaunchtype           Off

Confirmed that Intel hardware virtualization is enabled in BIOS.

Uninstalled VMware Workstation completely and confirmed that no VMware services remain.

Performed multiple restarts and verified that the disabled settings persist.

Current diagnostic results:

Despite the above changes, Windows continues reporting:

HypervisorPresent                      : True
VirtualizationBasedSecurityStatus      : 2
SecurityServicesConfigured             : {0}
SecurityServicesRunning                : {0}
CodeIntegrityPolicyEnforcementStatus   : 2
UsermodeCodeIntegrityPolicyEnforcementStatus : 2

Relevant registry settings are:

EnableVirtualizationBasedSecurity = 0
RequirePlatformSecurityFeatures   = 3
SystemGuard Enabled               = 0
HypervisorEnforcedCodeIntegrity Enabled = 0

Windows Event Viewer confirms that the hypervisor starts successfully.

On 23 October 2026 at 16:04:05, the Microsoft-Windows-Hyper-V-Hypervisor provider recorded:

Event ID: 1
Hypervisor successfully started.

Additional events include IDs 2, 129, 156 and 165, confirming hypervisor initialization and configuration.

Potentially relevant enforced policy:

Using CiTool.exe -lp -json, I identified the following enforced policy:

FriendlyName : Microsoft Windows Virtualization Based Security Policy
PolicyID     : a072029f-588b-4b5e-b7f9-05aad67df687
IsEnforced   : True

I appreciate that the presence of this policy does not necessarily establish that it is responsible for launching the hypervisor.

Impact:

VMware Workstation reports:

Virtualized Intel VT-x/EPT is not supported on this platform.
Feature 'hv.capable' was 0, but must be at least 0x1.
Module 'FeatureCompatLate' power on failed.

The VMware diagnostic log also contains:

IOPL_Init: Hyper-V detected by CPUID

Request for Microsoft support:

Could Microsoft please investigate and advise:

Why does the Microsoft hypervisor successfully initialize when hypervisorlaunchtype and vsmlaunchtype are both explicitly set to Off?

Could the enforced Microsoft Windows Virtualization Based Security Policy be contributing to this behaviour?

Is this a known issue with Windows 11 Build 26200, particularly on Intel Xeon workstation hardware?

What supported diagnostic procedure can identify the component or policy responsible for initiating the hypervisor?

Is there a supported method to completely disable the Microsoft hypervisor and VBS so VMware Workstation can access Intel VT-x/EPT directly?

This behaviour persists even after VMware has been uninstalled, indicating that the Microsoft hypervisor is operating independently of VMware.

I would appreciate a technical investigation rather than further recommendations to disable the standard Hyper-V features, as those steps have already been completed and verified repeatedly.

Chris Biggs 0 Reputation points

2026-10-27T10:05:52.0666667+00:00

Hi,

I don't know how much this will help, but I have/had a similar problem.

I have windows 11 pro with all the latest patches. I am using VMWare 26.0.0.25388281. Recently the performance of the guest servers (all windows 2022 servers) had diminished to frustratingly slow.

I asked CHATGPT to help and ran various diagnostic commands and installed Windows SDK at its request - all of which proved fruitless. Eventually it referenced your question and the answer from VPHAN to suggest things I could try.

I decided I would try Hyper-V rather than VMWare. The first step was to enable the Hyper-V features and reboot. This I did. On restart I ran bcdedit just to see what it said and it now has hypervisorlaunchtype set to auto - like your environment, this was previously set to off.

I restarted one of my guests and immediately could see that it was performing significantly better. Why this should have made any difference is beyond me but I am pretty sure I didn't make any other changes apart from install Windows SDK, turn on all the Hyper-V features and restarted.

If this helps you, I would be delighted.

Regards,

Chris

2 answers

Your answer

Chris Biggs 0 Reputation points

2026-10-27T10:05:52.0666667+00:00

Hi,

I don't know how much this will help, but I have/had a similar problem.

I have windows 11 pro with all the latest patches. I am using VMWare 26.0.0.25388281. Recently the performance of the guest servers (all windows 2022 servers) had diminished to frustratingly slow.

I asked CHATGPT to help and ran various diagnostic commands and installed Windows SDK at its request - all of which proved fruitless. Eventually it referenced your question and the answer from VPHAN to suggest things I could try.

I decided I would try Hyper-V rather than VMWare. The first step was to enable the Hyper-V features and reboot. This I did. On restart I ran bcdedit just to see what it said and it now has hypervisorlaunchtype set to auto - like your environment, this was previously set to off.

I restarted one of my guests and immediately could see that it was performing significantly better. Why this should have made any difference is beyond me but I am pretty sure I didn't make any other changes apart from install Windows SDK, turn on all the Hyper-V features and restarted.

If this helps you, I would be delighted.

Regards,

Chris

Answer 1

Hi Chris Nelis,

The reason the Microsoft hypervisor continues to initialize and block VMware Workstation from accessing Intel VT-x/EPT is that Virtualization-Based Security has been provisioned with a UEFI Lock. When features like VBS or Credential Guard are protected at this firmware level, their configuration is written directly to the motherboard's protected EFI variables in NVRAM. The Windows Boot Manager is intentionally designed to ignore operating system-level registry modifications or Boot Configuration Data commands when this lock is present to prevent malicious software from bypassing hypervisor-enforced protections. Your registry query returning a value of three for RequirePlatformSecurityFeatures confirms that System Guard Secure Launch is active. This feature anchors itself in the hardware firmware and mandates hypervisor initialization before the Windows kernel even loads.

You must clear the EFI variables overriding your local configurations. The supported method to break this lock requires a physical presence check through your Dell Precision firmware settings by temporarily disabling Secure Boot. Booting into Windows just once with Secure Boot disabled forces the bootloader to invalidate and discard the protected VBS and Credential Guard EFI variables. This drops the firmware-level lock and allows your existing configurations setting the hypervisorlaunchtype to off to finally execute. Once you confirm the hypervisor is completely disabled in the Windows Event Viewer and VMware functions correctly, you can safely restart and re-enable Secure Boot in your BIOS to restore your standard boot security.

Hope this answer has brought you some useful information. If it did, please hit “accept answer”. Should you have any questions, feel free to leave a comment.

VPHAN

Answer 2

The supported explanation in the available documentation is that this is by design when the Windows hypervisor is active.

Third-party virtualization applications such as VMware and VirtualBox cannot run alongside Hyper-V, Memory Integrity, or Credential Guard.
Only one software component at a time can use the processor virtualization extensions such as Intel VT-x and AMD-V.
When the Windows hypervisor is running, VMware cannot access VT-x/EPT directly, so nested virtualization features that depend on direct hardware access fail.

For the current state validation, the supported checks are:

Run Msinfo32.exe and inspect Virtualization-based security. If it shows Running, VBS is enabled and running.
In an elevated Windows PowerShell session, run:
```
   Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard
```
Interpret VirtualizationBasedSecurityStatus as:
- 0 = VBS is not enabled
- 1 = VBS is enabled but not running
- 2 = VBS is enabled and running

Based on the reported VirtualizationBasedSecurityStatus : 2 and the Hyper-V hypervisor start event, the supported conclusion is that VBS is enabled and running on the system, and that is sufficient to block direct coexistence with VMware’s use of VT-x/EPT.

The supported way to make third-party virtualization software work correctly is to disable Hyper-V and its dependent security features. The documentation explicitly includes Memory Integrity and Credential Guard in that conflict set. If those features remain active, VMware may fail to start VMs or fall back to slower emulation.

The available documentation does not provide support for these specific conclusions:

why the hypervisor starts when hypervisorlaunchtype and vsmlaunchtype are set to Off
whether the enforced Microsoft Windows Virtualization Based Security Policy is the component causing startup
whether this is a known issue specific to Windows 11 Build 26200 or Intel Xeon workstation hardware
a supported diagnostic procedure that identifies the exact component or policy that initiated the hypervisor

It does support this practical outcome: if VBS is required for the workload, direct VT-x/EPT access for VMware is not available on the same running Windows instance. If direct VMware access to Intel VT-x/EPT is required for Cisco Modeling Labs, the Windows hypervisor and dependent VBS features must not be running.