BSOD dump archive: nt!ExpPoolTrackerChargeEntry+0x40 on Win11 25H2
=================================================================

Reddit post:
https://www.reddit.com/r/techsupport/comments/1tt7tow/34_weeks_chasing_a_win11_25h2_bsod_always_in/

System
------
- Alienware 18 Area-51 (model AA18250)
- Intel Core Ultra 9, 64 GB RAM
- Samsung PM9F1 2TB NVMe
- NVIDIA RTX 5090 Laptop + Intel iGPU
- Windows 11 Home 25H2, build 26200.8457 (kernel image 26100.8457)

What's in this archive
----------------------
14 unique minidumps spanning 5/1/2026 through 5/28/2026 (deduplicated by
filename across multiple capture folders).

Full kernel MEMORY.DMP files exist for several of these crashes but are
not included for privacy reasons (multi-GB RAM snapshots). Happy to share
specific full dumps on request.

The signature
-------------
Every "core" crash buckets to the same kernel function:

  Faulting symbol      : nt!ExpPoolTrackerChargeEntry+0x40
  Faulting instruction : lock xadd qword ptr [r14+r8], rbp
  Param 1              : 0xc0000005 (access violation)
  WER failure bucket   : AV_nt!ExpPoolTrackerChargeEntry
  Failure hash         : 6f13343d-8edf-14f9-0269-6df067c74f57

Disassembly shows r14 is always a small constant (8 or 0x20, set by a
cmovne just above the faulting instruction). r8 is the input param,
expected to be a pointer to a PoolTrackTable entry. r8 is garbage at
fault time, and it's a DIFFERENT KIND of garbage across dumps (one was
UTF-16 ASCII residual "istr" from registry-path processing, another was
a valid-looking kernel pointer in the wrong region). Different garbage
each fault rules out a hardware bit flip and points at a software bug
in the caller (nt!ExpAllocatePoolWithTagFromNode+0x52) failing to set
r8 correctly in some edge case.

Three pool tags seen at fault time: CM64 (Configuration Manager parse
context), CcWB (Cache Write Back), VReg (Virtual Registry). So this is
not tag-specific, it is in the general pool tracker path.

Manifests under four different stop codes depending on which subsystem's
exception handler catches the fault:
  0x1E  KMODE_EXCEPTION_NOT_HANDLED
  0x3B  SYSTEM_SERVICE_EXCEPTION (syscall path)
  0x23  FAT_FILE_SYSTEM (when fastfat.sys is in the call chain)
  0x135 REGISTRY_FILTER_DRIVER_EXCEPTION (caught in nt!CmpCallCallBacksEx,
        including the kernel's own VrpRegistryCallback)

Per-dump summary
----------------
| File                  | Date       | Triggering process               | Failing symbol                          | Notes                                  |
| --------------------- | ---------- | -------------------------------- | --------------------------------------- | -------------------------------------- |
| 050126-16203-01.dmp   | 2026-05-01 | claude.exe                       | nt!PpmEventAddAffinityMaskAsSubset+0x120 | Different function, possibly unrelated |
| 051526-17000-01.dmp   | 2026-05-15 | svchost.exe                      | nt!ExpPoolTrackerChargeEntry+0x40       | Same hash                              |
| 051626-15796-01.dmp   | 2026-05-16 | logioptionsplus_agent.exe        | mountmgr!MountMgrQueryDosVolumePath+0x13b | Different function, possibly unrelated |
| 052026-10984-01.dmp   | 2026-05-20 | SearchIndexer.exe                | nt!CcTelemetryBucketizeLatency+0x6c     | Cascade after primary crash            |
| 052026-15406-01.dmp   | 2026-05-20 | Registry (kernel process)        | nt!ExpPoolTrackerChargeEntry+0x40       | Same hash                              |
| 052026-15875-01.dmp   | 2026-05-20 | Dropbox.exe                      | nt!ExpPoolTrackerChargeEntry+0x40       | Same hash                              |
| 052026-16171-01.dmp   | 2026-05-20 | svchost.exe                      | WdFilter+0x51f1c                        | Cascade                                |
| 052026-16687-01.dmp   | 2026-05-20 | explorer.exe                     | nt!ExpPoolTrackerChargeEntry+0x40       | Same hash                              |
| 052026-20234-01.dmp   | 2026-05-20 | Dell.TechHub.Instrumentation...  | msrpc!NdrpHandleAllocate+0x39           | Cascade                                |
| 052626-16593-01.dmp   | 2026-05-26 | (unparseable, truncated)         | (dump corrupted)                        | Subsequent crash interrupted dump-write |
| 052726-15765-01.dmp   | 2026-05-27 | ServiceShell.exe                 | nt!ExpPoolTrackerChargeEntry+0x40       | Same hash                              |
| 052726-15796-01.dmp   | 2026-05-27 | svchost.exe                      | nt!ExpPoolTrackerChargeEntry+0x40       | Same hash                              |
| 052826-17906-01.dmp   | 2026-05-28 | logioptionsplus_agent.exe        | nt!ExpPoolTrackerChargeEntry+0x40       | Same hash                              |
| 052826-18250-01.dmp   | 2026-05-28 | powershell.exe                   | nt!CmpCallbackFatalFilter+0x24          | Via VRP, root in ExpPoolTrackerChargeEntry |

Across 11 of 14 dumps the WER bucket / failure hash is identical. The 5/1
and 5/16 crashes in different functions appear to be unrelated. The
SearchIndexer / svchost / Dell.TechHub crashes in other kernel functions
look like cascades after the primary 5/20 22:44 crash, before a clean
boot reset the pool state.

Already ruled out
-----------------
- RAM           : Windows MemDiag clean, Dell ePSA firmware-level test clean
- Storage       : NVMe SMART zero errors, 0% wear, chkdsk clean, dirty bit not set
- System files  : sfc /scannow clean, DISM /Online /Cleanup-Image /ScanHealth clean
- GPU           : not in any stack; disabled dGPU and still crashed on iGPU
- Defender      : wdfilter.sys not in any primary stack; added Defender exclusions, reduced frequency but did not stop crashes
- KB5089549     : bug predates it (first hit 5/15, pre-cumulative); LCU agent silently reinstalls when uninstalled
- VBS / HVCI    : disabled via registry + bcdedit, verified SecurityServicesRunning=0, still crashed
- Third party   : no third-party kernel drivers other than Realtek; all stacks entirely in ntoskrnl.exe
- Driver Verif. : not yet run; system already crashes 1-3x daily, Verifier would worsen that

Sample WinDbg invocation
------------------------
kdX64.exe -z "<dump file>" -y "srv*c:\symbols*https://msdl.microsoft.com/download/symbols" -c "!analyze -v; q"

Contact
-------
DM-able via the Reddit post above. Microsoft support engineer is engaged
on a ticket and has the full dump package. Looking for either confirmation
that someone else hits this hash, internal-Microsoft tracking status, or
a workaround beyond reducing concurrency.
