Prime95 Worker Stopped: Finding the Unstable Core
Short answer: When one Prime95 worker stops with an error while the others keep running, the test has usually localised the instability for you. Each worker runs its own calculation thread, so a single failing worker often corresponds to a specific core or thread path that is not stable at the current settings, while the rest of the processor is holding up. That is more useful information than a whole-system crash. Record which worker stopped and when, confirm the finding in results.txt, and then verify any fix in a deliberate order: remove the overclock first, then adjust per-core or voltage settings conservatively, then retest long enough to trust the result. The troubleshooting hub covers the other error messages.
Why a single stopped worker points at a specific path
Prime95 divides the Torture Test across workers, and each worker continuously checks its own results against known correct values. If one worker’s calculation goes wrong, that worker stops and reports the failure; the others, whose results are still correct, continue. Modern processors are not perfectly uniform: cores differ slightly in how much voltage they need at a given clock speed, and many overclocking methods push some cores harder than others, through per-core multipliers, boost behaviour or shared voltage settings. A pattern of the same worker failing repeatedly, especially early in a run and at the same settings, is therefore consistent with the core or cores behind that worker being the weakest link. It is a strong lead, not a court verdict – memory and shared power delivery are shared by all workers – but it tells you where to look first. The underlying error itself is explained in FATAL ERROR: Rounding explained.
Read results.txt to pin it down
The on-screen window scrolls and can be closed by accident; results.txt is the durable record. You will find it in the folder where Prime95 was extracted. Open it and look for the lines around the failure: the worker number, the date and time, the test that was running, and the error text. Note three things in your own log. First, elapsed time: a worker that fails within minutes at a given setting is failing decisively, while one that fails after many hours is marginal. Second, repeatability: run the same preset and settings again and see whether the same worker fails. Third, the preset: a worker failing in Small FFTs keeps the suspicion on the CPU path, while failures only in Large FFTs or Blend widen the suspect list to memory and the memory controller. Reviewing how Prime95 workers and threads are set up will help you map worker numbers to your processor’s threads correctly, since changing the worker count or thread assignment changes that mapping.
| Pattern you observe | Most useful interpretation | Next move |
|---|---|---|
| Same worker fails early, every run, same settings | That core or thread path is not stable at those settings. | Reduce or remove that core’s overclock, or return to stock, and retest. |
| Different workers fail on different runs | A shared resource is more likely: voltage, heat, memory or power delivery. | Test at full stock settings and check temperatures before touching per-core settings. |
| A worker fails only after hours, when hot | A marginal setting that degrades with temperature. | Improve or verify cooling, then retest at the same settings to see if the failure moves or disappears. |
| Workers fail only in Large FFTs or Blend | Memory or the memory controller moves to the top of the list, per the Torture Test menu’s own hint. | Retest at base memory speed with the memory profile disabled. |
The verification order after a worker stops
- Reproduce it once. Before changing anything, rerun the same preset at the same settings and confirm which worker fails. One unrepeatable event is a note; two matching events are a diagnosis.
- Return to stock and retest. Load default settings, disable CPU and memory overclocks, and run the same preset. If every worker now runs cleanly for a solid session, the processor is performing correctly at its rated settings and your tuned settings were the problem.
- If you overclock per core, back off the failing path first. Reduce the overclock on the core or cores associated with the failing worker before touching the rest. Retest after each single change. This preserves most of a good overclock while removing the part the test actually objected to.
- If you adjust voltage, do it conservatively and singly. A small increase within the limits in your processor and motherboard documentation can stabilise a marginal core, but voltage is not a free fix: it raises heat and stress. Change only one voltage setting at a time, by the smallest step your firmware offers, and record the before and after values. Never copy a value from another system and assume it suits yours.
- Confirm with a long run. The official stress.txt guidance is 6 to 24 hours for a thorough check. A worker that previously failed in twenty minutes and now passes a full long run at the final settings is a credible fix; a twenty minute pass is not.
When it is not the core
If workers keep stopping at fully stock settings, with different workers failing on different runs and temperatures under control, stop thinking in terms of a single weak core. That pattern points at shared systems: memory, the memory controller, power delivery, or a board-level setting. Work through the decision tree in Hardware failure detected from the top, and test memory separately before concluding that the processor itself is faulty. A processor that fails Prime95 at its rated stock settings with known-good memory and cooling is uncommon, and that conclusion should be the last one you reach, not the first.