Troubleshooting and Support

This is the message people see most often. Prime95 checks the rounding error of each calculation against a threshold, and a worker stops when a result drifts past it. Forum examples show values from just over 0.4 to 0.5 and even far larger numbers. A bigger value usually means a more serious error.

Common causes

• An overclock that’s unstable. The classic cause, and the first suspect in nearly every thread.
• Too little core voltage, sometimes even at stock settings.
• Memory settings, such as an XMP, DOCP or EXPO profile the system can’t hold, or timings that are too tight.
• Heat, in the CPU or the memory.
• A weak or struggling power supply (less common than the others).
• A faulty CPU core, when it repeats at stock settings with good temperatures.

How to fix it

1. Return to stock. Load the BIOS defaults, so clocks, voltages and memory profile are reset. Note your settings first if you want to restore them later.
2. Check temperatures during the run. Clean dust, check the cooler mount and fix airflow before touching voltage.
3. Test memory separately with MemTest86, as the advice in nearly every thread says.
4. If you’re overclocking, change one thing in small steps. One guide suggests raising voltage about 10 mV at a time and retesting. Another option is to lower the clock speed slightly. Don’t raise voltage in large jumps.
5. Loosen memory. Disable the XMP, DOCP or EXPO profile, or loosen timings, and retest.
6. Update the BIOS. In one forum case, an old BIOS was behind instability that stock settings couldn’t fix.

For a deeper look at causes, see Prime95 errors explained.

This message appears when Prime95 has decided a worker’s results are wrong and stopped it. It’s the same root issue as the rounding error, and the two often appear together in results.txt. The stress.txt file that comes with the program is the document it refers to, and it covers background, what to do if a problem is found, and whether you can ignore it.

What stress.txt recommends

• If you’re not overclocking: check the CPU temperature with a motherboard monitor, and make sure the heatsink is properly attached, the fans work and the case airflow is good.
• For memory problems: try swapping memory modules with another machine to isolate the fault.
• For power problems: a power supply issue can often be spotted as a significant drop in voltages when Prime95 starts running.
• If you’re overclocking: increase core voltage, lower the CPU speed, lower the front-side bus speed, or change memory timings.

One more detail: the notes say that the faster Prime95 finds a hardware error, the more likely it is that other programs will fail on that machine too. So don’t treat a quick failure as a quirk of an extreme test.

These are older, internal-style messages that you’ll see in results.txt. The readme that ships with Prime95 lists SUMINP != SUMOUT and ROUND OFF > 0.40 as the common errors, and says they’re caused either by imperfect error checking or by a real hardware fault.

What the readme says happens next

• When Prime95 logs “Possible hardware failure, consult the readme file” during normal work, it waits 5 minutes and then continues from the last save file.
• If you see “Disregard last error” after it resumes, the earlier result may have been a false positive.
• For repeated errors, the readme recommends running a torture test to find out whether the machine is stable.

Release notes add that since version 23.6 the torture test stops after 100 ILLEGAL SUMOUT errors, and since 26.2 the progress updates include a running error count once a possible hardware error occurs. If you see these in the torture test, treat them the same as a rounding error: go back to stock settings and work through the flow at the bottom of this page.

Forum posts show this summary line in the output, for example “Torture Test ran 0 minutes – 1 errors, 0 warnings”. The number before “errors” counts failed checks. A line with 0 errors and 0 warnings means no mismatches were recorded during that run.

We couldn’t find the developer define the “warnings” counter in the documentation we read, so treat any non-zero warnings as a reason to look closer rather than as a verdict. A clean summary also isn’t a guarantee of lifelong stability. One forum answer repeats the program’s own caveat that it has been known to fail only after hours or longer.

What a good results.txt looks like

Forum logs show repeated lines such as “Self-test 1344K passed!”. Each line is one completed self-test with no failure. The number is the FFT size, so you’ll see it change as Prime95 cycles through sizes. A later run in the same file can still contain a fatal error, so read the whole log and not just the top.

Many forum threads describe the same pattern: workers on some cores fail every time, and the rest run clean. A Ryzen 7 3700X owner on Level1Techs saw Workers #3 and #4 fail every run, with the error “Rounding was 0.499909461, expected less than 0.4”, while MemTest86 passed four full passes. Replies suggested testing with fewer memory sticks, checking voltage and throttling, and trying a fixed core voltage.

What resolved it in that thread

• An old BIOS was causing some of the instability, and stock settings were no longer stable even after the update.
• Manual settings held for a while, but the poster suspected a failing CPU and was advised to request a replacement.
• The CPU still failed in a different system, which pointed to the CPU rather than the board or RAM. The replacement worked correctly.

What to try, in order

1. Reset to stock settings and update the BIOS.
2. Test memory with one or two sticks and with the XMP or EXPO profile off.
3. Check temperatures per core in a monitoring tool for a hot spot or bad contact.
4. On Ryzen, if you’ve set Curve Optimizer or PBO offsets, make the weakest core’s offset less negative. See testing Curve Optimizer.
5. If it fails at stock settings with good temperatures, in another system as well, it’s likely a CPU fault. See When it’s the hardware.

A caveat: the sources we found don’t give a reliable way to map a Prime95 worker number to a specific physical core, so don’t assume worker 3 means core 3. Pinning a single worker to each core, as per-core testing tools do, is the dependable way to find a weak one.

The two modes load different parts of the system, so the pattern is a clue. Small FFTs stay in the CPU cache and barely touch memory, while Blend uses most of your RAM. For the full explanation, read Small FFTs vs Large FFTs vs Blend.

Forum users report both directions. One AnandTech poster reported a system that passed Small FFTs and then blue-screened with a 0x124 stop code within two minutes of Blend. That’s one reason to run at least two modes before calling a system stable.

When the whole PC restarts or shows a blue screen, the failure was bad enough to take down Windows, not just a Prime95 worker. A forum analysis of a WHEA crash described it as likely caused by a hardware problem, and said the problem might be thermal. WHEA is Windows’ hardware error reporting layer, so a stop code such as WHEA_UNCORRECTABLE_ERROR points at the CPU, memory or power delivery rather than at software.

One Level1Techs example: a blue screen after about 41 minutes of Prime95 on a 5 GHz overclock, with the CPU at around 94°C for the run, led the poster to conclude the overclock wasn’t stable. Another user in the same thread argued that a reboot that happens right away argues against a thermal cause. That disagreement is a good reminder that temperature alone doesn’t settle it.

What to do

1. Write down the stop code from the blue screen, such as WHEA_UNCORRECTABLE_ERROR, or the code and event shown in Windows’ Reliability Monitor and Event Viewer.
2. Remove any overclock and memory profile, then retest at stock settings.
3. Watch temperatures and voltages during the run. Safe Prime95 temperatures explains how to find your CPU’s limit.
4. Run MemTest86 to rule out RAM.
5. Check the power supply, especially if the crash happens right as the load begins.

We didn’t find any Prime95 setting that makes the program close silently, and no documented message for it. In nearly every report this turns out to be the system crashing mid-test, or the program being ended by something else. Work through these:

• Check Windows Event Viewer (Windows Logs, System and Application) for a critical or error entry at the time it closed. A hardware error or a kernel power event confirms a system-level failure.
• Look at results.txt in the Prime95 folder. If the last line is a completed self-test, the program was ended from outside rather than failing.
• Check your antivirus and any monitoring or overclocking tools that might close processes at a temperature limit.
• Retest at stock settings, because an unstable overclock can crash a process before Prime95 gets to report an error.

Remember that the test is deliberately loading every thread, so a PC can feel sluggish while it runs even when nothing is wrong. Some reports of “freezes” are simply slowness. One forum thread found that a very high Prime95 priority setting made the program slow to respond, so that it looked locked up. A widely shared forum note also says Test, then Stop can take a few seconds to take effect.

Fixes

• Wait a few seconds after pressing Stop before deciding it’s stuck.
• Lower the Prime95 priority if you’ve raised it. The default is the right choice for almost everyone.
• Stop other heavy programs. Running two stress tests at once splits the CPU between them, and the notes say you may need to raise Prime95’s priority in that case.
• Look at the disk light. A light that stays on points to Blend using too much memory. See the disk problem below.
• If the system hangs completely, treat it as a crash and work through the reboot checklist above.

An instant shutdown when the load jumps usually means a power or protection problem rather than a slow heat build-up. The notes that come with Prime95 say a power supply problem can often be identified by a significant drop in the voltages when Prime95 starts running. A long-running Prime95 guide adds practical detail: watch the 12 V rail when the test begins, note that specifications allow about ±5%, and avoid the extremes. It also says weak supplies rarely cause these failures, so check the power supply last, not first.

• Watch the 12 V reading in a monitoring tool at the moment you start the test.
• Check the CPU power connectors are fully seated, and reseat the RAM.
• Make sure the cooler pump or fan is running. A cooler that isn’t making contact can trigger a protective shutdown within seconds.
• If you can, try a different power supply to rule it in or out.

Often, yes, with caveats. Intel defines Tjunction max as the maximum junction temperature a processor will allow before it uses internal thermal controls, says it varies per product and is usually between 100°C and 110°C, and says that when the controls activate, the processor typically reduces frequency and power. If throttling isn’t enough, Intel says the processor shuts down to prevent permanent damage. Look up your CPU’s value on its specification page.

On Ryzen, forum reports are consistent that high readings are common under Prime95. An AMD Community user saw about 92°C within seconds on a Ryzen 9 5900X running Small FFTs, while Cinebench stayed under 65°C. In another AMD thread about a Ryzen 5 3600, a reply said the chip was hitting its power and current limits, so the all-core test was running as expected. A third poster on a stock cooler said Prime95 is designed to keep heat rising, and that dropping the fan curve to follow CPU temperature kept the peak lower. All of these are individual reports, not AMD documentation.

What to do

1. Find your CPU’s maximum temperature and compare.
2. If you’re at the limit and throttling continuously, improve cooling. Clean dust, check the cooler mount, and raise the fan curve.
3. For a more realistic load, switch AVX off. See AVX settings.
4. If you’re far below the limit but temperatures still seem high, compare against published figures for your CPU and cooler.

The long-running PlayTool guide reports a 5°C drop for its author after cleaning a dusty heatsink and fan, which is a reminder that dust is the cheapest thing to fix.

A dropping clock is a CPU protecting itself or sticking to a limit. It can happen for three reasons: temperature, a power limit, or a current limit. Intel’s article confirms that activating thermal controls may cost performance because the processor reduces frequency and power.

A forum poster with a Ryzen 3950X described clocks varying between about 3.3 and 4.2 GHz during an all-core load, with temperatures mostly around 70°C and occasional peaks near 90°C, and attributed the variation to the changing Prime95 workload together with package power, thermal and current limits. AVX adds another reason: heavy AVX loads draw more power, so many CPUs reduce clocks to stay inside power limits.

The clock drop alone isn’t a failure. It’s a limit being hit, so judge it alongside temperature, power and errors.

A stress test only counts if it’s at full strength. A long-running Prime95 guide says to check Task Manager and aim for every CPU at 100%, and that anything lower means the test isn’t at full strength. Open Task Manager, choose Performance, then CPU, and watch utilisation while the test runs with all threads selected.

Why it might be lower

• Other programs. Close them. The guide notes other programs lower CPU load, and disk access lowers it further.
• Fewer workers than threads. In the torture test window, check the number of threads to stress test. The default loads every logical processor.
• Power plan or core parking. A Microsoft Q&A suggestion for a similar symptom was to set core parking to full performance, but that’s a user suggestion, not an official fix. Make sure the Windows power plan isn’t a power-saver mode.
• Hyper-Threading on older Prime95. An old AnandTech report said an old version loaded one logical CPU per core with Hyper-Threading enabled, giving about 50% usage, and that the poster fixed it by running a second instance with a switch. That’s a decade-old report about an old build, so it likely doesn’t apply to current versions, but it shows that thread count matters.
• Hybrid CPUs. A forum explanation about an analysis program said that when E-cores are excluded by affinity, total CPU usage is limited because only the P-cores can be used. Task Manager’s percentage covers all logical processors, so a load on some cores never shows 100%. Measure the work done and the per-core view, not just the total.

Blend automatically picks a “Memory to use” value that uses up most of the RAM in the computer. If that’s more than can fit, Windows starts paging to disk, and the test ends up accessing the hard drive a lot. The guide’s test for it is simple: when Blend runs properly, the hard disk is accessed only occasionally, so a light that stays on most of the time means it’s using more memory than the PC has.

The fix

1. Stop the test.
2. Open Options, Torture Test and choose Custom.
3. Reduce the Memory to use value until the disk activity stops.
4. Close other programs that use a lot of RAM, then restart the test.

Forum reports add a caution: because Blend uses so much memory, a paging-induced slowdown can be mistaken for a hardware fault, so lower the memory setting before drawing conclusions about a failure.

• “Not a valid Win32 application”: a 64-bit build on 32-bit Windows, or an incomplete extraction. Check your Windows type (Settings, System, About) and extract again.
• SmartScreen warning: normal for a small utility. Choose More info then Run anyway if the file’s name and size match what you downloaded.
• Antivirus blocks it: security software sometimes flags stress tools because they max out the CPU. Check the file, then add a folder exclusion if you’re sure.
• It starts and closes at once: try a fresh extraction into a new folder such as C:\Tools\Prime95, not Program Files, because Prime95 writes settings and logs next to the program.
• Can’t stop or delete it: end the process in Task Manager, then delete the folder. If Task Manager doesn’t list it, restart Windows.

Need the files again? See the download page.

“Join GIMPS” sets up an account and begins real prime-search work in the background. If you only wanted a stress test, close Prime95 and delete its folder, then extract a fresh copy and choose Just Stress Testing. The settings and work files all live in that one folder, so deleting it removes them.

If you keep it and run into connection errors, the readme says to choose the Connection button in the Test, PrimeNet dialog if you need to set a proxy. The simplest fix for a stress-testing user, though, is to avoid joining in the first place.

We couldn’t find a built-in total run timer in the documentation or forum posts we read. One forum answer to someone who wanted a 12-hour run was simply that the test keeps running until you stop it. The “Time to run each FFT size” setting controls how long each size runs before moving on, not the total time.

• Stop it manually with Test, Stop.
• Use a scheduled task or script that ends the process after the time you want. Another tool that launches Prime95, as some monitoring and wrapper tools do, can also stop it after a set time.
• Start it directly: the readme says a -t switch runs the torture test, the same as Options, Torture Test.

For how long people run it, see how long to run Prime95. The notes that ship with the program recommend running it for somewhere between 6 and 24 hours for a thorough test, and a day for an overclocked machine.

Prime95 keeps its files beside the program unless told otherwise. The readme describes them like this:

• To reset: close Prime95 and delete prime.txt and local.txt (or the whole folder). It rebuilds them on the next start.
• To keep files elsewhere: the readme describes a -W switch followed by a directory, so Prime95 finds its files in a different directory than the executable.
• Several copies side by side: the readme marks the old -An switch as obsolete. The simple way today is to extract the program into separate folders.
• Changing instruction sets: edit local.txt. See AVX settings. It only exists after you’ve run the program once and closed it.

On Linux and macOS, Prime95 is a command-line program called mprime. We didn’t find a thread documenting an mprime-specific AVX-512 fault, but similar reports for other software show a consistent pattern: an “illegal instruction” usually means the program tried an instruction the CPU, or a virtual machine, doesn’t expose. A related Intel community thread reports a segmentation fault on a Core i9-14900K when AVX2 was enabled. It’s anecdotal and not a confirmed fix.

What to try

1. Use the right build. Download the 64-bit archive for a 64-bit system.
2. Check the CPU really exposes AVX2 or AVX-512. Inside virtual machines, flags are often hidden. Compare lscpu flags with what the program uses.
3. Disable an instruction set in local.txt, as described in the AVX settings guide, and retest.
4. Run from a terminal in the extracted folder: ./mprime, or ./mprime -t to start the torture test directly. Choose stress testing when it asks about joining the prime search.
5. Test outside a VM if you can, since virtualisation changes which instructions are available.

Prime95 only tests the CPU, cache and memory in one specific way. A game crash can come from the graphics card, drivers, storage, memory that only fails under a different pattern, or the software itself. One forum commenter made the point well: you can fail Prime95 yet never hit an issue in day-to-day use, and you can pass it and still fail doing something else.

What to test next

• Memory: run MemTest86, and a second stress tool. See Prime95 vs OCCT vs AIDA64 vs Cinebench.
• Graphics: try the online GPU stress test for a quick check, and a dedicated GPU test.
• Power: a heavy CPU and GPU load together can strain a power supply that passes each alone.
• Drivers and Windows: update graphics and chipset drivers, and check Windows Event Viewer for errors around the crash.
• The exact workload: if your problem is in one program, test with that program under load.

The opposite case (Prime95 fails but everything seems fine): the notes that come with Prime95 describe two opposing views on ignoring instability, and also say that the faster Prime95 finds a hardware error, the more likely other programs will fail. A safe default is not to ignore it, especially for a machine that holds important work.