My PC has started freezing and crashing seemingly at random, and I'm having trouble determining whether the cause is the GPU, storage, CPU, or something else. The system uses a Ryzen 7 5800X3D on an ASRock B550M Steel Legend with 32GB DDR4-3600, an RTX 4070, a 500GB NVMe SSD, two SATA SSDs, an Intel AX200 Wi-Fi adapter, and an Elgato capture card. I'm running Windows 11 now, though the problem also happened on Windows 10.
The first crash occurred while I was using a Nintendo Switch through the capture card. The display froze and showed a BSOD, but Windows could not save a crash dump. A few days later, the system crashed again with WHEA_UNCORRECTABLE_ERROR and booted into the BIOS. After that, Windows had corrupted system files, could not sign in properly, and the Start menu stopped working. Event Viewer showed many bad-block errors, although CrystalDiskInfo reported that the drives were healthy. SFC found problems, but DISM could not locate a repair source. I eventually backed up my user folder and performed clean installations of Windows 10 and then Windows 11.
After another crash involving CRITICAL_PROCESS_STOPPED and a corrupted or missing Windows Boot Manager entry, I disabled PBO and changed the DisplayPort connection for my second monitor. The computer then booted normally. GPU, CPU, and memory stress tests passed, both with PBO and XMP enabled and disabled. However, I'm still seeing occasional frame drops and the second monitor sometimes fails to detect its signal automatically.
Could a failing GPU port or DisplayPort cable really cause this level of system instability, or are the WHEA and bad-block errors more suggestive of an NVMe drive, PCIe connection, motherboard, or another hardware problem? What would be the best next troubleshooting steps?
2 Answers
The WHEA error is more useful than the fact that the GPU was involved when the crash happened. Check the Kernel-Power event and its BugCheckCode, rather than looking only for a separate BugCheck entry. Windows displays those codes in decimal; for example, 0x124 appears as 292. The first parameter can help narrow it down: 0x0 generally points toward the CPU, 0x4 toward PCIe, and 0x10 toward NVMe storage. The fourth parameter contains the underlying hardware error packet.
The inability to create a dump is also significant. Unless the page file is encrypted, unavailable, or on a failing drive, Windows normally writes crash information through the page file and creates the dump during the next boot. Since you also saw bad-block errors and later encountered corrupted Windows files and boot entries, I would put the NVMe drive or its PCIe path ahead of the GPU port as a suspect. Back up anything important, check the NVMe drive in another slot or system if possible, and test with the operating system installed on a known-good drive. Also try a different DisplayPort cable and monitor input, but a bad display connection alone usually would not corrupt Windows or cause WHEA storage errors.
A GPU output port or cable can explain a monitor losing signal, but it normally cannot explain corrupted system files, failed boot entries, bad-block events, and missing crash dumps all by itself. Those symptoms are more consistent with storage, a PCIe link, motherboard instability, or power problems.
Start with a full backup, then run the system at stock settings: disable XMP, PBO, and any GPU overclock or undervolt. Test with one memory module at a time, disconnect unnecessary PCIe and SATA devices, and temporarily use a different known-good boot drive. Reseat the NVMe drive and GPU, inspect the power connectors, and try another DisplayPort cable separately. If the crashes follow the original NVMe drive, replace it; if they follow the motherboard slot or occur with multiple drives, investigate the board, CPU socket, and power supply. Passing FurMark or OCCT does not rule out intermittent PCIe or storage faults, because those tests may never exercise the failing path.
There aren’t any dump files to upload, which is part of the problem. I’d focus on the saved Kernel-Power and WHEA events instead, since they may still contain the hardware error details.