Re-filed from #41324, which was auto-closed by the staleness bot on 2026-08-26 while I was working out how to deliver the kernel dump. The bot's message asked for a re-file and there has been no further response there, so I'm opening this to keep the report visible. Same defect, same machine, nothing has changed in the analysis. #41324 is assigned to Blue (@OneBlue) and carries the labels ntbugcheck / hypervisor-platform.
The full kernel dump is already uploaded to the MSRC Researcher Portal as VULN-217534 (submitted 2026-08-30), at Blue (@OneBlue)'s request in #41324.
Windows Version
Microsoft Windows [Version 10.0.26200.8973]
WSL Version
2.7.11.0
Are you using WSL 1 or WSL 2?
Kernel Version
6.18.33.2-microsoft-standard-WSL2
Distro Version
Ubuntu 24.04.1 LTS
Other Software
Docker Desktop 4.86.0 (WSL2 backend)
NOTE: Docker is NOT required. The bug reproduces with plain WSL and no Docker running — starting any distro is sufficient.
Repro Steps
- Start any WSL2 distro and leave the VM running (vmmem/vmmemWSL present).
wsl -e sleep 600 is enough.
- Hibernate the host: Start menu > Power > Hibernate, or
shutdown /h.
Reproduced 10+ times over 13 days, across WSL 2.3.24.0 and 2.7.11.0, and across Windows cumulative updates and Docker Desktop 4.82 -> 4.86.
Avoiding it: run wsl --shutdown (and quit Docker Desktop), wait for vmmem to exit, then hibernate. That succeeds every time.
Expected Behavior
The host hibernates and resumes normally, as it does when no WSL VM has been started.
Actual Behavior
The display powers off but the machine stays fully powered with fans ramping for 4-9 minutes, then bugchecks:
0x0000009F (DRIVER_POWER_STATE_FAILURE)
Arg1 = 0x3 "A device object has been blocking an IRP for too long a time"
The hibernation image is never completed, so the next boot logs:
Kernel-Boot 16 : Windows failed to resume from hibernate with error status 0xC0000001 (also seen as 0xC000007B)
Kernel-Boot 27 : The boot type was 0x0 <- cold boot
Kernel-Power 41: The system has rebooted without cleanly shutting down first
The session is lost. No error or diagnostic is surfaced to the user — the machine goes black, stays hot for several minutes, and dies.
Shutdown is affected the same way: it sits through the same timeout before giving up, presenting as "shutdown takes forever".
Diagnostic Logs
Analysis is from a full kernel dump (4.52 GB, CrashDumpEnabled=2).
!analyze -v
BugCheck 9F, {3, ffffb583f7de6320, fffff805107fbf80, ffffb583f7c3b010}
Arg1: 0000000000000003, A device object has been blocking an IRP for too long a time
Arg2: ffffb583f7de6320, Physical Device Object of the stack
Arg4: ffffb583f7c3b010, The blocked IRP
FAILURE_BUCKET_ID: 0x9F_3_POWER_DOWN_vmswitch!VmsOmSwitchWaitForPendingData
MODULE_NAME: vmswitch
IMAGE_NAME: vmswitch.sys
Blocked IRP (!irp)
[IRP_MJ_POWER(16), IRP_MN_SET_POWER(2)]
0 e1 ffffb583f42ea050 00000000 fffff8057e7706a0-ffffb58391eab4f0 Success Error Cancel pending
\Driver\VMSP nt!PopSystemIrpCompletion
Args: 00015500 00000000 00000005 00000003
Device stack (!devstack)
!DevObj !DrvObj !DevExt ObjectName
ffffb583f42ea050 \Driver\VMSP ffffb583f42ea1a0 NDMP16
ffffb583f7de6320 \Driver\PnpManager ffffb583f7de6470 00000111
!DevNode ffffb583f8319270 :
DeviceInst is "ROOT\VMS_VSMP\0000"
ServiceName is "VMSMP"
Power manager state (!poaction)
PopAction:
State..........: 3 - Set System State
Action.........: Sleep
Lightest State.: Hibernate
Irp minor......: SetPower
System State...: Hibernate
IRP: ffffb583f7c3b010 (set/S4), PDO: ffffb583f7de6320, CURRENT: ffffb583f42ea050
THREAD: ffffb5838e5b0080 (static), IRP: ffffb583f7c3b010, DEVICE: ffffb583f42ea050
Stack of the blocked power worker thread
nt!KiSwapContext
nt!KiSwapThread
nt!KiCommitThreadWait
nt!KeWaitForSingleObject
ndis!NdisMSleep
vmswitch!VmsOmSwitchWaitForPendingData+0xd1 <-- blocks here
vmswitch!VmsExtPtNetPnPEvent+0x47b
ndis!ndisInvokeNetPnPEvent
ndis!ndisDeliverNetPnPEventSynchronously
ndis!ndisPnPNotifyBinding
ndis!ndisPnPNotifyBindingUnlocked
ndis!ndisPauseProtocolInner
ndis!ndisPauseProtocol
ndis!Ndis::BindEngine::Iterate
ndis!Ndis::BindEngine::UpdateBindings
ndis!Ndis::BindEngine::ApplyBindChanges
ndis!ndisPrepForLowPowerCommon
ndis!ndisPrepForLowPower
ndis!ndisSetSystemPower
ndis!ndisSetPower
ndis!ndisPowerDispatch
nt!PopIrpWorker
nt!PspSystemThreadStartup
Reading
The S4 transition drives ndisPrepForLowPower, which pauses protocol bindings.
That delivers a NetPnP event synchronously to vmswitch's extensible-switch
protocol edge, and VmsOmSwitchWaitForPendingData waits for pending switch data to
drain using NdisMSleep. There appears to be no timeout on that wait, and while a
VM port is still attached the drain condition is never satisfied, so the S4
SetPower IRP stays "pending" until the power manager times out and bugchecks.
Version delta that may help isolate this
| WSL |
VM state at hibernate |
Result |
| 2.3.24.0 |
VM shut down, switch still present |
crash, same bucket |
| 2.7.11.0 |
VM shut down, switch still present |
resumes cleanly (3/3) |
| 2.7.11.0 |
VM RUNNING |
crash - this report |
On 2.3.24 the switch blocked even when idle, and the only workaround was
"hnsdiag delete networks". On 2.7.11 an idle switch drains and completes
correctly. Only the live-VM case still hangs, which suggests the drain path is
where the defect lives and that adjacent code has already been touched.
Concurrent event from a different component
~3 seconds before the hang, with a VM running:
Kernel-Power 40: The driver \Driver\vpcivsp for device ROOT\VPCIVSP\0000
stopped the power transition.
vpcivsp (Hyper-V PCI server, used by WSL GPU paravirtualization) is NOT the
driver holding the blocked IRP in any dump analysed - every dump buckets to
vmswitch - but it may be useful context.
Suggested behaviour
Bounding the wait in VmsOmSwitchWaitForPendingData and failing the transition
cleanly would be preferable to an unbounded sleep. Alternatively, quiescing or
detaching VM ports on an S4 request, or refusing the transition with a surfaced
error, would all beat a multi-minute hang and a bugcheck with no user-visible
diagnostic.
Kernel dump
The full kernel dump has been uploaded to the MSRC Researcher Portal, at
Blue (@OneBlue)'s request in #41324:
MSRC submission : VULN-217534 (submitted 2026-08-30, status Submitted)
Attached there : MEMORY-dmp-41324.7z.001 ... .012 (12 x 50 MB 7-Zip volumes)
wsl-hibernate-minidump.zip
Extracts to : MEMORY.DMP, 4,857,879,600 bytes
SHA256 : AF7027F4A2E5A424222E9806EAD9C4F684E44405275063DCACD18B41161A23BB
Crash time : 2026-08-12 16:48 local (UTC+2)
AlwaysKeepMemoryDump was already 1 before that crash, so it is a full kernel dump
rather than a minidump. It had to be split into 50 MB volumes because single
uploads around 290 MB failed with HTTP 500.
Nine further minidumps spanning 13 days and two WSL versions all carry the
identical failure bucket and are available on request. The repro is deterministic
and takes about two minutes, so I can capture additional dumps or a file-mode WPR
trace that survives the bugcheck at any point - just say which profile.
Note on the documented reporting route
CONTRIBUTING.md section 10, "Reporting a Windows crash (BSOD)", still instructs
reporters to email the dump to secure@microsoft.com. That address now
auto-bounces:
"Microsoft is no longer accepting new submissions through secure@microsoft.com"
- Microsoft Security Response Center
Anyone following that section for a BSOD report currently hits a dead end. The
Researcher Portal offers a one-time token to put in the email subject line as a
workaround for people who cannot sign in, but the doc does not mention it.
Machine
HP OMEN 17-ck0xxx, Intel Core i7-11800H, RTX 3060 Laptop.
VBS and Credential Guard enabled. WSL networking: default NAT, Hyper-V firewall enabled.
wsl-hibernate-minidump.zip
Windows Version
Microsoft Windows [Version 10.0.26200.8973]
WSL Version
2.7.11.0
Are you using WSL 1 or WSL 2?
Kernel Version
6.18.33.2-microsoft-standard-WSL2
Distro Version
Ubuntu 24.04.1 LTS
Other Software
Docker Desktop 4.86.0 (WSL2 backend)
NOTE: Docker is NOT required. The bug reproduces with plain WSL and no Docker running — starting any distro is sufficient.
Repro Steps
wsl -e sleep 600is enough.shutdown /h.Reproduced 10+ times over 13 days, across WSL 2.3.24.0 and 2.7.11.0, and across Windows cumulative updates and Docker Desktop 4.82 -> 4.86.
Avoiding it: run
wsl --shutdown(and quit Docker Desktop), wait for vmmem to exit, then hibernate. That succeeds every time.Expected Behavior
The host hibernates and resumes normally, as it does when no WSL VM has been started.
Actual Behavior
The display powers off but the machine stays fully powered with fans ramping for 4-9 minutes, then bugchecks:
0x0000009F (DRIVER_POWER_STATE_FAILURE)
Arg1 = 0x3 "A device object has been blocking an IRP for too long a time"
The hibernation image is never completed, so the next boot logs:
Kernel-Boot 16 : Windows failed to resume from hibernate with error status 0xC0000001 (also seen as 0xC000007B)
Kernel-Boot 27 : The boot type was 0x0 <- cold boot
Kernel-Power 41: The system has rebooted without cleanly shutting down first
The session is lost. No error or diagnostic is surfaced to the user — the machine goes black, stays hot for several minutes, and dies.
Shutdown is affected the same way: it sits through the same timeout before giving up, presenting as "shutdown takes forever".
Diagnostic Logs
Analysis is from a full kernel dump (4.52 GB, CrashDumpEnabled=2).
!analyze -v
BugCheck 9F, {3, ffffb583f7de6320, fffff805107fbf80, ffffb583f7c3b010}
Arg1: 0000000000000003, A device object has been blocking an IRP for too long a time
Arg2: ffffb583f7de6320, Physical Device Object of the stack
Arg4: ffffb583f7c3b010, The blocked IRP
FAILURE_BUCKET_ID: 0x9F_3_POWER_DOWN_vmswitch!VmsOmSwitchWaitForPendingData
MODULE_NAME: vmswitch
IMAGE_NAME: vmswitch.sys
Blocked IRP (!irp)
Device stack (!devstack)
!DevObj !DrvObj !DevExt ObjectName
ffffb583f42ea050 \Driver\VMSP ffffb583f42ea1a0 NDMP16
!DevNode ffffb583f8319270 :
DeviceInst is "ROOT\VMS_VSMP\0000"
ServiceName is "VMSMP"
Power manager state (!poaction)
PopAction:
State..........: 3 - Set System State
Action.........: Sleep
Lightest State.: Hibernate
Irp minor......: SetPower
System State...: Hibernate
IRP: ffffb583f7c3b010 (set/S4), PDO: ffffb583f7de6320, CURRENT: ffffb583f42ea050
THREAD: ffffb5838e5b0080 (static), IRP: ffffb583f7c3b010, DEVICE: ffffb583f42ea050
Stack of the blocked power worker thread
nt!KiSwapContext
nt!KiSwapThread
nt!KiCommitThreadWait
nt!KeWaitForSingleObject
ndis!NdisMSleep
vmswitch!VmsOmSwitchWaitForPendingData+0xd1 <-- blocks here
vmswitch!VmsExtPtNetPnPEvent+0x47b
ndis!ndisInvokeNetPnPEvent
ndis!ndisDeliverNetPnPEventSynchronously
ndis!ndisPnPNotifyBinding
ndis!ndisPnPNotifyBindingUnlocked
ndis!ndisPauseProtocolInner
ndis!ndisPauseProtocol
ndis!Ndis::BindEngine::Iterate
ndis!Ndis::BindEngine::UpdateBindings
ndis!Ndis::BindEngine::ApplyBindChanges
ndis!ndisPrepForLowPowerCommon
ndis!ndisPrepForLowPower
ndis!ndisSetSystemPower
ndis!ndisSetPower
ndis!ndisPowerDispatch
nt!PopIrpWorker
nt!PspSystemThreadStartup
Reading
The S4 transition drives ndisPrepForLowPower, which pauses protocol bindings.
That delivers a NetPnP event synchronously to vmswitch's extensible-switch
protocol edge, and VmsOmSwitchWaitForPendingData waits for pending switch data to
drain using NdisMSleep. There appears to be no timeout on that wait, and while a
VM port is still attached the drain condition is never satisfied, so the S4
SetPower IRP stays "pending" until the power manager times out and bugchecks.
Version delta that may help isolate this
On 2.3.24 the switch blocked even when idle, and the only workaround was
"hnsdiag delete networks". On 2.7.11 an idle switch drains and completes
correctly. Only the live-VM case still hangs, which suggests the drain path is
where the defect lives and that adjacent code has already been touched.
Concurrent event from a different component
~3 seconds before the hang, with a VM running:
Kernel-Power 40: The driver \Driver\vpcivsp for device ROOT\VPCIVSP\0000
stopped the power transition.
vpcivsp (Hyper-V PCI server, used by WSL GPU paravirtualization) is NOT the
driver holding the blocked IRP in any dump analysed - every dump buckets to
vmswitch - but it may be useful context.
Suggested behaviour
Bounding the wait in VmsOmSwitchWaitForPendingData and failing the transition
cleanly would be preferable to an unbounded sleep. Alternatively, quiescing or
detaching VM ports on an S4 request, or refusing the transition with a surfaced
error, would all beat a multi-minute hang and a bugcheck with no user-visible
diagnostic.
Kernel dump
The full kernel dump has been uploaded to the MSRC Researcher Portal, at
Blue (@OneBlue)'s request in #41324:
MSRC submission : VULN-217534 (submitted 2026-08-30, status Submitted)
Attached there : MEMORY-dmp-41324.7z.001 ... .012 (12 x 50 MB 7-Zip volumes)
wsl-hibernate-minidump.zip
Extracts to : MEMORY.DMP, 4,857,879,600 bytes
SHA256 : AF7027F4A2E5A424222E9806EAD9C4F684E44405275063DCACD18B41161A23BB
Crash time : 2026-08-12 16:48 local (UTC+2)
AlwaysKeepMemoryDump was already 1 before that crash, so it is a full kernel dump
rather than a minidump. It had to be split into 50 MB volumes because single
uploads around 290 MB failed with HTTP 500.
Nine further minidumps spanning 13 days and two WSL versions all carry the
identical failure bucket and are available on request. The repro is deterministic
and takes about two minutes, so I can capture additional dumps or a file-mode WPR
trace that survives the bugcheck at any point - just say which profile.
Note on the documented reporting route
CONTRIBUTING.md section 10, "Reporting a Windows crash (BSOD)", still instructs
reporters to email the dump to secure@microsoft.com. That address now
auto-bounces:
"Microsoft is no longer accepting new submissions through secure@microsoft.com"
Anyone following that section for a BSOD report currently hits a dead end. The
Researcher Portal offers a one-time token to put in the email subject line as a
workaround for people who cannot sign in, but the doc does not mention it.
Machine
HP OMEN 17-ck0xxx, Intel Core i7-11800H, RTX 3060 Laptop.
VBS and Credential Guard enabled. WSL networking: default NAT, Hyper-V firewall enabled.
wsl-hibernate-minidump.zip