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

### 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:

```ini
[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.

Start with the available kernel MEMORY.DMP and the WinDbg !analyze -v output, focusing on the nt!VmpInvalidateSingleGpaRange stack described here; no repository file or test entry point is identified. Done means determining the host-side cause or routing the report to the appropriate Windows or Hyper-V channel and validating it against the idle-VM reproduction.

Written by the indexing model from the issue text.