Fatal machine check in WSL2 guest, Bank 0: b200000080060001 — 15 identical panics in 18 days, with no corresponding WHEA error on the host

Nobody has claimed this yet.

### Windows Version

`Microsoft Windows [Version 10.0.26200.9457]` (Windows 11 Pro 25H2)

### WSL Version

`2.9.12.0`

### Are you using WSL 1 or WSL 2?

WSL 2

### Kernel Version

`6.18.40.1-1` (`Linux version 6.18.40.1-microsoft-standard-WSL2 #1 SMP PREEMPT_DYNAMIC Fri Jul 31 22:12:15 UTC 2026`)

### Distro Version

Ubuntu 25.04

### Other Software

Docker Engine running inside the distro (the `docker0` bridge is visible in the dumps below), VS Code with the WSL remote extension, long-running compile / language-server / test workloads. Nothing exotic, and the fault does not correlate with any of them — see "load anti-correlation" below.

### Repro Steps

I have no deterministic repro; this is a spontaneous fault under ordinary sustained use. What I can offer instead is 15 captured panic dumps over 18 days with a byte-identical signature, and a set of hypotheses I have already falsified.

1. Run WSL 2 on an Intel Core Ultra (Meteor Lake) laptop under normal developer load — compiles, language servers, containers, many long-lived processes.
2. Leave the VM up for hours.
3. At an unpredictable point (observed uptime at failure: 1.6 h to 62 h) the guest kernel takes a fatal machine check and the entire VM dies instantly. Every process in it is lost.

Hardware: Dell Precision 5490, Intel Core Ultra 7 165H (family 6, model 0xAA stepping 4, CPUID `0xA06A4`), 64 GB RAM, BIOS 1.22.0 (2026-05-25), microcode revision `0x28`.

### Expected Behavior

The VM keeps running. If the host genuinely observes an uncorrected, context-corrupting core error, the host should observe it too — there should be a matching `Microsoft-Windows-WHEA-Logger` record and, for `PCC=1`, a host bugcheck `0x124`.

### Actual Behavior

The guest panics. Tail of the most recent dump (`%LOCALAPPDATA%\Temp\wsl-crashes\kernel-panic-1789761485-{…}.txt`, 2026-09-18 22:58):

```
[39028.286792] mce: [Hardware Error]: Machine check events logged
[39028.287183] mce: [Hardware Error]: CPU 6: Machine Check Exception: 4 Bank 0: b200000080060001
[39028.287193] mce: [Hardware Error]: TSC 6d0b826c5f2a
[39028.287194] mce: [Hardware Error]: PROCESSOR 0:a06a4 TIME 1789761485 SOCKET 0 APIC 6 microcode ffffffff
[39028.287197] mce: [Hardware Error]: Run the above through 'mcelog --ascii'
[39028.287716] mce: [Hardware Error]: Machine check: Processor context corrupt
[39028.287720] Kernel panic - not syncing: Fatal machine check
[39028.288693] Kernel Offset: 0x12000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
```

Decoding `b200000080060001`: `VAL=1 OVER=0 UC=1 EN=1 MISCV=0 ADDRV=0 PCC=1 S=0 AR=0`, `MCACOD 0x0001`, `MSCOD 0x0006`, Bank 0. `MCG_STATUS=4` ⇒ `RIPV=0`, so the kernel has no choice but to panic. Note `ADDRV=0` — **no address is logged**, so nothing is attributable to a memory location, and `MCACOD 0x0001` is Intel's "unclassified error".

#### All 15 events, byte-identical

| # | local time | CPU | uptime at MCE |
|---|-----------|-----|---------------|
| 1 | 2026-09-01 16:33:56 | 14 | 223462 s |
| 2 | 2026-09-02 14:24:59 | 7 | 73046 s |
| 3 | 2026-09-02 22:07:39 | 16 | 27453 s |
| 4 | 2026-09-04 10:15:42 | 11 | 98351 s |
| 5 | 2026-09-07 16:26:37 | 3 | 22822 s |
| 6 | 2026-09-08 21:04:38 | 3 | 64413 s |
| 7 | 2026-09-10 17:29:25 | 12 | 94616 s |
| 8 | 2026-09-11 16:17:46 | 5 | 35698 s |
| 9 | 2026-09-11 17:52:48 | 8 | 5637 s |
| 10 | 2026-09-11 22:35:51 | 16 | 16699 s |
| 11 | 2026-09-12 22:22:39 | 20 | 85473 s |
| 12 | 2026-09-15 17:43:35 | 19 | 17233 s |
| 13 | 2026-09-17 17:20:54 | 2 | 74812 s |
| 14 | 2026-09-18 11:01:39 | 0 | 52808 s |
| 15 | 2026-09-18 22:58:05 | 6 | 39028 s |

Every single one is `Bank 0: b200000080060001`. No exceptions, no variation in a single bit. **Eleven distinct logical CPUs** are represented. A defective physical core would concentrate on one CPU and would vary its `MSCOD`/`MCACOD`; this does neither.

### The part I think is the actual bug: the host never sees the error

I queried the Windows event log across all 15 crash times:

- **`Microsoft-Windows-WHEA-Logger`: zero records at any crash time.** The log contains only two events ever (2026-08-01 and 2026-08-26), neither within hours of any WSL death. I parsed both CPER blobs by hand: notification type `3d61a466-…` = Generic Hardware Error Source, six sections, all `Firmware Error Record Reference` (SoC FW err rec V2), **zero `IA32/X64 Processor Specific` sections**, no MCA bank, no status word, all severities `0 = Recoverable`. They are Intel SoC/PMC firmware telemetry, not core machine checks.
- **No BugCheck `1001`, no `Kernel-Power` event 41 in 30 days.** Windows has never crashed or restarted unexpectedly during this entire period.

So the guest dies 15 times from an unrecoverable, context-corrupting core error, and the OS that owns the physical core notices nothing at all. `PCC=1` means the core's architectural state is unrecoverable — the hypervisor and root partition are on that same core, and Windows should have bugchecked `0x124`. It never did. **A `PCC=1` core error that the host never observes is, I think, the whole bug**: something in the hypervisor↔guest MCE path is synthesizing or mis-forwarding a machine check into the guest.

### Cross-generation match with #13258

https://github.com/microsoft/WSL/issues/13258 reports the **byte-identical status word `b200000080060001`, Bank 0**, with the same panic — but on `PROCESSOR 0:906a3` (**Alder Lake**), a different Windows build, and WSL 2.5.9 / kernel 6.6.87.2.

Two different CPU generations, two machines, two WSL major versions, three kernel series — and the MCA status word matches bit for bit. Independent silicon defects do not do that. That is the fingerprint of a common software/firmware path.

#13258 is the only matching issue in this repository. It was never root-caused: a maintainer asked for logs, the reporter had moved on, and the stale bot auto-closed it after 7 days. `stateReason=COMPLETED` there is the bot, not a fix.

### What I have already falsified

I would rather save triage the round trips, so:

- **Not a specific kernel or WSL regression.** I have crossed WSL 2.9.4.0 → 2.9.12.0 and kernel 6.18.35.2-1 → 6.18.40.1-1 during this window with no change in rate. Combined with #13258 on 6.6.87.2, the fault spans kernel 6.6 → 6.18 and WSL 2.5 → 2.9.
- **Not the vCPU count or the hybrid P/E/LP-E topology.** I had no `.wslconfig` at all (guest got all 22 logical CPUs). On 2026-09-15 18:38 I added `processors=8`; the guest now boots `nr_cpus=8`. Crash rate before: 12 in 14.1 days = **0.85/day**. After: 3 in 3.2 days = **0.94/day**. Unchanged. The three post-cap crashes landed on CPUs 2, 0 and 6 — the fault simply followed the reduced CPU set.
- **Not memory pressure inside the guest.** **Zero** OOM lines in any of the 15 dumps. I run heavy workloads under memory-capped systemd scopes, and on the one occasion a dump did contain cgroup OOM kills they were 4.5 hours before the MCE in the same boot — the cap did its job and the VM stayed up.
- **Not load.** Crashes are, if anything, *anti*-correlated with busy hours. Uptime at failure ranges 1.6 h to 62 h with no pattern.
- **Not failing DRAM.** `ADDRV=0` on all 15 — there is no address to attribute, so this is not a memory-location fault.

### Standing conditions that might matter

- **Nested virtualization is enabled and the eVMCS path warns on every boot**, while nothing uses it: `Hyper-V: Nested features: 0x3e0101`, `kvm_intel: Using Hyper-V Enlightened VMCS`, then `vmentry_ctrl unsupported with eVMCS: 0x100000` and `vmexit_ctrl unsupported with eVMCS: 0x10000000`. `lsmod` shows `kvm_intel` at **refcount 0**.
- **Host firmware throttles the CPU continuously.** `Microsoft-Windows-Kernel-Processor-Power` event 37 ("speed of processor N is being limited by system firmware") fires for several processors essentially 24 h/day, and has since at least 2026-06-26. The active power plan is **Power saver** with minimum processor state 5 %.
- **Guest vCPU stalls immediately before the fault in two dumps.** `hrtimer: interrupt took 20785052 ns` (**20.8 ms**) 3.5 s before crash #9, and `hrtimer: interrupt took 24513013 ns` (**24.5 ms**) in crash #15. A ~20 000× timer overrun means the vCPU was frozen by the host. That is consistent with a host-side power/C-state/frequency transition rather than anything the guest did.

### One thing I have NOT tested, disclosed up front

#13258's reporter gave a second workaround in a follow-up comment: *"After restoring the Windows virtual memory settings to 'Automatically manage paging file size for all drives,' this issue no longer occurs. When the issue occurred, the paging file size for the C drive was set to 2 GB (this host has 32 GB of physical memory)."*

**This machine has the same class of misconfiguration and I have not yet cleared it.** `AutomaticManagedPagefile : False`, `C:\pagefile.sys` pinned at `InitialSize = MaximumSize = 12288` MB on a 64 GB host, so the commit limit is hard-capped at ~77 GB and cannot grow under pressure. My `.wslconfig` is:

```
[wsl2]
memory=48GB
swap=16GB
processors=8
```

so the guest may claim up to 48 GB of that. I am flagging this rather than waiting, because I would have to sit on the report for another week to test it and the 15-event dataset is useful now. I will restore auto-managed pagefile next and report back either way — if the crashes stop, that is a **second independent confirmation** that a pinned Windows pagefile surfaces in the guest as `Bank 0: b200000080060001`, which is a badly misleading failure mode that sends people off replacing RAM and flashing BIOS.

But note it does not obviously explain the rest: the crash rate barely moved when the guest's memory ceiling went from ~32 GB (default) to 48 GB, and it does not explain how commit pressure becomes a `PCC=1` machine check in the guest rather than an ordinary allocation failure.

### Diagnostic Logs

`collect-wsl-logs.ps1` output to follow in a comment shortly — I am aware from #13258 that the report is not actionable without it, and I will stay responsive to `/logs` and any follow-up. All 15 panic dumps are preserved and I can attach any or all of them; I can also re-run collection while the fault is still reproducing, since it recurs roughly daily.

---

🤖 Posted for @pankgeorg by an AI agent — harness: Claude Code 2.1.277 · model: claude-opus-5
Session: local Claude Code session 70bb1659-64b0-4623-923a-54f9826e8696

Start with the preserved dumps under %LOCALAPPDATA%\Temp\wsl-crashes\ and the forthcoming collect-wsl-logs.ps1 output, then compare the guest MCE records with host WHEA logs and issue #13258. Done means identifying a reproducible root cause and an actionable fix or documented mitigation for the recurring Bank 0 status.

Written by the indexing model from the issue text.