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: Oldest
  1. 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

  2. 放 李 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 No comments

  3. MG 0 Reputation points
    2026-07-02T23:59:32.6233333+00:00

    I have a brand new Lenovo ThinkPad P16 and I am experiencing exactly the same issue. I have 192GB of RAM, Core Ultra 9 275HX Intel. Overall, 16 verified crashes with identical issue as reported here. June 15 update didn't resolve it. Request to fix it ASAP. For now, my $9K laptop is useless.

    Was this answer helpful?

    1 person found this answer helpful.
    0 comments No comments

  4. Gary Nebbett 6,536 Reputation points
    2026-07-05T08:28:16.4366667+00:00

    Hello All,

    I suspect that the belief that this problem is due to a locking issue with Microsoft code is probably misplaced. Indeed, Microsoft might not be in a position to address the problem.

    Pat's analysis assumes that there is one "pool tracker table" (PoolTrackTable), but this is not the case on multiprocessor systems: they have one table per processor and PoolTrackTable is just the table for processor 0.

    19: kd> dq nt!PoolTrackTable l 1
    fffff803`d6efe9e0  ffffce0f`c2602000
    19: kd> dq nt!ExPoolTagTables l 1a
    fffff803`d6efa9e0  ffffce0f`c2602000 ffffbd80`3ac41000
    fffff803`d6efa9f0  ffffbd80`3ad00000 ffffbd80`3ad71000
    fffff803`d6efaa00  ffffbd80`3ae40000 ffffbd80`3aea1000
    fffff803`d6efaa10  ffffbd80`3af3d000 ffffbd80`3b000000
    fffff803`d6efaa20  ffffbd80`3b069000 ffffbd80`3b105000
    fffff803`d6efaa30  ffffbd80`3b19b000 ffffbd80`3b235000
    fffff803`d6efaa40  ffffbd80`3b2d0000 ffffbd80`3b366000
    fffff803`d6efaa50  ffffbd80`3b400000 ffffbd80`3b496000
    fffff803`d6efaa60  ffffbd80`3b540000 ffffbd80`3b600000
    fffff803`d6efaa70  ffffbd80`3b680000 ffffbd80`3b700000
    fffff803`d6efaa80  ffffbd80`3b796000 ffffbd80`3b830000
    fffff803`d6efaa90  ffffbd80`3b8c6000 ffffbd80`3b960000
    fffff803`d6efaaa0  00000000`00000000 00000000`00000000
    

    The "one table per processor" design removes the need for the lock management suggested by Pat.

    If there is no room in a per-processor table for a new entry, then an "expansion" table (shared by all processors) is used; this table is adequately protected by locks. As far as I can tell, this expansion table never shrinks (or is removed); the two full dumps available in this thread indicate that the expansion table has not been used (PoolTrackTableExpansion == 0).

    The values that Pat has observed in _POOL_TRACKER_TABLE NonPagedBytes fields (e.g. fffffffffdff47d0 and ffffffffffff9e20) are plausibly correct; there is no requirement to free a pool allocation on the same processor from which it was allocated. Treating these NonPagedBytes values as signed integers and summing across all processors gives reasonable results.

    In the two full dumps, the tag being tracked as CM64. The !poolused debugger extension performs the necessary summation of the individual processor table values.

    5: kd> !poolused 1 CM64
    ........................
     Sorting by Tag
    
                          NonPaged                                Paged
     Tag     Allocs     Frees    Diff       Used     Allocs     Frees    Diff       Used
    
     CM64   2829193   2829191       2        480          0         0       0          0
    

    The instruction that "causes" the exception uses the r14 register, which is not saved in the _KTRAP_FRAME created by KiGeneralProtectionFault; disassembly of ExpPoolTrackerChargeEntry shows that r14 must contain either 0x8 (offset of NonPagedBytes) or 0x20 (offset of PagedBytes). The "Circular Kernel Context Logger" indicates that no interrupt has plausibly taken place between entry into the ExpPoolTrackerChargeEntry routine and the exception. In some of the minidumps, a _CONTEXT structure with valid r14 value at time of exception can be found, showing that r14 contains an expected value.

    nt!ExpPoolTrackerChargeEntry+0x40:
    lock xadd qword ptr [r14+r8],rbp
    

    The !pte command on an address formed by the r8 value plus an assumed r14 value of 0x8 or 0x20, shows that the address writen by the xadd command is valid and writeable:

    5: kd> !pte @r8+8
                                               VA ffff8081a7b9bd58
    PXE at FFFFB65B2D96C808    PPE at FFFFB65B2D901030    PDE at FFFFB65B202069E8    PTE at FFFFB64040D3DCD8
    contains 0A00000125A0F863  contains 0A00000125A10863  contains 0A0000013AC11863  contains 8A000001262E8963
    pfn 125a0f    ---DA--KWEV  pfn 125a10    ---DA--KWEV  pfn 13ac11    ---DA--KWEV  pfn 1262e8    -G-DA--KW-V
    

    The "mystery" (to me) is what caused the general-protection exception.

    According to "Intel 64 and IA-32 Architectures | Software Developer’s Manual", the only reason for a general-protection exception when executing the xadd instruction is "If the memory address is in a non-canonical form". I think that the !pte command demonstrates that this is not the case.

    The limited range of models and CPU types on which the problem has been observed suggests that there is a hardware dependency, so the obligation to resolve the problem does not rest solely on Microsoft.

    Gary

    Was this answer helpful?

    7 people found this answer helpful.

  5. Gallus 0 Reputation points
    2026-07-08T13:37:49.8366667+00:00

    I am also having random crashes with 2 different Arrow Lake Systems (270k plus z890 Hero). I tested all the Hardware with different systems, it’s no a hardware fault. I clean reinstalled Windows 11, that didn’t solve the random bsod (especially also happening during idle/low load) either. There has to be something wrong with how Windows interacts with those arrow lake CPUs, cause all non Arrow lake systems I have access to don’t have this issue. This has been happening for over a month now and I tried everything hardware side possible to fix it aswell a reinstalling Windows for the clean out of the box software experience and nothing works.

    Was this answer helpful?

    0 comments No comments

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.