My PC keeps crashing — a full diagnostic walkthrough

A PC that crashes once is an anecdote. A PC that keeps crashing is leaving evidence every single time — and Windows stores all of it. This walkthrough collects that evidence in the order that gets you to a cause fastest: blue-screen dumps first, then per-application crash reports, then the event log to tie the timeline together. Everything here uses free tools, and the file analysis runs in your browser so nothing sensitive leaves the machine.

Step 1: Decide which kind of crashing you have

"Crashing" covers three different diseases with three different diagnoses. Blue screens — the whole machine dies to a sad-face screen and reboots — are kernel crashes, and they are the best case for diagnosis because Windows writes a dump file every time. One program dying repeatedly while Windows itself stays up is an application crash; the evidence lives in Windows Error Reporting. Hard freezes or instant black-screen reboots with no blue screen are the most hardware-flavoured pattern: power, temperature or a component fault that never gives Windows time to react. You can have more than one at once, but diagnose them separately.

Step 2: Blue screens — read the dump, don't guess from the code on screen

The stop code on the blue screen itself (DRIVER_IRQL_NOT_LESS_OR_EQUAL and friends) narrows things a little; the dump file narrows things a lot, because it also records the four crash parameters, every loaded driver, and the crash stack. Grab the files from a working session: press Win, type PowerShell, right-click → Run as administrator, then:

Copy-Item C:\Windows\Minidump\*.dmp "$env:USERPROFILE\Desktop\" -Force

Drop them into the BSOD analyzer — several at once is better than one, because patterns across dumps beat any single verdict. Three outcomes are typical. The analyzer names a third-party driver with high confidence: update or roll back that driver (each verdict links to the driver library entry with official-vendor download links) and you're likely done. It names only Windows core files or gives low confidence: don't chase the kernel — that usually means memory corruption or hardware is muddying the picture, so continue below. Or the stop codes vary wildly between dumps: that scatter is itself a diagnosis, pointing at RAM, storage or power rather than one bad driver — jump to step 5.

Step 3: One program keeps dying — read its error report

For application crashes, Windows Error Reporting keeps a folder per incident. Open it with Win+R → C:\ProgramData\Microsoft\Windows\WER\ReportArchive, sort by date, open the newest folder for your program and drop its Report.wer into the app-crash reader. The single most useful line is the faulting module: when a program crashes inside some third-party DLL — an overlay, a codec, a plugin, a printer driver's UI library — that module is your suspect, not the program. The exception code matters too: 0xC0000005 (access violation) is the generic "a bug happened"; repeated 0xC0000006 (in-page error) means the disk under the program failed a read, which turns this into a storage problem — check the drive's health before reinstalling anything.

Step 4: Tie the timeline together with the event log

Open Event Viewer (Win+R → eventvwr.msc) → Windows Logs → System, and look at the minutes around each crash. Three event IDs do most of the talking. 41 (Kernel-Power): the machine lost power or hard-froze without writing anything — if your "crashes" are all Event 41 with no matching blue screen, think PSU, cable, overheating or hard hardware fault. 1001 (BugCheck): confirms a blue screen and repeats its stop code — useful when dump files were cleaned up. Disk/NTFS warnings (IDs 7, 51, 98, 153): a drive that's erroring underneath everything will produce weird, varied crashes everywhere else; believe these warnings. Our .evtx guide covers exporting logs from another machine.

Step 5: The hardware baseline — when software evidence is muddy

Three checks catch the large majority of hardware-caused instability. RAM: run Windows Memory Diagnostic (Start → type "memory"), or better, MemTest86 from USB for several passes — and if you use an XMP/EXPO memory profile, disable it for a week as a test; "stable" profiles that aren't cause exactly this misery. Storage: check drive health in the maker's tool (Samsung Magician, WD Dashboard, CrystalDiskInfo generically) and run chkdsk C: /f; update SSD firmware while you're there. Heat and power: watch temperatures under load, clean dust, and treat a PSU older than the rest of the machine with suspicion — power delivery faults imitate every other failure. If crashes continue at stock clocks with healthy RAM, disk and temperatures, and the dumps stay inconclusive, that's when a repair shop's component-swap diagnosis earns its fee.

Step 6: Fix, then verify like you mean it

Apply ONE change at a time — the driver update the analyzer pointed at, the XMP toggle, the firmware update — and then use the machine normally for a few days. If a blue screen recurs, analyze the new dump: same culprit means the fix didn't take (try the rollback direction instead); a different culprit or scattered codes moves suspicion back toward hardware. Keep the dumps; a folder of them tells a story single crashes can't.