GPU Load Plus Large File Copies Cause Repeatable BSODs—Is the Kingston NVMe Failing?
Asked by
MellowBirch42
My Windows 11 PC repeatedly crashes when the GPU is under heavy load at the same time as large file transfers. The system uses an Intel i7-14700K, RTX 4080 Super, MSI PRO Z790-A MAX WIFI, 32GB DDR5, a Kingston Fury 1TB NVMe as the Windows drive, and an XPG S40G 512GB NVMe as a secondary drive. The crashes usually follow this pattern: a game or shader load starts, an SSD reaches 100% active time, the system freezes or black-screens, and then it either BSODs or reboots. Reported bugchecks include 0x154 UNEXPECTED_STORE_EXCEPTION, 0x7A KERNEL_DATA_INPAGE_ERROR, 0xEF CRITICAL_PROCESS_DIED, 0x1E KMODE_EXCEPTION_NOT_HANDLED, and 0xC0000006 STATUS_IN_PAGE_ERROR. One dump referenced nt!HvpGetCellPaged with STATUS_IN_PAGE_ERROR, while another showed CORRUPT_MODULELIST_0xEF and failed while writing the memory dump. CPU-only stress, CPU stress during a roughly 200GB copy, and GPU-only stress are stable. Combining GPU stress with a large file copy reproduces the crash, however, and has done so several times. I have updated the motherboard BIOS and SSD firmware, disabled overclocks and XMP, and tried moving the Kingston drive to another M.2 slot. After moving it, four 200GB copy tests during GPU stress completed without a crash, although I am continuing to test. What would be the best way to distinguish between a failing SSD or controller, a motherboard or PCIe-slot problem, a PSU or power-delivery issue, and a GPU/NVMe interaction?
Answers
A PSU or power-delivery problem is still possible because the GPU and NVMe are being stressed simultaneously, but the fact that the issue appears tied to one drive or one M.2 location makes the storage path the stronger lead for now. Verify the GPU power cable is firmly seated, avoid adapters if possible, and check whether the PSU has enough capacity and suitable dedicated cabling. If the failure follows the Kingston drive after swapping slots and cables where applicable, replace the drive before blaming the motherboard or PSU.
Reply to this answer
The different bugchecks do not necessarily mean several unrelated problems. If the storage device temporarily disappears or returns corrupted data, Windows can report paging errors, critical-process failures, registry faults, and even apparently random kernel exceptions. The failed dump-writing messages also fit a system that is losing access to the system drive during the crash. Moving the SSD and getting four successful combined tests is encouraging, but it is not conclusive—continue with longer tests, inspect the drive's health logs, and keep a current backup.
Reply to this answer
Run separate isolation tests rather than relying only on the combined workload. Put the Kingston drive in the slot normally used by the XPG drive, test the XPG drive under the same copy workload, and if possible copy between drives while monitoring both temperatures and SMART/NVMe health data. Check Event Viewer for disk, storahci, stornvme, WHEA-Logger, and PCIe errors immediately before the crash. If only the Kingston drive fails regardless of slot, replace or RMA it. If the problem follows the slot, investigate the motherboard or PCIe connection.
Reply to this answer
The firmware and BIOS versions are worth checking because some NVMe controllers have firmware bugs that only appear during sustained I/O. Update the Kingston drive using the vendor's SSD utility and install the latest stable motherboard BIOS and chipset or storage drivers. Since those updates did not resolve the issue, the fact that changing M.2 slots helped is significant: it points more toward a particular slot, socket contact, PCIe link, or motherboard path than toward Windows itself.
Reply to this answer
The first thing I would do is return the entire system to conservative defaults: load BIOS defaults, disable XMP, remove any CPU or GPU overclocking or undervolting, and retest. Memory instability can produce a wide variety of storage-looking bugchecks, including paging and corrupted-module errors. Since the crashes are repeatable, test one variable at a time and keep a record of which drive and M.2 slot are being used.
MellowBirch42: I tested with the system at stock settings and also disabled XMP, but the crashes still occurred.
Reply to this answer
Add your answer
Answers are reviewed before publication.
MellowBirch42: The Kingston firmware and motherboard BIOS were already updated. I also had an earlier SATA-controller-related crash that stopped after a driver update, but this newer failure pattern returned later.