Windows 11: Recurring application crashes and BSODs on an Intel i9-14900HX laptop

Question

Windows 11: Recurring application crashes and BSODs on an Intel i9-14900HX laptop

James Patrick-Gleed 0

I've been experiencing frequent application crashes and BSODs on my laptop for the last couple of months and am struggling to identify a common cause.

Using WinDbg to analyse application crash dumps, I frequently encounter 0xc0000005 access violations, including INVALID_POINTER_READ. However, the faulting module varies between crashes.

The problem affects several unrelated applications, including Microsoft Edge, WinDbg, Steam and games such as Battlefield 6 and X4: Foundations. Some crashes reference nvgpucomp64.dll, while others identify the application itself or, on one occasion, TiWorker during Windows repair and diagnostic attempts.

Troubleshooting already attempted:

Performed a clean Windows 11 reinstallation from USB, wiping the previous installation.
Reinstalled the NVIDIA graphics driver.
Disabled Hyper-Threading in the BIOS.
Experimented with Intel XTU, which appeared to improve stability temporarily, but the problems returned.

None of these measures has provided a lasting solution.

System specifications:

Laptop: ASUS ROG Strix G16 G614JVR

CPU: Intel Core i9-14900HX (24 cores / 24 threads with Hyper-Threading disabled)

RAM: 16 GB

GPU: NVIDIA GeForce RTX 4060 Laptop GPU, plus Intel UHD Graphics

BIOS: G614JVR.322

Operating system: Windows 11 Home, build 26300

NVIDIA driver: 32.0.16.2101

Intel graphics driver: 32.0.101.6790

One example application crash produced the following WinDbg summary:

Exception code: 0xc0000005 (access violation)

Failure bucket: INVALID_POINTER_READ_c0000005_X4.exe!Unknown

Faulting module: X4.exe

I understand that an access violation is not, by itself, proof of a hardware fault.

My question is: Given that these crashes affect multiple unrelated applications and have persisted after a clean Windows installation and graphics driver reinstallation, what diagnostic steps would you recommend to identify the underlying cause? In particular, how would you distinguish between CPU instability, faulty RAM, firmware issues, graphics driver problems and other potential causes?

I'm happy to provide further WinDbg output, BSOD stop codes or diagnostic results if useful.I've been experiencing frequent application crashes and BSODs on my laptop for the last couple of months and am struggling to identify a common cause.

Using WinDbg to analyse application crash dumps, I frequently encounter 0xc0000005 access violations, including INVALID_POINTER_READ. However, the faulting module varies between crashes.

The problem affects several unrelated applications, including Microsoft Edge, WinDbg, Steam and games such as Battlefield 6 and X4: Foundations. Some crashes reference nvgpucomp64.dll, while others identify the application itself or, on one occasion, TiWorker during Windows repair and diagnostic attempts.

Troubleshooting already attempted:

Performed a clean Windows 11 reinstallation from USB, wiping the previous installation.

Reinstalled the NVIDIA graphics driver.

Disabled Hyper-Threading in the BIOS.

Experimented with Intel XTU, which appeared to improve stability temporarily, but the problems returned.

None of these measures has provided a lasting solution.

System specifications:

Laptop: ASUS ROG Strix G16 G614JVR

CPU: Intel Core i9-14900HX (24 cores / 24 threads with Hyper-Threading disabled)

RAM: 16 GB

GPU: NVIDIA GeForce RTX 4060 Laptop GPU, plus Intel UHD Graphics

BIOS: G614JVR.322

Operating system: Windows 11 Home, build 26300

NVIDIA driver: 32.0.16.2101

Intel graphics driver: 32.0.101.6790

One example application crash produced the following WinDbg summary:

Exception code: 0xc0000005 (access violation)

Failure bucket: INVALID_POINTER_READ_c0000005_X4.exe!Unknown

Faulting module: X4.exe

I understand that an access violation is not, by itself, proof of a hardware fault.

My question is: Given that these crashes affect multiple unrelated applications and have persisted after a clean Windows installation and graphics driver reinstallation, what diagnostic steps would you recommend to identify the underlying cause? In particular, how would you distinguish between CPU instability, faulty RAM, firmware issues, graphics driver problems and other potential causes?

I'm happy to provide further WinDbg output, BSOD stop codes or diagnostic results if useful.

endong liu 0 Reputation points

2026-10-29T18:03:08.5366667+00:00
Same fingerprint on a different 14900HX laptop (Redmi G Pro 2024) — adding data points, including boot-stage freezes

I appear to have the same problem on a different machine, and some of my symptoms cannot be explained by any software-layer cause, so I want to add them to the record.

System

Laptop: Redmi G Pro 2024 (Xiaomi), motherboard TM2211

CPU: Intel Core i9-14900HX (8P+16E, 32 threads)

RAM: 64 GB

GPU: NVIDIA RTX 4060 Laptop, driver 32.0.16.2101 (same driver version as OP)

BIOS: RMGRP6B0P0909 (2025-03-05)

OS: Windows 11, build 26300 (clean reinstall on 2026-09-30; the machine threw a 0xEF (CRITICAL_PROCESS_DIED) BSOD on the very first day after that reinstall)

Storage: both NVMe drives SMART-healthy, zero disk I/O errors

Symptoms (ongoing since at least 2026-10-05)

Whole-machine hard freezes: screen frozen, no BSOD, no error, only a forced power-off recovers. Event log shows Kernel-Power 41 with no BugCheck. Seven freezes on 2026-10-05/06, and five of them happened before boot completed — before any driver or user application was loaded.

Random application crashes with access violations across completely unrelated processes: MSVC compiler (cl.exe 0xC0000005 in c1xx.dll/c2.dll, repeatedly, roughly one per 10-30 min of sustained parallel compile load), PowerShell (clr.dll), Microsoft Defender engine (MsMpEng.exe), .NET runtime optimizer, system services (svchost AppXSvc), Electron renderers, WPS, Feishu, StartMenuExperienceHost. Faulting module is different every time — exactly like OP. A WPS process produced three different memory-class exception codes (0xC0000409, 0xC00001A5, 0xC0000005) within 16 seconds on retry.

Crash dump analysis (LocalDumps, parsed myself): every recent dump is 0xC0000005 in user mode, faulting addresses inside whatever module happened to be executing — the "computation yields corrupted data" fingerprint, not a single buggy component.

WHEA: on 2026-10-05 18:24, 387 "corrected hardware error" events (PCI Express Root Port, AER) burst within one second; otherwise zero WHEA.

Progressive worsening then partial retreat: freeze interval shrank from ~25 minutes to ~2 minutes over two days in early October; after the September reinstall and driver updates the freeze storm paused, but application-level 0xC0000005 crashes continue daily to this day (5x cl.exe in the last 48 h, plus a PowerShell access-violation dump this morning).

Already ruled out

RAM: Windows memory diagnostics pass (also: freezes happen at boot with RAM barely touched).

Software: clean OS reinstall (crashed the same day), NVIDIA driver fully updated (32.0.16.2101, Oct 2026), third-party input-method/audio injection DLLs removed, browser hardware acceleration off — crashes and freezes continue regardless.

Load/thermals: routine usage ~14% RAM, pagefile unused.

Why I think this adds evidence for the CPU-instability hypothesis

Boot-stage freezes are, by construction, independent of drivers and applications.

Identical exception fingerprint on a second, unrelated 14900HX laptop (this thread) with the same GPU and even the same NVIDIA driver build.

Intel's official position is that mobile HX parts are not affected by Vmin Shift, but there are community reports of 14900HX systems showing clock-voltage-dependent single-bit errors and microcode-sensitive crash behavior. My machine's "random module every time, all memory-class, reinstall never fixes" pattern matches the desktop Vmin Shift reports point by point.

My own mitigation experiment (capping turbo via maximum processor state 99%) is queued for tomorrow; the OP's note that Intel XTU temporarily improved stability points the same direction. Happy to share my full forensics report (event-log timeline, dump parses, WHEA burst details) if useful to either the investigation or a warranty claim.Same fingerprint on a different 14900HX laptop (Redmi G Pro 2024) — adding data points, including boot-stage freezes

I appear to have the same problem on a different machine, and some of my symptoms cannot be explained by any software-layer cause, so I want to add them to the record.

1 answer

Your answer

Answer 1

The pattern points to a broad system-level instability rather than a single application defect, because the failures span multiple unrelated apps and continued after a clean Windows reinstall. An access violation such as 0xc0000005 often means an invalid pointer was dereferenced, but the fault can be in the crashing function or in an earlier component that passed bad data.

A practical way to separate likely causes is:

Capture the exact BSOD stop codes and timing Record the exact stop code text and the actions that led to the failure. Also check Event Viewer for critical errors in the same time window.
Check Device Manager for hardware or driver faults Open Device Manager from the Start button context menu and look for devices marked with !. For any affected device, review its properties and update, disable, or uninstall it as appropriate. This is the quickest way to identify an obvious driver or device problem.
Run Windows Memory Diagnostic Since crashes occur across unrelated applications, memory testing is a key next step.
- Press Windows key + R
- Run mdsched
- Select Restart now and check for problems (recommended)
- If the standard test is clean, press F1 during the test and switch from Standard to Extended, then press F10
- After restart, review the result notification, or check Event Viewer for MemoryDiagnostics-Results
If memory errors appear, that strongly points to RAM or memory-path instability.
Check free disk space and storage-related symptoms Windows needs sufficient free space for swap files and related operations. Keep roughly 10% to 15% free space available. Also review Event Viewer for disk-related errors occurring near the crashes. In-page I/O errors are commonly associated with hardware failure.
Use Driver Verifier carefully to isolate a bad driver Driver-related faults are a common cause of stop code errors. Windows includes Driver Verifier; start it by entering Verifier at a command prompt. Verify only a small set of suspect non-Microsoft drivers at a time, because Driver Verifier adds overhead and can make the system less stable while testing. This is most useful if BSODs continue and no memory issue is found.
Analyze crash dumps, not just app dumps For recurring BSODs, configure the system to generate a complete memory dump, then copy memory.dmp to another PC and open it in WinDbg. Set the symbol path to the Microsoft public symbol server: https://msdl.microsoft.com/download/symbols Then open the dump and use !analyze to identify the bug check details and any recurring driver or subsystem.
Collect user-mode dumps for the crashing apps Since application crashes are frequent, create live dumps from Task Manager by right-clicking the process in Processes or Details and selecting Create live memory dump file. Comparing several dumps can show whether the same driver, graphics component, or memory corruption pattern appears across different applications.

How to distinguish the likely categories:

Faulty RAM / memory-path instability: multiple unrelated apps crash with varying faulting modules; memory diagnostic may report errors; bug checks may vary.
Driver problem: Device Manager warnings, Event Viewer driver errors, or Driver Verifier forcing a more specific crash that points to one driver.
Graphics driver issue: repeated dumps or bug checks consistently implicate the same graphics-related module such as the NVIDIA stack.
Storage / firmware / hardware path issue: Event Viewer shows disk or controller errors near the crash; dump analysis shows in-page I/O patterns.
CPU or broader platform instability: failures persist across a clean reinstall, affect unrelated applications, and do not converge on one driver or one RAM error pattern.

Given the steps already completed, the highest-value next actions are:

Run Windows Memory Diagnostic with the Extended test.
Check Event Viewer and Device Manager immediately after the next crash.
Configure and analyze a complete memory dump in WinDbg.
If dumps do not identify a clear driver, use Driver Verifier on a small set of suspect third-party drivers only.
Capture several user-mode live dumps from different crashing applications and compare whether the same module recurs.

If the next BSOD stop codes or dump analysis consistently point to one driver or subsystem, that becomes the primary target. If the failures remain random across clean OS state, multiple apps, and multiple modules, that is stronger evidence of underlying hardware or firmware instability than of an application-specific problem.

References: