Skip to content

Windows 11 reboots during boot when hypervisorlaunchtype is Auto on AMD Ryzen 9 9950X3D #41882

Closed

Description

@harahideki-beep

Windows Version

Microsoft Windows [Version 10.0.26200.9457]

WSL Version

3.0.1.0

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

  • WSL 2
  • WSL 1
  • WSLC

Kernel Version

6.18.40.1-1

Distro Version

Not installed (Windows fails to boot with Hyper-V enabled before any WSL distribution can be launched).

Other Software

今回の問題は、Linuxディストリビューションを起動したときのエラーではありません。

Windows Hypervisorを有効にしただけで、Windowsそのものが起動できなくなる問題です。

そのため、WSLのカーネルバージョンはインストール済みコンポーネントの情報として記載しますが、Linuxカーネルが実際に起動したことを意味しません。

Repro Steps

  1. On Windows 11 build 26200.9457, create a separate Windows Boot Manager entry pointing to the same Windows installation.
  2. Keep the normal entry configured with hypervisorlaunchtype Off.
  3. Configure the test entry with hypervisorlaunchtype Auto.
  4. Restart the computer and select the test entry.
  5. Observe that Windows fails during startup, the system restarts, and the boot selection screen reappears.
  6. Select the normal Windows entry. Windows boots successfully.

Expected Behavior

Windows 11 should boot normally when hypervisorlaunchtype is set to Auto on an AMD Ryzen 9 9950X3D system with SVM enabled in firmware.

After Windows starts successfully, WSL2 and Docker Desktop should be able to use hardware virtualization without requiring hypervisorlaunchtype Off.

Actual Behavior

When hypervisorlaunchtype is set to Auto, Windows 11 fails during startup.

The Windows boot logo appears, then the display goes black and the computer restarts. The ASUS firmware logo appears again, followed by the Windows Boot Manager selection screen.

Selecting the normal Windows 11 entry with hypervisorlaunchtype Off allows Windows to boot successfully.

System configuration:

  • CPU: AMD Ryzen 9 9950X3D
  • Motherboard: ASUS TUF GAMING X870E-PLUS WIFI7
  • BIOS: 2503
  • Windows: 11, build 26200.9457
  • RAM: 64 GB DDR5-5600
  • WSL version: 3.0.1.0
  • WSL kernel package version: 6.18.40.1-1

Troubleshooting already performed:

  • AMD SVM virtualization is enabled.
  • SLAT and virtualization extensions are supported.
  • Virtual Machine Platform is enabled.
  • No relevant WHEA hardware errors were found.
  • No BugCheck event or new crash dump was recorded.
  • Hyper-V Hypervisor Admin and Operational logs contain no relevant entries.
  • Windows Startup Repair did not identify a root cause.
  • Boot logging was enabled for the test boot entry, but C:\Windows\ntbtlog.txt was not generated.
  • AMD Ryzen Master and its V30 driver were uninstalled, but the issue persisted.

Both boot entries reference the same Windows installation. Only the Hypervisor launch configuration differs in the tested setup.

No Linux distribution is installed yet because Windows itself cannot boot with the Hypervisor enabled.

The issue occurs before WSL2 or Docker Desktop can be launched.

Diagnostic Logs

No crash dump or WSL diagnostic trace is available because Windows fails during early boot, before WSL can be launched.

The System event log reports a previous unsuccessful boot, but no actionable BugCheck code was captured.

Hyper-V Hypervisor Admin and Operational logs were enabled but contained no events.

Boot logging was enabled using bcdedit /set <test-entry-guid> bootlog Yes, but C:\Windows\ntbtlog.txt was not created after reproducing the failure.

Boot logging has since been disabled. The normal Windows boot entry remains functional with hypervisorlaunchtype Off.

I can provide sanitized BCD output, System event log excerpts, and additional diagnostic information upon request.

Activity

  1. github-actions commented on Oct 12, 2026

    @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 [email protected] 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. OneBlue commented on Oct 12, 2026

    @OneBlue
    Collaborator

    /hyperv

  3. microsoft-github-policy-service commented on Oct 12, 2026

    @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.

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

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions