Prime95: Hardware Failure Detected – What to Do Next
Short answer: In Prime95, Hardware failure detected, consult stress.txt file means a worker computed a result that did not match the known correct result, so the program stopped that worker. The program’s own stress.txt guide is direct about the interpretation: suspect the hardware first. An error of this kind usually reflects an unstable overclock, memory instability or heat, not a bug in Prime95. The one exception the documentation names is narrow: if the exact same error repeats at the exact same place every time, that pattern is worth raising with the developers on the Mersenne Forum, because it may indicate a genuine software problem. Everything else should start as a hardware investigation.
Why the program blames hardware first
The Torture Test is a self-checking workload. Unlike a benchmark that simply measures speed, it compares results against answers that are already known to be correct. When a modern processor running at correct, in-specification settings executes that code, it should produce the correct answer every time. A mismatch therefore means something in the chain – cores, cache, memory controller, RAM, power delivery or cooling – did not hold up under that load. That is also why the message can appear on a machine that never crashes in games or office work: everyday workloads rarely check their own arithmetic, so the same marginal instability can stay invisible for months until a self-checking test exposes it. The related FATAL ERROR: Rounding guide explains the most common form of this message in detail.
Record this before you change any setting
| Detail to record | Why it matters |
|---|---|
| Which worker stopped, and its thread assignment | A single failing worker can point to a specific core or thread path. |
| The preset and FFT size that were running | Small FFTs stress the CPU and caches hardest; Large FFTs stress the memory controller and RAM. |
| How long the test ran before the failure | Failures within minutes suggest a large instability; failures after many hours suggest a marginal one. The official guide notes both patterns occur. |
| Whether the failure repeats at the same place | This is the dividing line in stress.txt between a hardware investigation and a possible software report. |
| Temperatures and settings at the time | You need a baseline before you start changing variables. |
A decision tree you can follow
- Are you overclocked or undervolted in any way, including a memory profile? If yes, return the BIOS or firmware to default settings, disable the memory overclock profile, and retest with the same preset. A pass at stock settings followed by a failure at your tuned settings means the tuned settings are not stable, however well they seemed to work elsewhere.
- Does the failure happen in only one preset? If Blend or Large FFTs fail while Small FFTs passes, follow the menu’s own hint and investigate memory and the memory controller first: test at base memory speed, test one memory configuration change at a time, and consider a dedicated memory test. If Small FFTs fails as well, the CPU cores, cache, cooling or power delivery move to the top of the list.
- Does it only fail when the system is fully warmed up? If failures arrive late in a run alongside high temperatures, treat cooling as the first suspect. Stop, let the system cool, inspect the cooler mounting and airflow, and retest while watching temperatures.
- Does it fail at stock settings, with reasonable temperatures, in more than one preset? At that point, systematic hardware testing is justified: test memory separately, check power supply health and connections, update the BIOS or firmware carefully if a known stability fix applies to your board, and consider testing components one at a time if you have spares.
- Does the exact same error repeat at the exact same place, every run? Only now does the software branch of the tree apply. Save the full results, note your exact Prime95 version (the current release is 30.19 build 20) and system details, and ask on the Mersenne Forum with that evidence attached, as stress.txt directs.
What this message is not
It is not a report that a specific component has died, and it does not name the guilty part. The message tells you a calculation was wrong; finding which subsystem produced the wrong result is your investigation, using the tree below. It is also not a reason to replace parts immediately. A large share of these reports end at the first branch of the tree, with an overclock, a memory profile or a cooling problem that costs nothing to correct. Replacement hardware is the conclusion only after stock settings, sound cooling and separately tested memory still produce failures. Keeping that order saves both money and time, and it is why the record-keeping step above matters: without notes, every new test run restarts the argument from the beginning.
How long to retest after each change
Every change deserves a test long enough to mean something. The official stress.txt recommendation is to run the Torture Test for 6 to 24 hours for a thorough stability check, with short 10 to 15 minute runs used while overclocking to explore each frequency step before a final long test. Our guide to how long to run Prime95 explains that guidance and its limits. A system that once failed after three hours has not been cleared by a twenty minute pass.
Common mistakes with this message
The most common mistake is reinstalling Prime95 or Windows and retesting with identical hardware settings, which predictably produces the identical result. A second mistake is raising voltages broadly until the message stops, without knowing which subsystem was marginal and whether the new settings stay within the manufacturer’s documentation for your parts. A third is dismissing a single failure because the machine feels fine in daily use. Stress.txt leaves the decision to keep using a machine that reports errors to personal preference, but it is clear that the error itself is real information about your hardware, not noise to silence. If your system also crashes or reboots under load, work through the crashes and blue screens guide in parallel, starting from the troubleshooting hub.