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. Matt Seger 0 Reputation points
    2026-07-18T19:27:53.4033333+00:00

    I'm having the exact same issue.
    Figured I'd add my name to this post.

    Alienware 18 Area-51 AA18250
    BIOS Version 2.5.0
    Intel(R) Core(TM) Ultra 7 255HX-20
    32Gb RAM
    NVIDIA GeForce RTX 5060

    Was this answer helpful?

    0 comments
  2. Timothy Lawless 10 Reputation points
    2026-07-09T05:07:41.9833333+00:00

    I found my way here from a post on reddit. I have two systems that have exhibited this problem. We bought two Alienware laptops, model AA16250 last year for Christmas. This is running the Ultra 9 275HX cpu. One laptop began crashing in April, the other one started crashing about two weeks ago. Dell replaced the mainboard on the 1st laptop and that resolved the crashes. I'm going through dell support presently to get the 2nd laptop fixed.

    1. This is a hardware (cpu?) issue. I shared my notes on the Dell forum and Reddit. You must look at the memory.dmp file generated by either a kernel or full dump to diagnose this. The failures are triggered by a locked atomic operation at nt!ExpPoolTrackerChargeEntry+0x40 (the lock xadd qword ptr [r14+r8],rbp instruction). From a memory.dmp file you can see from the !pte command that the address at [r14+r8] in the context of the exception was present, writable, supervisor, and write-back cacheable. From only a mini-dump you can't see this, and one would probably blame corruption of the pool tracking data structures.
    2. The crashes cluster around a particular core. In my first laptop, all but one crash was on core 17. On the 2nd laptop all crashes have been on core 9.

    In the case of my first laptop, demonstrating the behavior from #1 and the clustering from #2 was how I convinced dell to perform a mainboard replacement.

    Based on this thread, I am now wondering if the clustering is not an additional diagnostic pattern. In Bryan's mini-dumps, all but two of the crashes are on core 3. In Tyler's crashes, 3 of the 4 are on 19. This matches my observed clustering on my two laptops. I suspect that this "clustering" may also contribute to making the crashes "look" different, and may hinder identifying this issue in incoming error reports from users. On the 1st laptop, almost all the crashes traced back to a svchost and either NtOpenKeyEx, NtDeleteKey, NtSetValueKey, NtQueryInformationProcess. On the 2nd laptop, all but one crash pointed to DirectX. I was able to write a powershell script that triggered the crash quickly on laptop 1, but it does nothing to laptop 2. The fault is independent of the subsystem, with the constant being the locked atomic operation.

    Finally, this problem seems to have a delayed onset. In my case both systems entered into service at the same time and have been used for gaming daily, yet one didn't crash until 6 months after purchase, and the other started about 4 months after purchase.

    Best of luck,

    --Tim

    Was this answer helpful?

    3 people found this answer helpful.
  3. 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
  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. 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

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.