Recurring host BSOD 0x7E (STATUS_ASSERTION_FAILURE) in nt!VmpInvalidateSingleGpaRange when MiRebuildLargePages steals pages from the vmmemWSL partition

[lukebrett1993-spec]

Windows Version

Microsoft Windows [Version 10.0.26200.9168] (also reproduced on 26200.8875)

WSL Version

2.7.10.0

Are you using WSL 1 or WSL 2?

WSL 2

Kernel Version

6.18.33.2-2

Distro Version

Ubuntu (also Docker Desktop distros running in the same utility VM)

Other Software

Docker Desktop (WSL 2 engine); heavy parallel build / AI-agent workloads. Host: ASUS board, Intel Ultra 9 285K, 64 GB DDR5 (JEDEC 4800, no XMP).

Repro Steps

Run sustained heavy memory load on the host while the WSL 2 utility VM is running (parallel Docker image builds, multiple LLM coding-agent processes). Within hours to days the host bugchecks. 10+ host BSODs June–August 2026, roughly 2/week, all with vmmemWSL as the current process.

Expected Behavior

No host bugcheck.

Actual Behavior

Host BSOD 0x7E SYSTEM_THREAD_EXCEPTION_NOT_HANDLED with exception 0xC0000420 (STATUS_ASSERTION_FAILURE) in nt!VmpInvalidateSingleGpaRange.

Failure bucket (identical across all 0x7E dumps, spanning builds 26200.8655 → 26200.9168 and WSL 2.6.3 → 2.7.10):

FAILURE_BUCKET_ID: 0x7E_C0000420_nt!VmpInvalidateSingleGpaRange
PROCESS_NAME: vmmemWSL

Full stack from the two most recent minidumps (2026-08-11 on 26200.8875, 2026-08-12 on 26200.9168 — identical):

nt!VmpInvalidateSingleGpaRange+0x44
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

Analysis: the trigger is host-side, not guest-side. The MiRebuildLargePages system worker steals a 4k page backing the WSL utility VM partition (WSL sets BackingPageSize = Small / EnableColdDiscardHint = true in WslCoreVm.cpp), and the GPA-range invalidation on the TB-flush path hits an assertion. The guest is a bystander.

Ruled out / already attempted:

• WSL update 2.6.3 → 2.7.10 (kernel 6.6 → 6.18): no effect, same bucket.
• Guest free page reporting fully disabled via kernelCommandLine = initcall_blacklist=init_balloon_drv (verified in dmesg: hv_balloon never loads, no "Free page reporting enabled" / "Cold memory discard hint"): crash still reproduces via the MiRebuildLargePages path above, confirming cold-discard hints are not required to trigger it.
• HVCI / Memory Integrity disabled (SecurityServicesRunning = 0, verified after reboot): no effect on the 0x7E.
• August 2026 CU installed (KB5121003, 26200.9168): crashed again ~16h later.
• Hardware ruled out as far as practical: WHEA log clean, RAM at JEDEC 4800 (no XMP), no memory-diagnostic failures.

Possibly related: 3× 0x18B SECURE_KERNEL_ERROR (securekernel!SkmiProtectPageRange, param2 "VSM") on the same machine in the same period while HVCI was still enabled — also a memory-page-protection path; none since HVCI was disabled.

Minidumps available on request (5 retained, plus WER reports).

wsl --version:

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

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

[OneBlue]

/bsod

[microsoft-github-policy-service]

Hello! Could you please provide a kernel dump to help us better diagnose your issue? To collect a kernel dump, follow 10) Reporting a Windows crash (BSOD)
Thank you!