Prime95 Crashes, Freezes or Blue Screens: How to Isolate the Cause
Short answer: A crash, freeze, sudden reboot or blue screen during Prime95 is a system-level failure under load, which is a different symptom from a calculated error. Prime95 itself reports wrong results with an error message; when the whole machine goes down instead, the cause is usually one of four areas – temperature, power delivery, memory, or drivers and firmware – and the way to find it is to separate those areas one at a time instead of changing everything at once. Return the system to stock settings first: a crash at tuned settings tells you very little until you know whether it also happens at default settings. More context is in the troubleshooting hub.
First, describe the crash precisely
| Symptom | What it tends to suggest | First check |
|---|---|---|
| Freeze with the image still on screen | A core, memory or driver hang under sustained load. | Note how long the test ran and whether temperatures were still climbing. |
| Instant reboot with no error screen | Often power delivery or protection behaviour: the system cut or lost stable power under load, or a firmware protection tripped. | Check power supply capacity and connections, and whether it happens at stock settings. |
| Blue screen with a stop code | Windows caught a fault it attributed to a driver or to corrupted system state, which itself can be caused by unstable hardware. | Record the exact stop code and any file name shown, word for word, before searching for it. |
| Crash only after a long warm-up | Heat build-up or a marginal setting that fails when hot. | Repeat while watching temperatures, as in the overheating checks. |
Step 1: rule temperature in or out
Run the test again while watching temperatures in a sensor monitor, and note the last readings before the crash if you can. If the machine only goes down after temperatures have climbed to the upper range for your processor model, treat cooling as the lead suspect and work through the ladder in our guide to Prime95 reaching 100°C: stop, inspect the cooler mounting and paste, check case airflow, and retest. If the crash happens within the first minute at modest temperatures, temperature is unlikely to be the primary cause, and you can move on with more confidence.
Step 2: separate power from everything else
A stress test that loads every core at once draws sustained power in a way most everyday workloads do not. An ageing, undersized or failing power supply, or a loose or incorrect CPU power cable, can present as a clean instant reboot with nothing useful in the logs. Check that the CPU power connectors are fully seated, that you are not overloading a single cable run where your power supply’s manual advises against it, and that the supply is sensibly sized for your processor and graphics card at stock settings. Testing with any overclock removed also reduces power draw, which is another reason the stock-settings test comes first: if the reboots stop at stock, power headroom and your tuned settings are both back in the frame.
Step 3: test memory as its own suspect
Unstable memory can crash a machine under load just as surely as it can produce a rounding error, and the crash may blame an innocent driver whose data was corrupted in RAM. Disable any memory overclock profile and retest at the base memory speed. If the crashes stop, restore memory settings gradually rather than all at once. For a dedicated investigation, follow our Prime95 memory test guide, which explains what Large FFTs and Blend can show and where a dedicated bootable memory tester takes over. Note which preset was running when the crash occurred: a crash in Large FFTs or Blend that never happens in Small FFTs keeps memory near the top of the list.
Step 4: use the Event Viewer as a notebook, not an oracle
After a crash, open the Windows Event Viewer and look at the System log around the time of the failure. You are looking for context, not a verdict: whether Windows recorded an unexpected shutdown, whether the same driver or service appears in warnings before each crash, and whether disk or display errors cluster around the event. Write down any blue screen stop code exactly as shown. Treat that code as a lead to check against Microsoft’s own documentation for that code, because the authoritative meaning and suggested checks for each code live there; general articles, including this one, should not be treated as the definition of a specific code. If the codes differ from crash to crash while the hardware settings stay the same, that inconsistency itself is information: random, shifting faults under load often point back to marginal hardware stability rather than to one broken driver file.
Step 5: drivers and BIOS, in that order of effort
Only after temperature, power and memory have been separated should you spend effort on software. Update chipset and graphics drivers from the manufacturer’s own site, one package at a time, retesting between changes. A BIOS or firmware update is justified when the board maker’s release notes describe a stability or compatibility fix relevant to your processor or memory, and it should be done carefully, at stock settings, following the board maker’s instructions exactly – never as a casual experiment in the middle of an unstable system. If crashes happen at fully stock settings, with sound cooling, tested memory and current drivers, the remaining explanation is a hardware fault that needs component-level testing or professional diagnosis.
Next steps
Keep a written log of each run: preset, settings, time to crash, temperatures and any stop code. That log is what turns a frustrating week of random reboots into a short, solvable list. Start again from the troubleshooting hub if a new symptom appears, and read Prime95 errors vs an unstable system for how to judge a machine that errors without fully crashing.