u/bryan0087

I bought this computer about three weeks ago, and not long after that it started randomly blue-screening. At first it would happen every once in a while, but eventually I had three crashes back-to-back. Since I’m pretty new to troubleshooting this kind of thing, I started digging into it with help and a lot of trial and error. My wife was pretty frustrated that a brand-new computer was already giving me problems.
One thing that stood out right away was when the crashes happened. They almost always occurred while the computer was sitting idle, downloading games, or doing something in the background. I can play games for hours without a single issue.

Specs
\-Alienware 16X Aurora AC16251
\-Intel Core Ultra 9 275HX (Arrow Lake)
\-32 GB DDR5-5600
\-BIOS 2.4.0
\-Windows 11 Build 26100/26200 family
\-Modern Standby (S0 Low Power Idle only)

The bugchecks I’ve seen include:
0x1E – KMODE\_EXCEPTION\_NOT\_HANDLED
0x3B – SYSTEM\_SERVICE\_EXCEPTION
0x7E – SYSTEM\_THREAD\_EXCEPTION\_NOT\_HANDLED

The common exception across them is 0xC0000005 (Access Violation).
Failure hash:
6f13343d-8edf-14f9-0269-6df067c74f57

BlueScreenView almost always points to ntoskrnl.exe, but it never consistently identifies the same third-party driver.

**Hardware checks**
I couldn’t find any evidence of:
Bad RAM
GPU overheating
CPU overheating
WHEA hardware errors
Machine Check Exceptions

**Driver troubleshooting**
The first thing I did was reinstall every driver from Dell’s support page for my specific system.
After that, I enabled Driver Verifier hoping it would identify a faulty driver. Early minidumps repeatedly referenced the Intel NPU driver (npu\_kmd.sys version 32.0.100.4724), so I disabled the Intel NPU in Device Manager. The crashes continued, so that didn’t appear to be the root cause.

Across nearly every dump I continued seeing Intel platform power management components such as:
intelpep.sys
Intel PMT
ipf\_acpi.sys
ipf\_lf.sys
Intel Dynamic Tuning / IPF
Intel Management Engine components

They appeared frequently, but none of them were clearly identified as the driver causing the corruption.
At that point I performed a completely clean Windows installation. The crashes continued.
I also used DDU to completely remove and reinstall my GPU drivers. No change.
Reliability Monitor showed repeated Dell D3 Svc DTH Sub Agent failures around some of the earlier crashes, so I removed both McAfee and Dell SupportAssist. That also made no difference.
The only thing that noticeably changed the behavior was disabling sleep, disabling display sleep, disabling the Intel NPU, and forcing the system to use only the dedicated GPU. Instead of crashing multiple times a day, the system could sometimes run for a day or two before crashing again. The issue became less frequent, but it never disappeared.

I also attempted ETW tracing several times, but the machine would often crash again before I could stop the trace and save the results.
At that point my working theory was that the repeated Intel power management components were related somehow, but I still couldn’t identify a single driver responsible.

While searching for similar reports, I found a Microsoft Q&A thread from someone running an Alienware 18 with very similar symptoms. Their conclusion was that the crash occurred inside Windows kernel pool management rather than pointing to a specific driver. Since then I’ve seen more users posting similar reports.
I switched from collecting minidumps to full kernel memory dumps and analyzed them with WinDbg.

The full dump paints a much clearer picture.
The crash occurs when Windows accesses a corrupted kernel memory structure. Ntoskrnl.exe itself doesn’t appear to be the original cause. Instead, something corrupted kernel memory earlier, and the corruption isn’t detected until later when the kernel accesses that damaged structure.

Running both the minidumps and the full dump through additional analysis consistently pointed to:
FAILURE\_BUCKET\_ID: AV\_nt!ExpPoolTrackerChargeEntry
PROCESS\_NAME: sihost.exe
The interesting part is that sihost.exe (Shell Infrastructure Host) is just the process that happened to touch the corrupted memory. It was opening a registry key when Windows attempted to update kernel pool accounting.

The faulting instruction:
lock xadd qword ptr \[r14+r8\], rbp
was attempting an atomic update using an invalid pointer. The access violation occurred near the guard page for sihost.exe’s expanded kernel stack, which looks much more like previously corrupted data finally being accessed than a bug inside sihost.exe itself.
Based on everything I’ve found, this looks less like a faulty application or driver crashing directly and more like memory corruption that’s only detected later by the Windows kernel.

If anyone doesn’t know, full kernel dumps contain much more useful information than standard minidumps. Most users never enable them, so Microsoft may not be seeing enough of the data needed to connect these reports.

If you’d like to look at my dumps and supporting files, I’ve uploaded them in my Dell forum thread.

One final note: Dell support has told me they’re aware of the issue, but motherboard replacements are still being recommended in many support cases. If this is the same issue I’m seeing, replacing motherboards is unlikely to solve it. It would be far more valuable if these reports, along with the associated dumps, reached the Windows kernel engineers for investigation. If anyone has contacts on the Microsoft kernel team or knows the best way to get this in front of the right people, I’d appreciate the advice. I’ve already submitted multiple feedback reports and they guys on the Microsoft q&a have as well.