Skip to content

[HCS/Hyper-V] HCS_E_HYPERV_NOT_INSTALLED on Windows 11 26H2 despite HypervisorPresent=True #41920

New issue
New issue
Closed
Closed
[HCS/Hyper-V] HCS_E_HYPERV_NOT_INSTALLED on Windows 11 26H2 despite HypervisorPresent=True#41920
Labels
wsl2Issue/feature applies to WSL 2

Description

@benny1232123
Xie Zhenyu (benny1232123)
opened on Oct 14, 2026

Windows Version

Windows 11 version 26H2, build 26300.9711

WSL Version

3.0.3.0

Are you using WSL 1, WSL 2, or WSLC?

  • WSL 2
  • WSL 1
  • WSLC

Kernel Version

No response

Distro Version

No response

Other Software

No response

Repro Steps

On an ASUS TUF Gaming A16 FA607PV with an AMD Ryzen 9 7940HX CPU, running Windows 11 26H2 (build 26300.9711), ensure that hardware virtualization is enabled and the following Windows features are enabled:

Hyper-V

Virtual Machine Platform

Windows Hypervisor Platform

Windows Subsystem for Linux

Open an elevated PowerShell terminal and run:

wsl --install -d Ubuntu-22.04

Observe that Ubuntu downloads successfully, but WSL fails when registering the distribution and creating its virtual machine.

To verify that the issue is not specific to WSL or Ubuntu, create a basic Hyper-V virtual machine without a virtual hard disk or network adapter:

$name = "HCS-Diag-Test"

New-VM -Name $name -Generation 2
-MemoryStartupBytes 512MB -NoVHD
-Path "$env:ProgramData\Microsoft\Windows\Hyper-V"

Get-VMNetworkAdapter -VMName $name |
Remove-VMNetworkAdapter

Start-VM -Name $name

Observe that the standalone Hyper-V VM also fails to start with an error stating that a Hyper-V component is not running.

Check the host state:

Get-CimInstance Win32_ComputerSystem |
Select-Object HypervisorPresent

hcsdiag hostproperties processortopology

HypervisorPresent is True, and the processor topology query succeeds.

Expected Behavior

Ubuntu 22.04 installs successfully and the WSL2 distribution starts.

A basic Hyper-V virtual machine can start successfully.

The Host Compute Service (HCS) recognizes the running Windows hypervisor and successfully creates the required compute system.

Actual Behavior

WSL fails during distribution registration and virtual machine creation with:

Wsl/InstallDistro/Service/RegisterDistro/CreateVm/HCS/HCS_E_HYPERV_NOT_INSTALLED

Error code: 0x80370102

The message claims that virtualization is not enabled or Hyper-V is not installed, even though:

HypervisorPresent = True.

hypervisorlaunchtype is Auto.

Hyper-V, Virtual Machine Platform, Windows Hypervisor Platform, and WSL features are enabled.

The vmcompute, vmms, HvHost, hvservice, and WslService services are running.

Hyper-V infrastructure devices, including ROOT\VID\0000 and ROOT\VMBus\0000, report Started.

DISM reports no component-store corruption, and SFC reports no integrity violations in the checked Hyper-V system files.

Updating Windows from build 26300.9457 to 26300.9711 did not resolve the issue.

Disabling and re-enabling Virtual Machine Platform did not resolve the issue.

The standalone Hyper-V VM fails with:

The virtual machine could not be started because a Hyper-V component is not running.

Hyper-V Compute Operational event 2000 reports a compute-system creation result of 0x80370102, and Hyper-V Compute Admin event 11008 reports that Hyper-V is not installed on the host.

An earlier WSL ETL trace also recorded an exception in vmcompute.exe at capabilityhelpers.cpp(258) with error 0x80070001. Further investigation is needed to identify the underlying failure.

Diagnostic Logs

No response

Activity

  1. github-actions commented on Oct 14, 2026

    @github-actions
    github-actionsBot
    on Oct 14, 2026 – with GitHub Actions
    Contributor

    Logs are required for review from WSL team

    If this a feature request, please reply with '/feature'. If this is a question, reply with '/question'.
    Otherwise, please attach logs by following the instructions below, your issue will not be reviewed unless they are added. These logs will help us understand what is going on in your machine.

    How to collect WSL logs

    Download and execute collect-wsl-logs.ps1 in an administrative powershell prompt:

    Invoke-WebRequest -UseBasicParsing "https://raw.githubusercontent.com/microsoft/WSL/master/diagnostics/collect-wsl-logs.ps1" -OutFile collect-wsl-logs.ps1
Set-ExecutionPolicy Bypass -Scope Process -Force
.\collect-wsl-logs.ps1

    The script will output the path of the log file once done.

    If this is a networking issue, please use .\collect-wsl-logs.ps1 -LogProfile networking instead, following the instructions in Collect WSL logs for networking issues

    Once completed please upload the output files to this GitHub issue.

    See Collect WSL logs (recommended method).

    If you choose to email these logs instead of attaching them to the bug, please send them to wsl-gh-logs@microsoft.com with the GitHub issue number in the subject, and include a link to your GitHub issue comment in the message body, and reply with '/emailed-logs'.

  2. github-actions
    added
    needs-author-feedback
    on Oct 14, 2026

  3. benny1232123 commented on Oct 14, 2026

    @benny1232123
    Xie Zhenyu (benny1232123)
    on Oct 14, 2026
    Author

    WslLogs-2026-10-14_21-24-07.tar.gz

    Attached the WSL diagnostic logs collected on October 14, 2026, after reproducing the issue on Windows build 26300.9711.

    The issue persists after updating Windows, verifying system file integrity, and re-enabling Virtual Machine Platform. A standalone Hyper-V test VM without a virtual hard disk or network adapter also fails to start with the message that a Hyper-V component is not running.

    The logs are attached for further investigation. Thank you.

  4. github-actions commented on Oct 14, 2026

    @github-actions
    github-actionsBot
    on Oct 14, 2026 – with GitHub Actions
    Contributor

    The log file doesn't contain any WSL traces. Please make sure that you reproduced the issue while the log collection was running.

    Diagnostic information 
    .wslconfig found
Failed to parse .wslconfig: expecting "[Some('='), Some(':')]" but found EOF.[wsl2]

Detected appx version: 3.0.3.0
Found no WSL traces in the logs
  5. microsoft-github-policy-service
    removed
    needs-author-feedback
    on Oct 14, 2026

  6. benny1232123 commented on Oct 14, 2026

    @benny1232123
    Xie Zhenyu (benny1232123)
    on Oct 14, 2026
    Author

    WslLogs-2026-10-14_23-30-28.tar.gz
    I recollected the diagnostic logs and reproduced the WSL installation failure while the logging session was actively running. I also reproduced the Hyper-V VM startup failure during the same session. The newly collected diagnostic archive is attached.

  7. github-actions commented on Oct 14, 2026

    @github-actions
    github-actionsBot
    on Oct 14, 2026 – with GitHub Actions
    Contributor
    Diagnostic information 
    .wslconfig found
Failed to parse .wslconfig: expecting "[Some('='), Some(':')]" but found EOF.[wsl2]

Detected appx version: 3.0.3.0
Detected user visible error: Wsl/InstallDistro/Service/RegisterDistro/CreateVm/HCS/HCS_E_HYPERV_NOT_INSTALLED
  8. David Bennett (dkbennett)
    added
    wsl2Issue/feature applies to WSL 2
    on Oct 14, 2026

  9. mohandtest commented on Oct 14, 2026

    @mohandtest
    Mohand (mohandtest)
    on Oct 14, 2026

    Had the same issue. For now you'll need to uninstall the update KB5127648 to solve it until Microsoft fixes it.

  10. benhillis commented on Oct 15, 2026

    @benhillis
    Ben Hillis (benhillis)
    on Oct 15, 2026
    Member

    /hyperv

  11. microsoft-github-policy-service commented on Oct 15, 2026

    @microsoft-github-policy-service
    microsoft-github-policy-serviceBot
    on Oct 15, 2026 – with Microsoft GitHub Policy Service
    Contributor

    Thank you for reporting this issue. Since this issue is specific to Hyper-V and not WSL, could you please report it in Feedback Hub? Go to "Report a problem" and then choose Apps > Hyper-V.

  12. microsoft-github-policy-service
    closed this as completedon Oct 15, 2026

  13. anonymoosemagoose commented on Nov 5, 2026

    @anonymoosemagoose
    anonymoosemagoose
    on Nov 5, 2026

    Same symptom here — root-caused and fixed.
    For me it was a third-party filter driver on the VID device stack, not Windows.

    Machine: Windows 11 Pro 26H2 (26300.9818), Ryzen 7 9800X3D, ASUS X670E-E. Every VM failed with 0x80370102 / HCS event 11008 "Hyper-V is not installed on the host", plus VMMS event 15350 "The virtualization infrastructure driver (VID) is not running". Windows Sandbox, a plain Hyper-V VM, and a WSL2-style utility VM all died identically. Hypervisor was provably running (HypervisorPresent=True, SkTool all green, IOMMU fine).

    What did NOT fix it (all verified correct, so skip these): BIOS SVM, hypervisorlaunchtype, VBS/Memory Integrity on or off, DISM/SFC (clean), disabling and re-enabling every Hyper-V/VMP/WHP feature with reboots, BIOS update, cumulative/preview updates, uninstalling updates. Status tools cannot see this problem.

    What the failure actually is. An ETW trace of the Hyper-V providers across a Restart-Service vmcompute, vmms shows the one real error, 1 ms before every 11008/15350:

    Microsoft-Windows-Hyper-V-VID Function=VidGetPartitionProperty viddll.c(3128)
    Error=1 IOCTL=VidIoctlDualGetPartitionProperty

    Error 1 = ERROR_INVALID_FUNCTION: something answering that IOCTL on VID's behalf doesn't know it. Meanwhile the hypervisor itself was fine — WHvCreatePartition + WHvSetupPartition (winhvplatform.dll) succeeded from both an admin account and SYSTEM. So HCS/VMMS's "is Hyper-V installed" check was failing on a request that never reached Vid.sys.

    The culprit — 5-second check:

    pnputil /enum-devices /instanceid "ROOT\VID\0000" /stack

    (If that instance ID isn't found, get yours with pnputil /enum-devices /class System | findstr /i "ROOT\VID".) Healthy output is Stack: Vid / PnpManager. Mine was:

    Stack: nipbcfk
    Vid
    PnpManager

    nipbcfk.sys = National Instruments NI-PAL 2.0 (2007-era) "PCI bus configuration filter", registered as an UpperFilter on the whole System device class {4d36e97d-e325-11ce-bfc1-08002be10318} — which contains Hyper-V's VID device. A 2007 filter sitting in front of a 2026 driver, rejecting an IOCTL it predates. It came in with Fieldpiece Firmware Update (an instrument-vendor tool built on NI-VISA 4.1). Hyper-V had been dead on this box since the day that was installed; I only noticed when a tool needed it.

    To see who's registered on the class:

    powershell
    foreach ($c in Get-ChildItem 'HKLM:\SYSTEM\CurrentControlSet\Control\Class') {
    $p = Get-ItemProperty $c.PSPath -ErrorAction SilentlyContinue
    if ($p.UpperFilters -or $p.LowerFilters) { "{0} [{1}] Upper={2} Lower={3}" -f $c.PSChildName, $p.Class, ($p.UpperFilters -join ','), ($p.LowerFilters -join ',') } }

    Anything non-Microsoft on {4d36e97d-…} (System) is a suspect.

    Fix: uninstall the product that owns the filter (NI Uninstaller → NI-VISA Runtime → Remove All). Verify the class UpperFilters entry, the Services\nipbcfk key and the .sys file are all gone, then reboot. Stack now reads Vid / PnpManager; Sandbox and Hyper-V VMs start.

    ⚠ Do NOT disable the filter with sc config … start= disabled and reboot. A System-class filter is also on the boot disk's stack; mine went straight to INACCESSIBLE_BOOT_DEVICE (0x7B). (Recovery if you already did: WinRE → Command Prompt → reg load HKLM\OFF C:\Windows\System32\config\SYSTEM (the Windows drive may not be C: in WinRE — check with dir), then reg add HKLM\OFF\ControlSet001\Services<driver> /v Start /t REG_DWORD /d 0 /f, reg unload HKLM\OFF, reboot, then uninstall properly.)

    If your /stack output shows something other than Vid / PnpManager, you have the same class of problem, whatever the driver's name. Worth running before another reinstall.

    hope this helps

  14. benny1232123 commented on Nov 15, 2026

    @benny1232123
    Xie Zhenyu (benny1232123)
    on Nov 15, 2026
    Author

    anonymoosemagoose oh man, thank you — this was exactly it. I'd been stuck on HCS_E_HYPERV_NOT_INSTALLED / 0x80370102 for a while and had already tried all the usual stuff: BIOS SVM, hypervisorlaunchtype, VBS/Memory Integrity on and off, DISM/SFC, toggling every Hyper-V feature. Nothing.

    Ran your pnputil /enum-devices /instanceid "ROOT\VID\0000" /stack and there it was — nipbcfk sitting right in front of Vid. Turned out it was NI-PAL that came along with some instrument software I'd installed. Pulled the UpperFilters entry, deleted the nipbcfk service and the .sys, rebooted, and the stack finally reads Vid / PnpManager. WSL2 starts up fine now.

    Wouldn't have found this one on my own, seriously. And thanks for the warning about not just disabling the filter — that would have been a rough morning.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    wsl2Issue/feature applies to WSL 2

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions