I built this PC myself, and it worked reliably for about three years before suddenly becoming unstable. It now freezes or shows BSODs, usually CRITICAL_PROCESS_DIED with 0xC000021A or 0xEF. The system lasts roughly 10–15 minutes in normal Windows and around 30 minutes in Safe Mode. A combined CPU and GPU stress test causes a crash at almost exactly three minutes every time, while the BIOS can remain open for hours. Disconnecting the internet sometimes seems to extend the runtime.
After a crash, the computer reboots into the BIOS instead of Windows. Choosing Save and Exit or pressing Escape only causes another reboot back into the BIOS. A complete power-off with the physical power button is required before Windows will boot normally again.
The hardware is a Ryzen 5 5600X, ASRock B550M Steel Legend, 32GB of G.Skill DDR4-3600, an RTX 4060 Ti, a 2TB GTL Poseidon NVMe SSD, a GameMax GX-850 850W power supply, and an ID-Cooling 240mm AIO. Temperatures are reasonable under load, around 75°C for the CPU and 78°C for the GPU.
MemTest86 completed four full passes with no errors, CrystalDiskInfo reports the SSD at 96% health, and moving the SSD to another M.2 slot made no difference. I also updated the BIOS to version 4.00 and performed a completely clean Windows 11 installation, installing only the graphics driver afterward, but the crashes continued. Reported voltage readings also appear stable. Event Viewer mainly shows Kernel-Power event 41, along with several errors that seem to be consequences of the crash.
What would be the best next step for identifying whether this is the PSU, storage, motherboard, or another component?
4 Answers
The symptoms point strongly toward a hardware or connection problem rather than a normal Windows installation issue. CRITICAL_PROCESS_DIED and 0xC000021A can occur when Windows loses access to the system drive, and returning to the BIOS after a crash may mean the NVMe drive temporarily disappeared. Even though the health report looks good, test with a different known-good boot drive if possible, and inspect the M.2 socket, mounting screw, and drive firmware.
I would also test the power supply before trusting the voltage readings from software. A weak or failing PSU can pass idle checks while failing when the CPU and GPU load changes quickly. Try a known-good, reputable PSU with the correct separate power cables, and run the system with BIOS settings fully at stock—no CPU, memory, boost, or GPU overclocking.
The next useful diagnostic step is to check whether Windows created files in C:WindowsMinidump. Those dump files can show which driver or kernel component triggered the stop error. If none exist, configure Windows to create small memory dumps and check again after another crash. The dump analysis is much more useful than the generic Kernel-Power 41 event, which usually only records that the system did not shut down cleanly.
MemTest86 makes defective RAM less likely, but it does not completely eliminate a motherboard slot, memory-controller, or marginal XMP/DOCP setting. Test one memory module at a time in the board's recommended slot with the memory profile disabled. If the machine still fails at the same point under combined load, the PSU, motherboard, GPU, or storage path becomes more suspicious than the memory itself.
There is no obvious overclock, but I will reset the BIOS to defaults and test with another PSU rather than relying on the reported software voltages.