WSL2 enters unrecoverable zombie state after sleep/wake - vsock communication failure

[dodjango]

Windows Version

Microsoft Windows [Version 10.0.26100.2605]

WSL Version

WSL-Version: 2.3.26.0
Kernelversion: 5.15.167.4-1
WSLg-Version: 1.0.65
MSRDC-Version: 1.2.5620
Direct3D-Version: 1.611.1-81528511
DXCore-Version: 10.0.26100.1-240331-1435.ge-release
Windows-Version: 10.0.26100.2605

Kernel Version

5.15.167.4-1

Distro Version

Ubuntu 24.04

WSL 1 or WSL 2?

• WSL 2

Repro Steps

1. Start WSL2 normally (working state, shell sessions open)
2. Put Windows into standby/sleep overnight
3. Resume Windows from standby
4. Existing WSL2 shell sessions still work (inside the VM)
5. Attempt to open new WSL session via wsl command → hangs indefinitely
6. Get-Service LxssManager shows "Running"
7. Start-Service LxssManager fails with Wsl/Service/E_UNEXPECTED

Expected Behavior

WSL2 should recover gracefully after Windows resumes from sleep/standby, or at minimum provide a way to restart the services without requiring a full system reboot.

Actual Behavior

After sleep/wake, WSL2 enters a "zombie running" state:

• All services (LxssManager, vmcompute, vmms) appear "Running" in Get-Service
• But vsock communication between Windows and the WSL2 VM is broken
• The VM itself is still running (existing shell sessions inside WSL work!)
• New connections from Windows side fail with Error 110 (ETIMEDOUT)

Event Log evidence:

• NDIS virtual network adapter fails to restore after standby
• Hyper-V vmms logs show no errors (services think they're healthy)

Recovery attempts that fail:

• Restart-Service LxssManager → hangs
• Stop-Service vmcompute -Force → causes system instability (details sent to secure@microsoft.com)

Only working recovery: Full system reboot via Restart-Computer

Detailed Analysis

I have documented the complete incident with Event Log analysis, diagnostic steps, and system configuration in this gist:

https://gist.github.com/dodjango/545a8322b43697fb81f214fad245a263

Related Issues

• WSL is non-responsive after waking from hibernate #8696 - WSL2 not working after sleep (248+ upvotes, same root cause)
• Blue Screen of Death  #8459 - Issues when stopping vmcompute (closed)
• enable wsl2 cause random bsod bluescreeen on win11 #8205 - WSL2 hangs after sleep
• Getting BSOD saying dxgkrnl.sys failed after upgrade to wsl 2.0.9.0 #10750 - Sleep/wake networking issues

Other Software

• GPU: NVIDIA with WSLg enabled
• Hyper-V features enabled
• Docker Desktop installed (not running during incident)

Request

1. Could the WSL team investigate why vsock communication breaks during sleep/wake while the VM stays alive?
2. Is there a safe way to restart WSL services without a full reboot when this state occurs?

Note: Additional diagnostic data (minidump) has been submitted separately to secure@microsoft.com per contribution guidelines.

[github-actions]

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-networking-logs.ps1, 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'.

[dodjango]

Log Collection Note

The incident described in this issue has been resolved via system reboot (the only working recovery method). Therefore, current logs would not show the failure state.

However, I have documented extensive diagnostics from the incident:

Evidence in the Gist

The detailed analysis gist contains:

• Event Log entries from the exact time of failure:
  • NDIS virtual adapter power transition failure
  • Hyper-V Compute logs showing service state
  • Kernel-Power events around sleep/wake
• Service states captured during the zombie state
• Error messages from LxssManager recovery attempts
• System configuration (.wslconfig, WSL version, Windows build)

Key Diagnostic Finding

The critical observation: existing WSL2 shell sessions continued to work inside the VM during the failure. This proves:

1. The WSL2 VM was still running
2. Only the vsock communication (Windows ↔ VM) was broken
3. Services appeared "Running" but could not establish new connections

Additional Data

A minidump from the subsequent system crash (when attempting Stop-Service vmcompute -Force) has been submitted to secure@microsoft.com per contribution guidelines.

If current-state logs would still be helpful for baseline comparison, I'm happy to run collect-wsl-logs.ps1 and attach them.

[dodjango]

/emailed-logs

[github-actions]

Diagnostic information

Found '/emailed-logs', adding tag 'emailed-logs'