Interpreting Prime95 Results: results.txt and prime.log Explained
Quick facts: Prime95 30.19 build 20 records what it did in text files in its own folder, principally results.txt for test outcomes and related log output often referred to from the program’s files. A passing entry means the computed result matched the known correct result. A rounding error or a hardware failure message means it did not, and the program’s stress.txt guidance says to suspect hardware first: unstable settings, memory problems, or overheating. This guide shows the shape of those entries and how to use the worker information in them. Entry wording below is shown as a format illustration to teach the layout, not as a log copied from any specific machine.
Where the evidence lives
Everything important is in the folder you extracted Prime95 into, which is another reason that folder must be writable. results.txt accumulates outcome lines over time, so a long-lived folder holds a history across many runs and even across machines if the folder travels. Before you interpret anything, note the date, preset, worker layout, and settings for the run you care about, and consider copying results.txt to a dated backup before the next run overwrites your context with newer lines. The Torture Test’s strength is that it checks arithmetic against known answers; the log is simply the written record of those checks, worker by worker.
What a passing entry looks like
A pass is recorded as a completed test with its identifying details and a successful result, without an error message. As a format illustration, expect a line pattern of this shape:
[Worker #1] Test completed successfully / no errors reported (format illustration)
The teaching points are the worker identifier at the start and the absence of an error term. One passing short run is weak evidence; a passing entry at the end of a long run in the preset you intended, with the worker layout you intended, is the evidence that matters. Always confirm the run actually lasted as long as you think it did. A test that stopped early because a worker was never started can look deceptively tidy in a quick glance at the log.
What a rounding error looks like
A rounding error means a computed value differed from the expected value by more than the allowed tolerance during the check. As a format illustration, expect a pattern of this shape:
[Worker #2] FATAL ERROR: Rounding was 0.5, expected less than 0.4 (format illustration)
The exact numbers vary by test, which is why the illustration is labelled as format only. The diagnostic content is consistent: rounding errors under load point first to unstable core or memory settings, voltage that is insufficient for the frequency, or heat changing the processor’s behaviour during the run. Note which worker reported it and after how long. Then change one variable and repeat the same preset. The dedicated diagnosis is in FATAL ERROR: Rounding explained.
What a hardware failure entry looks like
When the program detects a mismatch it may stop the worker and record a hardware failure message. As a format illustration:
[Worker #3] Hardware failure detected, consult stress.txt file (format illustration)
Read that message literally and calmly. It means this computation on this hardware at these settings produced a wrong answer. It does not, by itself, prove a permanently damaged processor; most such messages in overclocking practice trace back to settings, memory, or cooling that can be corrected and retested. It also does not mean the software is at fault. stress.txt makes the exception narrow: only if the identical error repeats at the identical place every time should you consider asking on the Mersenne forum whether you have found a program issue. The full response sequence is in Hardware failure detected: what to do.
Locating the problem by worker and core
The worker tag is your map. If you arranged workers by core groups and only one worker ever fails, suspect the settings or silicon associated with that part of the processor, or the memory channel pattern that worker’s preset exercises. If different workers fail on different runs with the same settings, suspect something global: memory timings or voltage, power delivery, or temperatures that rise over time. Pair the log with your run note: preset, elapsed time, and peak temperature you observed. A failure in the first minutes at Small FFTs tells a different story from a failure in hour nine of Blend, even if the error line looks similar. Small and early suggests core settings; late and in Blend or Large suggests heat soak or memory. Use those patterns to choose the next test, not to declare a verdict from one line.
When to ask for help, and what to bring
If two careful cycles of one-change-at-a-time testing still leave you with the same first error, outside help becomes reasonable, whether from a motherboard or memory maker’s support channel or from the Mersenne forum in the narrow case stress.txt describes. Bring evidence, not a summary from memory: the exact error lines from results.txt, the worker number, the preset, the elapsed time, your full settings note, and what you already changed and retested. State whether the failure happens at completely stock settings, because that single fact separates a tuning problem from a possible hardware fault more clearly than any other detail. A helper who can see the first error in context can often spot the pattern quickly, while a report that only says the test failed forces everyone to start from zero.
A clean interpretation routine
Stop the test properly. Save results.txt. Write down preset, workers, threads, settings, duration, and observed temperatures. Identify the first error, not the last, because later lines may be consequences. Change exactly one variable. Rerun the identical test. Compare first-error behaviour across the two logs. That routine, repeated, is how a text file becomes a diagnosis instead of an argument.
Next steps
For live faults, use the troubleshooting hub. For setup, revisit Worker Setup and How to Use Prime95. Every tutorial is indexed in the tutorials hub.