Windows 11 Home Hypervisor Remains On Error & Cannot Be Closed

Question

Windows 11 Home Hypervisor Remains On Error & Cannot Be Closed

NPLGlitcherPatcher 350

Windows 11 Home Hypervisor Remains On Error & Cannot Be Closed

Operating System Name: Windows 11 Home

Version: 26200.9278

How did it start?

Windows 11 was installed with virtualization enabled on an AMD processor.**

What's the problem?

Boot time is significantly longer when virtualization is enabled.

Therefore, the Memory Integrity feature in Windows Defender was disabled and the system was restarted.

Although this reduced boot time, the Windows 11 system still gives the following error code when virtualization mode is disabled:

"Virtual Safe Mode (VSM) could not be started during the check to enable the virtualization-based security policy in step 0. The hypervisor or VSM may not have been found or enabled."

This situation is not observed in the same way when Windows 11 is installed with virtualization disabled.

Things tried to fix this:

Disabling the hypervisor with bcdedit,

Making the necessary settings in the registry (correct method), Checking Windows Defender.

Despite these measures, the problem persists.

Also, there is no corruption or malfunction in the system files.

The system has been installed in a stable and proper manner. (A secure erase operation was performed on the disk.)
Given that the Hypervisor shouldn't normally remain open for this long, is there anyone who can show me how to fix this situation?

0 comments

1 answer

Your answer

Answer 1

Kai-H 26,135 Microsoft External Staff Moderator

Hi, NPLGlitcherPatcher

This message usually does not mean the hypervisor is still running. It means Windows tried to start VSM because a virtualization-based security component is still configured, but AMD virtualization was disabled in UEFI, so the check failed.

Here are some suggestions you can try:

Press Windows key + R, enter msinfo32, and check Virtualization-based security. If it says Not enabled and there is no “hypervisor detected” message, the hypervisor is already off. The Event Viewer entry can be ignored.

Open Turn Windows features on or off and clear any enabled items named Virtual Machine Platform, Windows Hypervisor Platform, Windows Sandbox, and Windows Subsystem for Linux. Restart afterward.

Open Terminal as administrator and run:

bcdedit /set hypervisorlaunchtype off

bcdedit /set vsmlaunchtype off

Then perform a full shutdown, not only a restart:

shutdown /s /t 0

Install the latest BIOS and AMD chipset driver from the PC or motherboard manufacturer. Firmware settings can affect whether Windows correctly detects AMD-V and IOMMU.

Build 26200.9278 is also from the KB5120998 preview update. Since no matching known issue is currently listed, avoid deleting VBS policy files or additional protected system files.

Thank you for your patience in reading, I hope this information has been helpful to you.

If the answer is helpful, please click "Yes" and kindly upvote it. If you have extra questions about this answer, please click "Comment."

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

NPLGlitcherPatcher 350 Reputation points

2026-08-31T09:10:00.68+00:00

Hello @Kai-H!,

Thank you for your response.

I have already applied all the steps you mentioned, including disabling virtualization features, checking DISM, disabling VBS/HVCI, and confirming that no VM‑related components are active.

However, the issue persists.

The main problem is that Windows 11 Home is incorrectly detecting the hypervisor as active, even when all virtualization features are disabled.

In msinfo32, the line “A hypervisor has been detected” appears consistently. This indicates that the hypervisor was forcibly triggered, not intentionally enabled.

After further testing, I found that:

Installing Windows 11 with virtualization enabled causes the system to enter a state where the hypervisor is permanently marked as active.

Even if virtualization is disabled afterwards (BIOS + Windows), the hypervisor state remains cached and continues to be reported as active.

This suggests a boot‑chain bug in Windows 11 Home where the hypervisor/VSM state is not cleared correctly.

All chipset, storage, and platform drivers are up‑to‑date. BIOS/UEFI is also the latest version.

Instead of reinstalling or performing an in‑place upgrade, I would like to understand:

Which component is responsible for caching the hypervisor/VSM state, and at what stage of the boot process this detection occurs?

Any information about how Windows 11 Home handles hypervisor state persistence would be very helpful.

Thank you.
Kai-H 26,135 Reputation points Microsoft External Staff Moderator

2026-09-01T06:16:36.15+00:00

Hi, NPLGlitcherPatcher

Thank you for clarifying. I would be careful about calling this a cached-state bug, because the available documentation does not identify a persistent cache that controls the “hypervisor detected” result.

The decision to launch the hypervisor is made during the early boot process. Windows Boot Manager and the OS loader read the BCD settings and applicable VBS or Code Integrity policies before the normal Windows kernel starts. The msinfo32 message is then based on the current runtime state reported by Windows, rather than a saved result from the original installation. BCD Boot Configuration Data confirms that BCD controls the boot sequence and settings used by the OS loader.

Since msinfo32 still detects the hypervisor, something is loading it during boot, even if the usual optional features and registry switches are off. A boot-level App Control or Code Integrity policy is one possibility, but this cannot be confirmed from msinfo32 alone.

For a more reliable diagnosis, install the current Windows SDK and run SkTool.exe /status as administrator. This tool displays the Hypervisor and Secure Kernel state and, importantly, the reason VBS was started.

I would recommend sharing the complete SkTool output, plus:

bcdedit /enum all

Without that diagnostic output, it is not possible to confirm whether this is a Windows 11 25H2 regression or an active boot policy.

NPLGlitcherPatcher 350

Hi @Kai-H

sktool.exe could not be found on the Windows SDK despite a normal installation.

Therefore, I'm showing you all the boot sections of bcdedit:

C:\Windows\System32>bcdedit /enum all
Firmware Boot Manager
---------------------
identifier {fwbootmgr}
displayorder {bootmgr}
{ce234ffa-a47a-11f1-9888-806e6f6e6963}
{ce234ffb-a47a-11f1-9888-806e6f6e6963}
{ce234ffc-a47a-11f1-9888-806e6f6e6963}
timeout 1
Windows Boot Manager
--------------------
identifier {bootmgr}
device partition=\Device\HarddiskVolume1
path \EFI\MICROSOFT\BOOT\BOOTMGFW.EFI
description Windows Boot manager
locale tr-tr
inherit {globalsettings}
default {current}
resumeobject {dd5088d2-a477-11f1-8d12-b2fd5411bab3}
displayorder {current}
toolsdisplayorder {memdiag}
time out 30
Firmware Application (101fffff)
----------------------------
identifier {ce234ffa-a47a-11f1-9888-806e6f6e6963}
description UEFI:CD/DVD Drive
Firmware Application (101fffff)
----------------------------
identifier {ce234ffb-a47a-11f1-9888-806e6f6e6963}
description UEFI:Removable Device
Firmware Application (101fffff)
----------------------------
identifier {ce234ffc-a47a-11f1-9888-806e6f6e6963}
description UEFI:Network Device
Windows Bootloader
-------------------
identifier {current}
device partition=C:
path\Windows\system32\winload.efi
description Windows 11
locale tr-tr
inherit {bootloadersettings}
isolatedcontext Yes
allowedinmemorysettings 0x15000075
osdevice partition=C:
systemroot\Windows
resumeobject {dd5088d2-a477-11f1-8d12-b2fd5411bab3}
nx OptIn
bootmenupolicyStandard
Resume from Hibernate
---------------------
identifier {dd5088d2-a477-11f1-8d12-b2fd5411bab3}
device partition=C:
path\Windows\system32\winresume.efi
description Windows Resume Application
locale tr-tr
inherit {resumeloadersettings}
isolatedcontext Yes
allowedinmemorysettings 0x15000075
filedevice partition=C:
custom:21000026 partition=C:
filepath \hiberfil.sys
bootmenupolicyStandard
debugooptionenabled No
Windows Memory Tester
---------------------
identifier {memdiag}
device partition=\Device\HarddiskVolume1
path \EFI\Microsoft\Boot\memtest.efi
description Windows Memory Diagnostics
locale tr-tr
inherit {globalsettings}
badmemoryaccess Yes
EMS Settings
------------
identifier {emssettings}
bootem number
Debugger Settings
-----------------
identifier {dbgsettings}
debugtype Local
RAM Defects
-----------
identifier {badmemory}
Global Settings
---------------
identifier {globalsettings}
inherit {dbgsettings} 
{emssettings} 
{badmemory}
Boot Loader Settings
--------------------
identifier {bootloadersettings}
inherit {globalsettings} 
{hypervisorsettings}
Hypervisor Settings
-------------------
identifier {hypervisorsettings}
hypervisordebugtype Serial
hypervisordebugport 1
hypervisorbaudrate 115200
Resume Loader Settings
----------------------
identifier {resumeloadersettings}
inherit {globalsettings}
C:\Windows\System32>

As seen here, the hypervisor line appears to be present.

This indicates that the VBS/hypervisor is triggered during system boot.

Even after resetting the entire BCD (S:) using bcdboot + diskpart on WinRE, the problem persists.

I suspect this might be due to a flag remaining in the registry, and the system installation with the "SVM: enable" setting left open in the BIOS/UEFI settings seems to have caused this.

The following additional lines should be shown as registry entries:

C:\Windows\System32>reg query HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard
    CachedDrtmAuthIndex    REG_DWORD    0x0
    RequireMicrosoftSignedBootChain    REG_DWORD    0x1
    WasEnabledBy    REG_DWORD    0x1
    EnableVirtualizationBasedSecurity    REG_DWORD    0x1
    HyperVVirtualizationBasedSecurityOptout    REG_DWORD    0x0

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios

C:\Windows\System32>reg query "HKLM\SYSTEM\CurrentControlSet\Control\CI\Policy"

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CI\Policy
    EmodePolicyRequired    REG_DWORD    0x0
    SkuPolicyRequired    REG_DWORD    0x0
    VerifiedAndReputablePolicyState    REG_DWORD    0x0
    SAC_PreviousState    REG_DWORD    0x2
    SAC_EnforcementReason    REG_DWORD    0x6


C:\Windows\System32>reg query "HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot\State"

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\State
    UEFISecureBootEnabled    REG_DWORD    0x1
    PolicyPublisher    REG_SZ    {77fa9abd-0359-4d32-bd60-28f4e78f784b}
    PolicyVersion    REG_DWORD    0x1


C:\Windows\System32>

The Event Viewer (eventvwr.msc) shows the following: Windows Logs > System Lines related to VBS/hypervisor:

1-) (eventlog) Hypervisor started successfully.

2-) (eventlog) Hypervisor scheduler type is 0x4.

3-) (eventlog) Hypervisor has started I/O remapping. Hardware available: true Hardware enabled: true Policy: 0x0 Enabled properties: 0x34A Internal information: 0x0 Issues: 0x0 Additional information: 0x0

4-) (eventlog) Hypervisor-configured mitigations for CVE-2018-3646 for virtual machines. Processor unaffected: false Processor family unaffected: false Processor supports cache clearing: false HyperThreading enabled: true Top hypervisor applies mitigations: false Bcdedit: false Mitigations enabled: true Cache clearing required: false

5-) (eventlog) Hypervisor configured mitigations for CVE-2019-11091, CVE-2018-12126, CVE-2018-12127, CVE-2018-12130 for virtual machines. Processor unaffected: false Processor family unaffected: false Processor supports micro-hierarchical buffer clearing: false Buffer clearing required: false

Based on these situations, it appears that a registry flag or bcdedit setting triggered the hypervisor error.

What steps can I take to fix this error?

Another finding prior to formatting:

I previously encountered the same error loop when I installed and then uninstalled WSL2.

This also significantly prolonged the boot process when SMV and memory integrity were enabled.

Kai-H 26,135 Reputation points Microsoft External Staff Moderator

2026-09-02T06:30:48.6966667+00:00

Hi, NPLGlitcherPatcher

The {hypervisorsettings} section only stores debugger defaults and is inherited normally. It does not start Hyper-V. The important finding is EnableVirtualizationBasedSecurity = 1, which explicitly requests VBS during early boot; the Event Viewer entries confirm the hypervisor actually started.

Back up the key, then disable the VBS request from an elevated Command Prompt:

reg export "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" "%USERPROFILE%\Desktop\DeviceGuard.reg"

reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v EnableVirtualizationBasedSecurity /t REG_DWORD /d 0 /f

bcdedit /set {current} hypervisorlaunchtype off

Confirm that HVCI is also disabled:

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

Disable hibernation temporarily so Windows performs a clean boot rather than restoring an earlier kernel state:

powercfg /h off

shutdown /s /t 0

Leave CachedDrtmAuthIndex, RequireMicrosoftSignedBootChain, and Secure Boot values unchanged. Do not delete the {hypervisorsettings} BCD object.

If EnableVirtualizationBasedSecurity returns to 1 after boot, list active boot policies with CiTool.exe --list-policies. An enforced Code Integrity policy may be reapplying VBS, particularly on current Windows 11 25H2 builds.
NPLGlitcherPatcher 350 Reputation points

2026-09-02T14:57:35.2533333+00:00
Hi, @Kai-H

I followed your instructions to the letter.

However, things didn't go as expected, and since the error persisted, I've reverted to the registry backup I created.

Regarding other actions taken:

I performed the "EC Power Drain" operation because I suspected that SVM might actually be a cache
during startup.

I reset the BIOS/UEFI settings, loaded the default settings, and disabled the SVM setting. I also deleted all keys in secure boot and reinstalled the default secure boot keys.

Even though I deleted the hypervisor layer via bcdedit, the constant forced boot of the hypervisor in the event viewer suggests that this might be a bug specific to Windows 11 Home.

I'll explain the WSL2 issue in more detail:

I had previously installed WSL2, then uninstalled it.

But this time, the system forced VBS to boot, and the boot time increased significantly.

I hadn't been able to resolve this issue before either.

Also, hyperfil.sys has been disabled for months on my end; I never use it because I don't need fast startup, so powercfg /h off is a step I take after installing the system.

Based on these situations, is this really a chronic problem with the system, or is it a bug?

Another finding:

Today, while SMV was enabled and this error occurred, I tried to run VMware Workstation Pro 26h1, but the virtual machine failed and couldn't start at all. (The same thing didn't happen when I tried running a virtual machine with SMV enabled before.)
Kai-H 26,135 Reputation points Microsoft External Staff Moderator

2026-09-03T06:32:05.21+00:00

Hi, NPLGlitcherPatcher

This does not look like an EC or firmware cache. Your Event Viewer records confirm that the Windows hypervisor is genuinely loading. However, there is currently not enough evidence to classify this as a confirmed Windows 11 Home bug. Similar behavior has been raised on Windows 11 25H2, but no official regression or fix has been documented in that thread.

Keep SVM enabled in UEFI when testing VMware. VMware requires AMD-V, so disabling SVM will prevent the virtual machine from starting regardless of the Windows hypervisor state.

Check the VM folder’s vmware.log immediately after the failure. Search for Monitor Mode, VBS, WHP, AMD-V, or Module 'MonitorMode' power on failed. Broadcom confirms that VBS/Hyper-V can reserve hardware virtualization and prevent VMware from starting or force it into the slower Windows Hypervisor Platform mode.

Since the registry, BCD, firmware, and Windows features have already been tested, I would not recommend further registry deletion. Please report this through Feedback Hub > System and Settings > Virtualization, include the Event Viewer export, msinfo32, bcdedit /enum all, and VMware’s exact error plus vmware.log.

At this point, this should be treated as a possible 25H2 compatibility or policy issue requiring log analysis, not as a proven persistent cache.
NPLGlitcherPatcher 350 Reputation points

2026-09-03T06:54:39.51+00:00

Hi @Kai-H

Even though I've enabled SVM, the hypervisor is still trying to start and is preventing me from even creating virtual machines. And despite other measures I've taken today, VSM still won't shut down.

Do you know of a way to actually fix this?
Kai-H 26,135 Reputation points Microsoft External Staff Moderator

2026-09-04T06:29:42.7066667+00:00

Hi, NPLGlitcherPatcher

At this point, the remaining likely cause is a VBS or Credential Guard UEFI variable, which ordinary registry and BCD changes cannot remove. The supported approach is to start SecConfig.efi once and physically confirm removal before Windows loads.

Back up your BitLocker or Device Encryption recovery key first, even if encryption appears inactive.

Keep SVM enabled, then run these commands in Command Prompt as administrator:

mountvol X: /s

copy %WINDIR%\System32\SecConfig.efi X:\EFI\Microsoft\Boot\SecConfig.efi /Y

bcdedit /create {0cb3b571-2f2e-4343-a879-d86a476d7215} /d "Disable VBS" /application osloader

bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} path "\EFI\Microsoft\Boot\SecConfig.efi"

bcdedit /set {bootmgr} bootsequence {0cb3b571-2f2e-4343-a879-d86a476d7215}

bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} loadoptions DISABLE-LSA-ISO,DISABLE-VBS

bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} device partition=X:

mountvol X: /d

shutdown /r /t 0

During the pre-boot prompt, confirm both changes using the displayed function key. Missing this confirmation leaves the UEFI variables unchanged.

After Windows starts, verify with msinfo32. If the hypervisor still loads after this exact process, stop making registry or Secure Boot changes. That would require escalation with boot diagnostics, since no confirmed VBS persistence bug is currently listed on Windows 11, version 25H2 known issues and notifications.
NPLGlitcherPatcher 350 Reputation points

2026-09-05T06:20:58.5333333+00:00

Hi @Kai-H

I have followed your instructions precisely and confirmed everything, including the confirmation screen.

However, despite this, the "hypervisor starting attempt" error still appears in the Event Viewer, and I've noticed that this might be specific to Windows 11 Home, and the lack of Pro management tools significantly restricts it.

I suspect this might be an unreported, unexplained error rather than a chronic problem.

Just like this BSOD:

https://learn.microsoft.com/en-us/answers/questions/3864605/im-getting-an-inexplicable-bsod-in-windows-11

I've experienced this BSOD myself, and this situation alone shows that there might be undocumented errors in Windows 11.
Kai-H 26,135 Reputation points Microsoft External Staff Moderator

2026-09-09T06:47:10.8866667+00:00

Hi, NPLGlitcherPatcher

I understand why you suspect an undocumented Windows issue. However, the separate BSOD example does not prove that the VBS behavior is a Windows 11 Home bug. In that case, 0xC000A003 was identified as STATUS_INVALID_STATE_TRANSITION, which exists in the public Windows headers even though it was missing from the referenced online error-code page. I'm Getting an Inexplicable BSOD in Windows 11

At this stage, you have already exhausted the supported methods, including removing Hyper-V-dependent features, disabling VBS/HVCI, changing BCD, clearing the UEFI variables through SecConfig.efi, and performing a cold boot. Repeating those changes or deleting protected policy files is unlikely to help and could make Windows unbootable.

The next step is to collect proof of which boot policy starts the hypervisor:

CiTool.exe --list-policies

Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard | Format-List *

Also export Microsoft-Windows-Hyper-V-Hypervisor/Admin, Kernel-Boot, and the VMware vmware.log. The VMware failure is consistent with Hyper-V or a Hyper-V-based security feature already owning AMD-V. This interaction is documented as by design, but the failure of all supported disable methods is not enough to identify the responsible policy locally.

I recommend submitting these logs through Feedback Hub and opening a Microsoft support case for boot-trace analysis. Until the initiating policy is identified, there is no further safe registry or BCD fix I can recommend.
NPLGlitcherPatcher 350 Reputation points

2026-09-09T08:47:40.0233333+00:00

Hi, @Kai-H

Thank you for your reply.

The items to be displayed in the PowerShell output are as follows:

[PII removed]

The other PowerShell command is listed below:

[PII removed]
Kai-H 26,135 Reputation points Microsoft External Staff Moderator

2026-09-10T06:52:59.9033333+00:00

(Since this is a public forum, we will hide your personal identifiable information, and I have sent that code block of yours containing your personal identifiable information in a private message so we can work together to resolve the issue. Also, please check your private message in case you want to share other information to avoid leaking your PII by click on the Private Message button)

Hi, NPLGlitcherPatcher

Thank you, this output finally identifies the important distinction. VBS is genuinely running, because VirtualizationBasedSecurityStatus : 2 explicitly means enabled and running. However, Credential Guard and Memory Integrity are not the active consumers, since both SecurityServicesConfigured and SecurityServicesRunning contain only 0. Guidance for blocking rollback of Virtualization-based Security related security updates confirms the meaning of status 2.

The significant item is:

Microsoft Windows Virtualization Based Security Policy

Is Currently Enforced: true

Is Authorized: true

This matches another Windows 11 25H2 case with the same combination: VBS status 2, no configured or running security services, and the Microsoft VBS, Endpoint Security, and Driver policies enforced. Windows 11 25H2: Hypervisor detected and VBS running despite Hyper-V, VBS, Credential Guard disabled

Also, Windows 11 24H2 and later include a default boot-session VBS Code Integrity policy for rollback protection. The policy is serviced together with Windows components, and copying, replacing, or removing the wrong policy can prevent Windows from starting.

Therefore, I would not delete .cip, .p7b, or Code Integrity files, and I would not try to remove those platform policies with CiTool. The other enforced Windows Driver, Endpoint Security, and cross-certificate policies appear to be Microsoft-signed platform policies, not leftover WSL components.

At this point, your evidence supports a boot-session platform policy keeping VBS active, rather than a cached SVM setting. Whether the hypervisor behavior on this particular Windows 11 Home build is intended or a regression cannot be determined from these local tools. Since the supported disable procedures have already failed, this now requires Microsoft boot-policy analysis or a servicing fix.