Recurring 0x1E bugcheck in nt!ExpPoolTrackerChargeEntry on Windows 11 25H2 (26100.8655), not fixed by KB5094135

Pat Gordon 90 Reputation points
2026-06-16T05:45:47.4066667+00:00

My Alienware 18 (model AA18250) on Windows 11 25H2 has been blue-screening repeatedly for about five weeks, and I would like it escalated since the latest cumulative update did not fix it.

Failure signature (consistent across 15+ dumps since early May):

  • Fault bucket: AV_nt!ExpPoolTrackerChargeEntry
  • WER failure hash: 6f13343d-8edf-14f9-0269-6df067c74f57
  • Bugcheck 0x1E (KMODE_EXCEPTION_NOT_HANDLED, parameter 1 = 0xc0000005). The same function also surfaces as 0x3B, 0x23, and 0x135 depending on which subsystem trips it.
  • Triggered by many unrelated processes (explorer.exe, svchost.exe, Registry, and others), which points to the shared kernel pool allocator rather than any single third-party driver.

Analysis already done:

  • Faulting instruction is lock xadd qword ptr [r14+r8], rbp, where r8 (expected to be a PoolTrackTable entry pointer) holds different invalid values on each crash. Different garbage each time indicates a software race, not a hardware bit-flip. Caller is nt!ExpAllocatePoolWithTagFromNode+0x52.
  • ETW kernel tracing shows a burst of roughly 700,000 registry/file kernel events per second immediately before each crash (normal heavy load is 10,000 to 50,000 per second), under filesystem-filter pressure.
  • Hardware ruled out: Windows Memory Diagnostic passed two passes, Dell ePSA passed, and NVMe SMART is clean.

Why I am posting: KB5094135 (build 26100.8655, installed 6/13/2026) did not resolve it. It has recurred on this build with the identical signature on 6/14, 6/15, and 6/16.

Request: escalation to the kernel / pool-allocator team referencing failure hash 6f13343d-8edf-14f9-0269-6df067c74f57, confirmation of whether a fix is planned and in which build, and any supported interim mitigation. I can provide minidumps and the ETW capture on request.

Windows for home | Windows 11 | Performance and system failures

22 answers

Sort by: Newest
Most helpful Newest Oldest
  1. 放 李 5 Reputation points
    2026-07-01T03:42:34.82+00:00

    Similar problem, crash happens when i playing delta force. dump11.txt This is keep happening since i use the windos11,so i guess this should be considered by microsoft`s engineers.

    Was this answer helpful?

    2 people found this answer helpful.
    0 comments
  2. Deleted

    This answer has been deleted due to a violation of our Code of Conduct. The answer was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.

    Comments have been turned off. Learn more

  3. Bryan Stanco 15 Reputation points
    2026-06-22T07:37:02.8533333+00:00

    Posting my minidumps in zip file here as well.

    https://1drv.ms/u/c/e460de3646470951/IQCrYOC76bT5S7-Yo2d2khsMAeHQQZ6LU-lHqB0f36CivT4?e=FQkApc

    Disabling intel NPU gave me all morning without a restart, but when I got home I had another 0x1E failure. Same issues as Pat.

    Was this answer helpful?

    1 person found this answer helpful.
    0 comments
  4. Lester Bernard Reyes 86,810 Reputation points Independent Advisor
    2026-06-22T03:50:59.4066667+00:00

    Hi, thank you for replying. Upon checking the ntkrnlmp.exe error, it is only displaying a general error on the PC and still pointing to tcpip.sys, moreover, have you done the steps above and still have an issue?

    If yes, can you please check the System logs on the PC so I can further examine the root cause of the issue?

     

    To share the System logs, please follow the steps in the link below:

     

    Press the Windows key + X, then select "Event Viewer"

    Click the drop-down of "Windows logs"

    Right-click System > click Filter Current logs > Check: Critical, Warning, and Error > Hit OK

    On the right pane, click "Save Filtered Log File As..."

    Save the System logs file to your desktop and share it by following the steps from the link:

    https://support.microsoft.com/en-us/office/share-onedrive-files-and-folders-9fcc2f7d-de0c-4cec-93b0-a82024800c07

     

    Note: You can also use your preferred cloud storage to upload and share the logs.

    Was this answer helpful?

    0 comments
  5. Pat Gordon 90 Reputation points
    2026-06-21T23:56:44.27+00:00

    Posting a full root-cause analysis in case it helps triage, and to ask whether this can be escalated to the kernel / pool-allocator team. Offsets from ntkrnlmp.exe 10.0.26100.8457; still reproduces on 26100.8655 after KB5094135 (installed 2026-06-13). Failure hash 6f13343d-8edf-14f9-0269-6df067c74f57, faulting IP nt!ExpPoolTrackerChargeEntry+0x40 (P2 low bits ...96570, invariant across ASLR bases).

    Summary: use-after-free in the pool tag tracker. nt!ExAllocateHeapPool has a lock-free fast path that locates a _POOL_TRACKER_TABLE entry from a cached PoolTrackTable base and mask, then calls nt!ExpPoolTrackerChargeEntry to atomically update its accounting fields. The tracker table is dynamically expandable: nt!ExpInsertPoolTrackerExpansion publishes the new base/size under ExpTaggedPoolLock, releases the lock, and then frees the old table with nothing waiting for in-flight lock-free readers to drain. A fast-path charge that snapshotted the old base before an expansion computes an entry pointer into the freed/recycled old table and executes lock xadd against it. If that page has been reused, it bugchecks.

    The fault (052826-17906-01.dmp, .cxr at the exception context):

    nt!ExpPoolTrackerChargeEntry+0x40:
fffff805`bf996570 f04b0fc12c06  lock xadd qword ptr [r14+r8],rbp  ds:002b:ffffa381`b4ba31e8=fffffffffdff47d0

rbp=0000000000000540  r8=ffffa381b4ba31e0  r13=0000000020707249 ("Irp ")  r14=0000000000000008

    r8 is a _POOL_TRACKER_TABLE entry pointer; r14=8 selects NonPagedBytes; rbp=0x540 is the allocation size being added. [r8+8] holds fffffffffdff47d0, not a plausible byte total. Bugcheck SYSTEM_SERVICE_EXCEPTION (3B), exception c0000005. Call chain is a routine IRP allocation: ExpPoolTrackerChargeEntry <- ExAllocateHeapPool <- ExpAllocatePoolWithTagFromNode <- ExAllocatePool2 <- IopAllocateIrpPrivate (tag "Irp ") <- a NtQueryInformationProcess / file-name query.

    Cross-dump fingerprint (the use-after-free tell). Same instruction and hash; r8 is invalid a different way each crash, which is what freed-and-reused memory looks like:

    Dump Process Stop r8 what is at r8 now
    052826-17906-01 logioptionsplus 0x3B ffffa381b4ba31e0 freed/reused, [r8+8]=fffffffffdff47d0
    052026-15875-01 Dropbox 0x1E 0072007400730069 not a pointer; r8/r9/r10 = UTF-16 "istr","y\ma","chin", a ...Registry\Machine... path string in that page
    052726-15765-01 svchost 0x23 ffff80805d5b6330 freed/reused, [r8+8]=ffffffffffff9e20
    052826-18250-01 powershell 0x135 via CmpCallbackFatalFilter same root function

    Four processes, four stop codes, one root function. The stop code is just whichever exception handler catches the fault on the way up. The Dropbox dump is decisive: the tracker-entry pointer points into a page that has been recycled into a registry path string.

    Where the bad pointer is produced (nt!ExAllocateHeapPool). The slow path reads the table base fresh under ExpTaggedPoolLock; the fast path uses a cached snapshot and takes no lock:

    mov  rdx, qword ptr [rsp+38h]    ; cached PoolTrackTable base, NO lock
and  eax, r12d                   ; index &= cached PoolTrackTableMask, NO lock
lea  rbx, [rax+rax*4]            ; rbx = index*5
shl  rbx, 4                      ; rbx = index*0x50  (sizeof _POOL_TRACKER_TABLE)
add  rbx, rdx                    ; entry = base + index*0x50
mov  r8, rbx
call nt!ExpPoolTrackerChargeEntry

    Where the old table is freed (nt!ExpInsertPoolTrackerExpansion):

    call nt!ExAllocateHeapPages                          ; new larger table -> rdi
... memcpy(old -> new) ; memset(tail) ...
mov  [nt!PoolTrackTableExpansion], rdi               ; +bfcde445 publish new base, lock held
mov  [nt!PoolTrackTableExpansionSize], r12           ; +bfcde452 publish new size, lock held
call nt!KeReleaseInStackQueuedSpinLock               ; +bfcde46b release lock
call nt!ExPoolCleanupExpansionTable(old, oldSize)    ; +bfcde47b FREE old table, AFTER unlock

    The publish is correctly serialized under ExpTaggedPoolLock. The defect is that reclamation happens after the lock is released, unprotected against in-flight lock-free readers.

    The race. CPU A (charge) snapshots base+mask with no lock. CPU B grows the table, publishes the new base/mask under the lock, releases, then frees the old table. CPU A computes old_base + index*0x50 and executes lock xadd/lock inc into the freed table.

    Why heavy load is required. A continuous ETW kernel trace shows every crash preceded by a ~3 second burst of ~700,000 kernel events/sec (normal heavy load is 10k-50k/sec), ~42% registry and ~42% file, from a process-creation storm across 24 logical CPUs. That forces tracker-table growth while charges are in flight, and explains the very low public report rate.

    Fix direction. The publish is already serialized; the problem is freeing the retired table immediately after unlock. Most localized fix: defer the free until lock-free readers drain (epoch/generation or an RCU-style barrier) instead of calling ExPoolCleanupExpansionTable right after release. Alternatives: bump a generation counter under the lock on each publish and recheck it on the charge path before the atomic write; or carry the index and recompute the entry from the current base at charge time.

    This is not a single bad unit. Multiple independent users now report the identical hash and faulting offset on the Intel Arrow Lake-HX platform (Core Ultra 9 275HX), across different OEMs and GPUs: Alienware 18, Alienware 16x, and Acer Predator. WER bucket telemetry alone may not surface something this rare; correlated multi-user reports with the same hash through a kernel engineer would. Full kernel dumps, 14 deduplicated minidumps (all same hash), and the ETW captures are available on request.

    Caveat: this is reverse-engineered from optimized release ntoskrnl.exe with public symbols and post-mortem dumps. The fault context, the two-path disassembly, the divergent-r8 fingerprint, and the burst correlation are direct evidence; the exact free/publish ordering in the expansion routine is the one inference the team can confirm internally.

    Was this answer helpful?

    6 people found this answer helpful.

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.