Diagnose BSODs, Crashes and Hardware Errors

Stabilize and preserve evidence

Return CPU, GPU and memory tuning to defaults. Back up important files. Record the stop code, named driver, current task and recent hardware/software changes. Do not run a registry cleaner; it removes context and rarely repairs a kernel crash.

Reliability Monitor

Search Start for View reliability history. The timeline groups application failures, Windows failures, update events and successful installs by day. Open the event near the crash and note the faulting module or bucket. A repeated pattern after one driver or application update is more useful than a single red X.

Event Viewer and dump files

Event Viewer → Windows Logs → System can show WHEA hardware errors, unexpected shutdowns, storage resets and driver failures. Kernel-Power event 41 confirms an unclean shutdown but usually does not name the cause.

Windows can write small dumps to C:\Windows\Minidump. WinDbg from Microsoft can analyze them with !analyze -v. A driver named in the stack is a lead; memory corruption can make an innocent module appear near the crash.

Hardware isolation

• Memory: test at default JEDEC settings; use a bootable memory test.
• Storage: check NVMe/S.M.A.R.T. health, cable/slot connections and filesystem status.
• CPU/GPU: monitor temperature and power, then run separate controlled stability tests.
• Power: remove adapters/risers, check correct PSU cabling and test stock limits.
• Firmware: load defaults, then update only with a safe model-specific path.

Escalate cleanly

If crashes continue on supported Windows, stock settings and known-good drivers, collect system information, dump files and exact reproduction steps for the hardware vendor, game developer or Microsoft support. Reinstalling Windows can separate software from hardware only after backups and with minimal drivers/apps during the test.