Two minidumps off an ASUS ROG Strix G18 / Core Ultra 9 275HX that land in the same place as an existing cluster, with one new data point: the board was already replaced and it came back.
WER failure hash : 6f13343d-8edf-14f9-0269-6df067c74f57
Fault bucket : AV_nt!ExpPoolTrackerChargeEntry
Faulting IP : nt!ExpPoolTrackerChargeEntry+0x40
Instruction : lock xadd qword ptr \[r14+r8\],rbp
Exception : #GP (nt!KiGeneralProtectionFault), NTSTATUS 0xC0000005 as bugcheck
Build : 26200.9457 (ge_release.240331-1435)
Not adding much to the root-cause work already in the MS thread, but two things there are worth revisiting with this data.
**1. It is a #GP, not a #PF.** Both of my dumps fault through `nt!KiGeneralProtectionFault`. Per SDM Vol. 2, the documented cause of #GP for `xadd` with a memory operand is a non-canonical address. The r8 values I have are kernel addresses (`ffffe70056adb1c0` region), so on their face they are canonical. That lines up with what Gary Nebbett found on the full dumps - valid and writable per `!pte` - and his conclusion that the cause of the GP is unexplained. I could not run `!pte` myself: these are minidumps, and per Timothy's note a minidump has no page tables, so the walk fails with `Unable to get PXE`. I have switched the machine to kernel dumps so the next one is answerable.
**2. The board swap result points away from silicon.** One report in the thread argues for a CPU fault on the strength of a mainboard replacement fixing it. ASUS Japan replaced the motherboard here and the identical hash reproduces. Laptop boards carry the CPU soldered, so that board carried a different CPU than the one the bug was first seen on. Onset here was also far quicker - Windows reinstalled 2026-08-26 16:10, first crash 2026-08-27 12:53 - which looks like workload rather than silicon degradation.
**What I can show from the dumps**
Crash 1 (0x3B, 2026-09-06 04:16, cmd.exe, processor 7 of 24):
nt!ExpPoolTrackerChargeEntry+0x40
nt!ExAllocateHeapPool+0x13a3
nt!ExpAllocatePoolWithTagFromNode+0x52
nt!ExAllocatePool2+0x8a
Ntfs!NtfsGetReparsePointValue+0x7cf
Ntfs!NtfsCommonCreate+0x194d
FLTMGR!FltpLegacyProcessingAfterPreCallbacksCompleted+0x3fe
Crash 2 (0x1E, 2026-08-27 12:53) is a different subsystem entirely - `NETIO!IsEmpty` on the LWF send path - same root function. Consistent with the "one function, many stop codes" pattern already described.
r14 = 0x8 (NonPagedBytes selector), so the xadd target is `[r8+8]`. I do not have a kernel dump yet, so I cannot say whether that page is present or recycled.
**Questions**
- Does the expansion path in `nt!ExInsertPoolTrackerExpansion` still reclaim the retired table immediately after `KeReleaseInStackQueuedSpinLock`? If so, the fast path's cached `PoolTrackTable` base/mask has exactly the window Pat describes.
- On the multiprocessor point Gary raised - with one tracker table per processor, is the free path for the per-processor tables the same shape, or only the shared expansion table?
- Anyone on 26200 seeing this? The reports I can find are on 26100.8655.
Hardware is clean on my side if it is useful: zero WHEA machine-check errors in the full retained history, `Kernel-WHEA/Errors` enabled with 0 records, nvidia-smi shows nothing retired, NVMe 0 read/0 write errors, `chkdsk /scan` clean on both volumes.
Dumps and full `!analyze -v` output: Microsoft OneDrive
Existing thread: Recurring 0x1E bugcheck in nt!ExpPoolTrackerChargeEntry on Windows 11 25H2 (26100.8655), not fixed by KB5094135 - Microsoft Q&A