Another affected machine, different OEM, same failure hash. Adding data because
this thread's most recent data point is KB5095093, and I can confirm the defect
still reproduces on the August 2026 cumulative update.
FAILURE HASH: 6f13343d-8edf-14f9-0269-6df067c74f57
FAULTING IP: nt!ExpPoolTrackerChargeEntry+0x40
INSTRUCTION: lock xadd qword ptr [r14+r8], rbp
HARDWARE
- Lenovo Legion Pro 7 16IAX10H (machine type 83F5)
- Intel Core Ultra 9 275HX, 24 logical processors
- 64 GB DDR5-6400 (2x32 GB Micron MTC16C2085S1VC64BD1), running at 6400 MT/s, 1.1 V
- NVIDIA GeForce RTX 5080 Laptop + Intel Arrow Lake iGPU
- BIOS Q7CN78WW (2026-06-23, the latest Lenovo release)
Note this is a Lenovo, whereas the reports so far have been Alienware, Dell and
Acer. The common factor across all of them is the Core Ultra 9 275HX with 24
logical processors, which is consistent with a race window that widens with the
number of concurrent lock-free readers.
OPERATING SYSTEM
- Windows 11 25H2, currently build 26200.9168
- Windows installed 2025-09-27; machine ran without a single bugcheck until May 2026
ONSET CORRELATES EXACTLY WITH KB5089549
- 2026-04-15 KB5083769 installed (26200.8246)
- 2026-04-18 to 2026-05-12: zero bugchecks (this is the full System log retention window, which begins 2026-04-18, so 24 consecutive clean days)
- 2026-05-12 22:39 KB5089549 staged (26200.8457)
- 2026-05-13 00:11 KB5089549 finalized after restart
- 2026-05-13 18:32 FIRST BUGCHECK, ~18 hours later, first full day on the new build
22 BUGCHECKS TO DATE (2026-05-13 to 2026-08-16)
The faulting IP low bits are invariant across ASLR bases and change only when a
cumulative update relocates ntoskrnl. They group cleanly into four kernel builds:
...96570 26200.8457 9 crashes 2026-05-13 to 2026-05-31
...a32a0 26200.8655 5 crashes 2026-06-12 to 2026-07-06
...970b0 26200.8875 7 crashes 2026-07-13 to 2026-08-13
...a22a0 26200.9168 1 crash 2026-08-16
The ...96570 group on 26200.8457 is the identical offset already reported in this
thread for that build.
Full list (date, bugcheck, faulting IP):
2026-05-13 18:32 0x3B 0xfffff804eed96570
2026-05-18 21:17 0x3B 0xfffff804e0996570
2026-05-25 12:46 0x3B 0xfffff805d0796570
2026-05-26 13:56 0x3B 0xfffff805d1796570
2026-05-27 22:07 0x3B 0xfffff805cf996570
2026-05-29 13:59 0x3B 0xfffff800bc316570
2026-05-30 13:48 0x3B 0xfffff806db166570
2026-05-30 13:59 0x1E 0xfffff807dbd86570
2026-05-31 11:14 0x3B 0xfffff805bfc76570
2026-06-12 14:28 0x1E 0xfffff803883a32a0
2026-06-18 23:41 0x3B 0xfffff806b3da32a0
2026-06-27 15:41 0x3B 0xfffff806d0fa32a0
2026-06-29 09:33 0x1E 0xfffff807e0fa32a0
2026-07-06 21:36 0x1E 0xfffff8027f3a32a0
2026-07-13 10:24 0x3B 0xfffff803897970b0
2026-07-21 23:47 0x3B 0xfffff802b35970b0
2026-07-28 20:55 0x3B 0xfffff801815970b0
2026-07-28 21:02 0x3B 0xfffff805be9970b0
2026-08-02 16:39 0x3B 0xfffff802d77970b0
2026-08-03 12:02 0x1E 0xfffff8037bf970b0
2026-08-13 13:45 0x3B 0xfffff8068eb970b0
2026-08-16 11:36 0x3B 0xfffff802e0da22a0
FOUR DUMPS ANALYZED, FOUR UNRELATED CALLERS, ONE FAULT SITE
2026-08-16 0x3B SearchProtocolHost
nt!ExpPoolTrackerChargeEntry+0x40 <- nt!ExAllocateHeapPool <-
nt!ExpAllocatePoolWithTagFromNode <- nt!ExAllocatePool2 <-
FLTMGR!FltpAllocateIrpCtrlInternal <- FLTMGR!FltpCreate <- nt!NtOpenFile
Pool tag 'FMic'. r8 = ffffb501f7443990, faulted on [r8+8], r12 = 0xfff (mask),
rcx = 0x28 (entry size), rbp = 0x6c0 (allocation size being charged).
2026-08-13 0x3B claude.exe
nt!ExpPoolTrackerChargeEntry+0x40 <- nt!ExAllocateHeapPool <-
nt!ExpAllocatePoolWithTagFromNode <- nt!ExAllocatePool2 <-
bindflt!BfFormatPathFromFileNameInfo <- bindflt!BfGenerateFileNameCallback <-
FLTMGR!FltGetFileNameInformation <- bindflt!BfPreDirectoryControl
Here !analyze buckets to bindflt and yields a different FAILURE_ID_HASH
(2af63562-9a83-2d62-7e53-91772b13c090), but the faulting instruction is the
same nt!ExpPoolTrackerChargeEntry+0x40. Worth noting for anyone matching on
hash alone: the bucket follows whichever module requested the allocation.
2026-08-03 0x1E svchost.exe
Reached via nt!KiGeneralProtectionFault, i.e. a NON-CANONICAL pointer, not an
unmapped page. Chain: nt!ExpPoolTrackerChargeEntry+0x40 <- nt!ExAllocateHeapPool
<- nt!ExAllocatePool2 <- nt!CmpAllocatePool <- nt!CmpAllocateParseContext <-
nt!CmOpenKey
2026-08-02 0x3B Registry
nt!ExpPoolTrackerChargeEntry+0x40 <- ... <- nt!CmpAllocatePool <-
nt!CmpConstructNameFromKeyNodes <- nt!CmQueryKey <- nt!NtQueryKey
The mix of an unmapped-page fault and a non-canonical-pointer #GP across the set
matches the "different garbage in r8 each time" fingerprint already described here.
WHAT IS RULED OUT ON THIS MACHINE
- Zero WHEA-Logger events of any kind over the whole period.
- Driver Verifier was already run against non-Microsoft drivers back in May and caught nothing.
- BIOS is the latest available.
- The crashes occur across three completely different external display setups (4K monitor plus OLED TV over HDMI to the dGPU; a USB-C DisplayPort triple portable monitor rig; and no external displays at all), so no display or USB path is involved.
- Triggering processes are always different: Windows Search indexer, claude.exe, svchost, the Registry process.
WORKLOAD
Developer machine. Heavy use of AI coding agents and local web development
stacks, which generate exactly the kind of process-creation storms with combined
registry and file activity described earlier in this thread as the trigger
condition.
REQUEST
Confirmation of whether a fix is in progress and which build will carry it.
I can provide any of the 22 minidumps on request.