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

[pankgeorg]

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

#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 Kernel panic - not syncing: Fatal machine check #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 tar with symbolic links #9, and hrtimer: interrupt took 24513013 ns (24.5 ms) in crash SSH seems broken #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

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

[pankgeorg]

WslLogs-2026-09-18_23-40-36.tar.gz

Update: 16th occurrence, and this time collect-wsl-logs.ps1 was tracing across the fault

2026-09-18 23:47:06, ~49 minutes after the crash reported in the issue body. Same status word, no variation:

[ 2905.658602] mce: [Hardware Error]: Machine check events logged
[ 2905.658638] mce: [Hardware Error]: Machine check events logged
[ 2905.658648] mce: [Hardware Error]: CPU 1: Machine Check Exception: 4 Bank 0: b200000080060001
[ 2905.664022] mce: [Hardware Error]: TSC 81e92c67b77
[ 2905.664943] mce: [Hardware Error]: PROCESSOR 0:a06a4 TIME 1789764426 SOCKET 0 APIC 1 microcode ffffffff
[ 2905.667311] mce: [Hardware Error]: Machine check: Processor context corrupt
[ 2905.667701] Kernel panic - not syncing: Fatal machine check

Two things are new here.

1. The trace covers the fault. I started collect-wsl-logs.ps1 at 23:40:36, the panic landed at 23:47:06, and collection stopped at 23:48. So logs.etl spans the ~6.5 minutes before the machine check and the panic itself. This is what #13258 never had. Bundle attached.

2. Shortest uptime to failure yet, by a wide margin. 2905 s — 48 minutes. The previous minimum across the other 15 was 5637 s (1 h 34 m), and the median is around 14 hours. This one also came 49 minutes after the preceding crash, on the very next boot.

Also minor but possibly a hint for whoever reads the trace: this dump logs Machine check events logged twice before the exception line. All 15 earlier dumps log it once.

What was running, precisely

I was deliberately trying to provoke it, so the load is documented rather than guessed:

• 10 concurrent tsc --noEmit typechecks, each in its own memory-capped systemd scope (MemoryMax=1500M, MemorySwapMax=0, CPUQuota=200%), looping. 53 such scopes ran to completion between 23:44 and the panic, every one exit code 0. Largest observed peak in any of them was ~540 MB.
• One unrelated Julia/Pkg.instantiate workload, also capped (MemoryMax=12G, JULIA_NUM_THREADS=2), 17 invocations across the boot.
• Otherwise idle interactive sessions.

This was not a memory-exhaustion event. The guest is configured memory=48GB / swap=16GB and was nowhere near either. Zero OOM events in the entire boot's journal — not in the panic dump, not in journalctl -b -1, not one cgroup kill. Every capped scope exited cleanly on its own.

So what correlates is sustained multicore CPU load, not memory pressure. That fits the other two things already in the report — the continuous Kernel-Processor-Power event 37 firmware throttling, and the multi-millisecond hrtimer overruns showing the vCPU being frozen by the host — considerably better than it fits a commit-limit story.

Honest limits on that claim

n=1. The base rate on this machine is ~0.94 crashes/day, so a 48-minute window carries roughly a 3% chance of catching one regardless of what I did. I am not claiming a deterministic repro. What I am claiming is narrower and checkable: a fault occurred while a WPR trace was running, and the trace is attached.

The pinned-pagefile caveat from the issue body still stands — AutomaticManagedPagefile is still False, so that variable is still uncontrolled. I have not changed it yet, precisely so this capture would be of the same configuration everything else in the report was taken under. That is the next thing I change, and I will report the result either way.

Bundle contents

WslLogs-2026-09-18_23-40-36.tar.gz — logs.etl (23.5 MB WPR/ETW), plus the usual wsl-install-logs.txt, windows-version.txt, .wslconfig, registry and Winsock dumps. Collected with the default LogProfile, Dump : False.

I have all 16 panic dumps preserved and can attach any of them, run collection again against a RestartWslReproMode capture, or add -Dump on the next one if that would help. The fault recurs roughly daily and I can now provoke it reasonably reliably, so please ask for whatever would actually be useful — I will stay responsive.

---

🤖 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

[pankgeorg]

I also opened ~25 chrome tabs on the host, one of which a video call, and tried to run 10 heavily allocating julias (inside the WSL). While claude says julia unrelated, it's highly likely it's very related and it just didn't catch it.

[pankgeorg]

So, this is probably on me. The thing is, I had allocated 48G/64 to WSL, and also limited Window's Pagefile to 12G (because my SSD is only 500G, really nothing these days -with claudes writing 500 worktrees like it's release day). I set these to 32/64 for WSL and unlimited pagefile and will monitor it.

[chemwolf6922]

Hi Παναγιώτης Γεωργακόπουλος (@pankgeorg) .
The memory setting is likely the cause. The log shows many hyper-V allocation failures. Meaning the VM was promised memory that the host cannot provide.
Please check if the system stabilizes after the change.