Host bugcheck 0x7E / STATUS_ASSERTION_FAILURE in nt!VmpInvalidateSingleGpaRange with idle WSL2 VM (4 builds affected, kernel dump available)

[JeanCapixaba]

Summary

Host bugchecks with 0x7E / STATUS_ASSERTION_FAILURE in nt!VmpInvalidateSingleGpaRange whenever a WSL2 VM is running — even when the VM is completely idle. Reproduced across four consecutive Windows builds over 4 months (14 crashes). A full kernel memory dump (3.72 GB) was captured and analyzed; the stack shows the crash is initiated by a host memory-manager worker thread, not by the guest.

I'm filing here because PROCESS_NAME is vmmemWSL and the failing path is the hypervisor integration used by WSL2. Happy to move this if another repo/channel is more appropriate.

Bugcheck details

Bugcheck  : 0x0000007E (SYSTEM_THREAD_EXCEPTION_NOT_HANDLED)
Exception : 0xC0000420 (STATUS_ASSERTION_FAILURE)
Faulting  : nt!VmpInvalidateSingleGpaRange+0x44 (ntkrnlmp.exe)

FAILURE_BUCKET_ID : 0x7E_C0000420_nt!VmpInvalidateSingleGpaRange
FAILURE_ID_HASH   : {a9270265-d553-0ae1-9a99-f3429c97b86d}
PROCESS_NAME      : vmmemWSL

Full stack (from the kernel dump, 2026-08-15 17:12 crash)

nt!VmpInvalidateSingleGpaRange+0x44     <-- assertion fails here
nt!VmpProcessInvalidateList+0x24de29
nt!VmpFlushTb+0x146
nt!MiFlushTbList+0x872
nt!MiFlushSingleTbEntry+0x2d7
nt!MiStealPage+0x405
nt!MiTradePage+0x287
nt!MiClaimPhysicalRun+0xe0
nt!MiFindContiguousPagesEx+0x559
nt!MiRebuildLargePage+0x194
nt!MiRebuildLargePages+0x2f8
nt!ExpWorkerThread+0x4bb
nt!PspSystemThreadStartup+0x5a
nt!KiStartSystemThread+0x34

Interpretation: a host background worker thread doing large-page rebuilding (MiRebuildLargePages → MiClaimPhysicalRun → MiTradePage → MiStealPage) steals physical pages backing the running VM's guest-physical memory. The follow-up GPA range invalidation in the hypervisor path hits a failed assertion and bugchecks the host.

This explains why no guest-side tuning helps — the guest never initiates it.

Steps to reproduce

1. Enable Hyper-V / Virtual Machine Platform, install WSL2.
2. Start any WSL2 VM (in my case Docker Desktop's WSL2 backend) and simply leave it running.
3. Wait. No workload is required — the VM can sit idle.
4. Host bugchecks, typically after 1–3 days of VM uptime.

It never happens when no VM is running. It also reproduced with QEMU (Android emulator) through the Windows Hypervisor Platform, so it is not Docker-specific — any VM on this host triggers it eventually.

Occurrences

Identical bucket every single time:

2026-04-08, 2026-06-07, 2026-06-28 (×2), 2026-06-29, 2026-07-12 (×2), 2026-07-15, 2026-07-17 (×2), 2026-07-21, 2026-07-22, 2026-07-24, 2026-08-11, 2026-08-15 (kernel dump captured)

Builds affected

All four crashed with the identical signature:

Windows build	Result
26200.8655	crashes
26200.8737 (KB5095093)	crashes
26200.8875	crashes
26200.9168 (current)	crashes

WSL was also updated to 2.7.10 — no effect.

Environment

WSL version      : 2.7.10.0
Kernel version   : 6.18.33.2-2
WSLg version     : 1.0.73.2
MSRDC version    : 1.2.6676
Direct3D version : 1.611.1-81528511
DXCore version   : 10.0.26100.1-240331-1435.ge-release
Windows version  : 10.0.26200.9168  (Windows 11 Pro 25H2)

CPU         : Intel Core Ultra 7 265K (Arrow Lake, 20 cores)
Motherboard : ASRock Z890 Pro RS WiFi White, BIOS 2.03
RAM         : 32 GB DDR5 (2x16 GB Kingston KF564C32-16, XMP 6400)
Virtualization: Hyper-V platform enabled, VBS running

.wslconfig in use:

[wsl2]
memory=8GB
processors=4
swap=4GB
pageReporting=false

[experimental]
autoMemoryReclaim=disabled

The crash reproduces regardless of these settings — pageReporting=false and autoMemoryReclaim=disabled were set specifically to stop guest-side page reclaim, and the host still crashed 2 days later. Consistent with the host-initiated stack above.

Ruled out during investigation

• Storage — SSD firmware updated, all drives healthy; no change
• Antivirus — same signature with protection paused
• Guest-side memory reclaim — disabled (pageReporting=false, autoMemoryReclaim=disabled); still crashes
• System file integrity — sfc /scannow and DISM /RestoreHealth both clean
• Windows Update — four builds tested, all affected

Evidence available

• Full kernel dump MEMORY.DMP (3.72 GB) of the 2026-08-15 crash
• Minidumps from three earlier crashes (identical bucket)
• Complete WinDbg !analyze -v output

I can upload the kernel dump anywhere you prefer — just let me know where.

Expected behavior

Host memory management reclaiming/rebuilding large pages should not be able to bugcheck the host while a VM holds those pages.

[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-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'.

[JeanCapixaba]

/emailed-logs

Logs collected with collect-wsl-logs.ps1 (default profile, with the WSL2 VM running) and emailed to wsl-gh-logs@microsoft.com with #41364 in the subject.

Important note about the trace

The ETW trace cannot contain the actual repro, and I want to be upfront about why:

• This is a host bugcheck (0x7E / STATUS_ASSERTION_FAILURE in nt!VmpInvalidateSingleGpaRange), not a WSL-level failure. When it fires, the entire host bugchecks and the in-memory trace buffers are lost with it.
• There is no way to trigger it on demand — it happens on its own after roughly 1–3 days of VM uptime, with the VM completely idle.

The attached trace was therefore captured during normal operation with the WSL2 VM (Docker Desktop backend) running, so you have the full environment, configuration and live VM state.

The actual evidence

A full kernel dump (MEMORY.DMP, 3.72 GB) was captured from the 2026-08-15 17:12 crash. The complete stack from that dump is already in the issue description above — it shows the fault is initiated by a host memory-manager worker thread (ExpWorkerThread → MiRebuildLargePages → MiClaimPhysicalRun → MiTradePage → MiStealPage → MiFlushSingleTbEntry → MiFlushTbList → VmpFlushTb → VmpInvalidateSingleGpaRange), i.e. large-page rebuilding steals physical pages backing the running VM's guest-physical memory.

This is also why no guest-side tuning changes anything — the guest never initiates the path.

I can upload the kernel dump anywhere you prefer — please just tell me where.

Privacy note on the logs

In windows-version.txt I redacted only the license identifier fields (ProductId, DigitalProductId, DigitalProductId4, RegisteredOwner, RegisteredOrganization). Everything technically relevant is untouched: build 26200.9168, DisplayVersion 25H2, EditionID Professional, BuildLab, and all other files including the complete logs.etl trace.

[github-actions]

Diagnostic information

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

[OneBlue]

/bsod

[JeanCapixaba]

Thanks Blue (@OneBlue) — the kernel dump is already captured and ready.

AlwaysKeepMemoryDump was already enabled before the crash, and the machine bugchecked on its own on 2026-08-15 17:12 with Docker Desktop (WSL2 backend) idle in the background. MEMORY.DMP was written successfully: 3.72 GB.

I'm sending it to secure@microsoft.com now, with #41364 in the subject and a note in the body that it is intended for the WSL team, per section 10. Since the file is 3.72 GB it obviously won't fit in an email — I'm compressing it and will ask them for an upload location. If you have a preferred drop point, just say the word and I'll upload there instead.

For convenience, here is the analysis from that exact dump again:

Bugcheck  : 0x0000007E (SYSTEM_THREAD_EXCEPTION_NOT_HANDLED)
Exception : 0xC0000420 (STATUS_ASSERTION_FAILURE)
Faulting  : nt!VmpInvalidateSingleGpaRange+0x44

FAILURE_BUCKET_ID : 0x7E_C0000420_nt!VmpInvalidateSingleGpaRange
FAILURE_ID_HASH   : {a9270265-d553-0ae1-9a99-f3429c97b86d}
PROCESS_NAME      : vmmemWSL
Windows build     : 26200.9168 (25H2)

nt!VmpInvalidateSingleGpaRange+0x44     <-- assertion fails here
nt!VmpProcessInvalidateList+0x24de29
nt!VmpFlushTb+0x146
nt!MiFlushTbList+0x872
nt!MiFlushSingleTbEntry+0x2d7
nt!MiStealPage+0x405
nt!MiTradePage+0x287
nt!MiClaimPhysicalRun+0xe0
nt!MiFindContiguousPagesEx+0x559
nt!MiRebuildLargePage+0x194
nt!MiRebuildLargePages+0x2f8
nt!ExpWorkerThread+0x4bb
nt!PspSystemThreadStartup+0x5a
nt!KiStartSystemThread+0x34

I also still have minidumps from three earlier crashes with the identical bucket (2026-07-22, 2026-07-24, plus the 2026-08-15 one), if a second data point is useful.

[JeanCapixaba]

Blue (@OneBlue) heads-up: the channel documented in section 10 is no longer accepting submissions.

I sent the kernel dump details to secure@microsoft.com as instructed (with #41364 in the subject and a note that it is intended for the WSL team) and got this auto-reply:

Microsoft is no longer accepting new submissions through secure@microsoft.com

Please use the Microsoft Researcher Portal to report all potential product or service security vulnerabilities.

The Researcher Portal is scoped to security vulnerabilities, and this is a reliability bug (host bugcheck), so submitting it there seems like the wrong queue and would likely be triaged out.

Where would you like the dump instead? I'm ready to send it immediately:

• MEMORY.DMP — 3.72 GB uncompressed
• Already compressed to 547 MB (.xz, integrity verified with xz -t); happy to repackage as .zip if that's easier
• I can upload to any drop point you provide, or share a private link

Worth noting for the repo as well: since /bsod points contributors at a dead address, anyone hitting a BSOD right now has no working path to deliver a dump.