Short answer: Prime95 is a well-known, legitimate stress-testing program, and running it is a normal part of building and overclocking PCs. It is not, however, a program anyone can honestly promise is risk-free in all circumstances, and this page will not pretend otherwise. The software is provided as-is, without warranty, under its freeware license. Its own stress.txt guide treats the risks plainly: the Torture Test applies maximum sustained load, so cooling and power delivery have to be up to the job, temperatures have to be watched, and continuing to use a machine that reports errors is a personal decision with real downsides. Safe use is a set of habits – monitor, start short, keep cooling in order – not a promised number of hours. Quick answers to related questions are in the Prime95 FAQ.

The official position, in the program’s own documents

Three documented facts frame the whole question. First, the license: Prime95 is freeware provided as-is, with no warranty, which is the developer’s way of saying the responsibility for how and where you run it is yours. Second, the design: the Torture Test continuously compares calculations against known correct results, and presets such as Small FFTs are defined by the program itself as producing maximum power, heat and CPU stress. Maximum is not marketing language; it is the menu description, and it means this workload will find the ceiling of your cooling faster than almost any everyday program. Third, the error philosophy in stress.txt: failures under this test should be taken as information about the hardware, and the guide is explicit that ignoring errors and carrying on regardless is the user’s own choice and risk. None of that makes Prime95 dangerous software. It makes it an honest tool that refuses to flatter marginal hardware.

The real risks, stated without drama

There is no safe-duration promise, and that is normal

Search results sometimes imply a number of hours beyond which Prime95 becomes dangerous, or a number of hours that certifies a system as completely stable. Neither number exists in the official documentation. What stress.txt actually recommends is a duration for confidence: 6 to 24 hours for a thorough stability check, because errors have surfaced after hours and occasionally much longer, while clearly unstable systems usually fail within minutes. When overclocking, it suggests short 10 to 15 minute runs to survey each frequency step before committing to a long final test. Our guide to how long to run Prime95 explains this guidance in full. Duration answers the question of how thoroughly you have tested; it is not a safety timer in either direction.

Temperature: monitor against your model’s specification

Prime95’s documentation sets no universal safe temperature, so be wary of any single number presented as one. Your ceiling is the maximum temperature published by Intel or AMD for your exact processor model, commonly listed as TjMax or a maximum operating temperature. Small FFTs will approach that ceiling more closely than any other preset, by design. If your system reaches its limit quickly at stock settings, that is a cooling finding to fix, and our guide to Prime95 reaching 100°C works through the mounting, paste, airflow and AVX checks in order. Note also the one specific, dated caution in stress.txt: written in a 2019 context, it observes that first-generation Ryzen processors could become heat-unstable above 70°C. That is a generation-specific note from that document, not a general rule for modern processors.

Your monitoring partner: HWiNFO

Safe stress testing is mostly watching. Run HWiNFO alongside Prime95 from the beginning: it is a free monitoring program from hwinfo.com, recommended here purely as a companion tool with no partnership involved. Its Sensors view shows temperatures, clock speeds, power and throttling indicators while the test runs, which turns vague worry into specific facts: temperature settling at a steady level below your model’s limit, with clocks holding steady, is what a healthy run looks like. Temperature that climbs without settling, or clocks that fall as the limit is reached, tells you to stop and fix cooling before any long run. Keep the same monitoring habit for every test in the troubleshooting hub, so results from different days and settings stay comparable.

Frequently asked questions

Can Prime95 damage my hardware?

Prime95 is a legitimate stress test, not malware, but any sustained maximum load exposes weak cooling, marginal power delivery and unstable settings, and the results of ignoring those warnings are the user’s responsibility. The program’s license provides the software as-is, without warranty. Run it with temperature monitoring in place, start with short tests, and stop if temperatures reach the limit for your processor model. A healthy system at stock settings with working cooling is expected to run it without harm; a system with a cooling fault is expected to reveal that fault, which is the point of the test.

How long is it safe to run Prime95?

There is no official safe duration, and any site that promises one is inventing it. The official stress.txt guide recommends 6 to 24 hours for a thorough stability check, because errors have appeared after hours or even weeks, while clearly unstable machines often fail within minutes. When overclocking, the same guide suggests short 10 to 15 minute runs to explore each setting before a long final test. Duration is about how much confidence you need, supervised by temperature monitoring, not about a hidden time limit after which damage begins.

What temperature is safe during Prime95?

Prime95’s documentation gives no universal safe temperature. Check the specification for your exact processor model from Intel or AMD, where a maximum temperature such as TjMax is published per model, and treat that as your ceiling. Small FFTs is the maximum power and heat preset by design, so expect the highest readings there, watch them with a monitoring tool such as HWiNFO, and stop the test if the limit for your model is reached.

How do I run Prime95 more safely?

Use stock settings for your first runs, monitor temperatures, clocks and throttling with a tool such as HWiNFO from the start rather than after problems appear, begin with short runs before attempting an overnight test, make sure cooling and case airflow are working before blaming the software, and never leave a first-ever run of a newly built or newly overclocked system completely unattended. Those habits, not a promised number of hours, are what safe stress testing actually consists of.

Short answer: Prime95 can stress memory hard, but it is not a dedicated memory tester, and treating it as one leads to missed diagnoses. Large FFTs use data sets too large for the CPU caches, so they stress the memory controller and RAM. Blend, the default preset, mixes everything, and the Torture Test menu carries an official hint: if Blend fails but Small FFTs passes, the problem is often in memory or the memory controller. What Prime95 cannot do is test every memory address methodically from outside the operating system, which is the job a dedicated bootable tool such as MemTest86 exists for. Use Prime95 to find memory instability under realistic combined load, and the dedicated tool to isolate faulty memory itself. The full preset comparison is in Small vs Large vs Blend FFTs.

What each preset tells you about memory

Since version 29.8, the Torture Test chooses its FFT ranges from your CPU’s cache size rather than from a fixed table, and on systems with more than 5 GB of memory Blend defaults to using all memory minus 3 GB. That means the same preset name adapts to your hardware; do not compare your run against old forum posts that quote fixed FFT ranges from much older versions as if they were specifications for the current release.

A sensible Prime95 memory workflow

1. Start at base memory settings. Disable the memory overclock profile (XMP, EXPO or manual timings) and run Large FFTs. A clean run at base speed followed by failures at profile speed is a clear, actionable result: the profile settings are not stable on your system as configured.
2. Run Small FFTs as the control. If Small FFTs also fails, the problem is not memory alone, and you should work through the general decision tree in the troubleshooting hub before drawing memory conclusions.
3. Run Blend for combined load. Blend stresses CPU, caches and memory together, closer to a worst-case real workload. Instability that only appears under combined load is still real instability, even if each subsystem passes alone.
4. Record the pattern. Note the preset, the elapsed time and whether one worker or several workers reported errors. Memory faults often produce errors across different workers, since all of them share the same RAM, unlike a single weak core.

Where Prime95 stops and MemTest86 starts

Prime95 runs inside your operating system, which means part of your memory is occupied by the system itself and cannot be tested, and a memory fault can crash or corrupt the very environment doing the testing. A dedicated bootable tester runs instead of Windows or Linux, can address the memory far more completely, and tests it with patterns designed purely for finding faulty cells and marginal sticks. The division of labour is therefore straightforward: Prime95 answers the question of whether your whole system, memory included, stays correct under heavy combined load; MemTest86 answers whether the memory itself is sound, stick by stick if needed. Our head-to-head, Prime95 vs MemTest86, explains when each tool should lead. If Prime95 points at memory, confirm with the dedicated test before buying replacement RAM; if the dedicated test passes every stick but Blend still fails at profile settings, the memory controller settings or the profile itself remain the likely problem, and base settings are your stable fallback.

Testing individual sticks and slots

When the dedicated test or the Prime95 pattern points at memory, the oldest isolation method is still the most decisive: test one stick at a time, in the slot your motherboard manual designates for single-stick use. A fault that follows one stick wherever it is installed identifies that stick. A fault that stays with one slot regardless of which stick occupies it points instead at the slot, the board or the memory controller. Change only the stick or only the slot between runs, and write down which combination produced which result, because with two sticks and several slots the combinations multiply quickly and memory of what you tested is unreliable after a long evening of runs. This physical isolation is something no in-Windows test, Prime95 included, can do for you, and it is the step that turns a suspicion into a part you can confidently replace or return.

Limits to state honestly

No pass, in Prime95 or anywhere else, proves memory perfect for all time; marginal faults can depend on temperature, load pattern and time. The official stress.txt guidance for the Torture Test overall is 6 to 24 hours for a thorough check, and that patience applies to memory suspicion too, since memory errors can be rare events per hour of testing. Equally, do not use Prime95 alone to condemn a memory kit for a warranty claim when a dedicated test from outside the operating system is the evidence the situation calls for. Used in the right order, the two tools complement each other: Prime95 finds the instability in context, and the dedicated tester isolates it.

Short answer: A Prime95 error is evidence, not a verdict. One worker reporting one error tells you that, at those settings and that moment, one calculation came back wrong. It does not, by itself, prove the whole machine is unusable, and a machine with no errors in a short run is not thereby proven stable either. The useful distinctions are pattern and repeatability: a single isolated error, occasional errors under specific settings, and errors that recur quickly at stock settings are three different situations with three different responses. This guide draws that line using the program’s own documentation and, separately and clearly labelled, the common community position. Start from the troubleshooting hub for the individual error guides.

What a single error actually establishes

The Torture Test checks its arithmetic against known correct results, so an error establishes one narrow fact with unusual certainty: the hardware produced a wrong answer under that load, at those settings. Everyday software rarely proves anything comparable, because it does not check itself. That is why dismissing the error as meaningless is a mistake, and why overreacting to it is also a mistake. At overclocked or undervolted settings, a single error most often means the settings are slightly beyond what the hardware can do reliably – a tuning problem, fixable by backing off. At fully stock settings with controlled temperatures, the same single error deserves more attention, because the hardware is expected to be correct at its rated settings. Either way, the next step is identical: note the worker, preset, elapsed time and settings, then reproduce or refute the result with a longer run. The mechanics of the commonest error are covered in FATAL ERROR: Rounding explained.

Three patterns, three meanings

The community position, and the official position, kept separate

A widespread community position in overclocking forums runs roughly as follows: if a machine never crashes in the owner’s actual games and applications, it is stable enough, and a Prime95 error in a workload far heavier than daily use can be accepted. That is a statement about personal risk tolerance, and for a gaming machine whose worst failure mode is a crash, some owners knowingly accept it. The official position in Prime95’s own stress.txt is different in emphasis. It recommends running the Torture Test for 6 to 24 hours for a thorough check, notes that errors have appeared after hours or even weeks of testing as well as within minutes on clearly unstable machines, and warns in substance that continuing to use a machine that produces errors is a personal decision with a real downside: a system that calculates wrong can silently corrupt data, not merely crash visibly. Where the machine handles important files, work output, finances or long computations, the official caution deserves the greater weight. Where it is a games-only machine, an informed owner may accept the community trade-off – but informed means knowing an error occurred, not never testing. Our guide to how long to run Prime95 sets out the duration guidance in full.

Why short clean runs prove less than people think

Errors are events with a rate, not a switch that is either on or off. A marginal system might produce a wrong result once in several hours of maximum load, which means a thirty minute clean run is entirely compatible with the system still being marginal; you simply did not sample long enough to catch the next event. This is the statistical reason behind the official 6 to 24 hour recommendation, and behind the observation in stress.txt that some errors only appeared after very long testing. Judge a clean run by its length and its conditions: a full-length run, at the final settings, at full operating temperature, with the same preset that originally failed, is meaningful evidence. Anything shorter or lighter is a progress check, not a clearance, and presenting it to yourself as a clearance is how marginal machines end up corrupting something important months later.

How to judge your own result

Ask four questions. Did it happen at stock or tuned settings? Stock errors weigh far more heavily. How quickly and how repeatably does it happen? Minutes and every time is systemic; once after many hours is marginal. Does it track heat or a particular preset? A pattern that follows Small FFTs, Large FFTs or Blend tells you which subsystem to work on. And what does this machine do for you? The same marginal result that is acceptable on a disposable gaming setup is not acceptable on the only copy of your work or family archive. If the honest answers leave you uneasy, the deciding experiment is always available: a long run at stock settings, as described in Is Prime95 safe to run? A clean long run at stock closes the hardware question and leaves only your tuning to manage; errors at stock open the full diagnostic path in the troubleshooting hub.

Short answer: An AVX offset is a BIOS or firmware setting, found mainly on Intel platforms, that automatically lowers the CPU clock multiplier by a set amount whenever the processor detects AVX workloads. It exists because AVX instructions draw more power and generate more heat per clock cycle than ordinary code. Prime95 triggers the offset reliably because current versions use AVX, AVX2 and, where supported, AVX-512 code paths in their FFT calculations – exactly the kind of sustained AVX load the offset was designed for. An offset is not the same as disabling AVX inside Prime95: the offset keeps AVX running at a lower clock, while the in-program settings stop Prime95 from using AVX paths at all. Platform background is collected in our platforms hub.

Why AVX loads get their own clock speed

AVX instructions process wide blocks of data in a single operation, which is why Prime95’s FFT code became much faster when AVX support was added in the 27.x versions, followed by FMA support and later AVX-512 FFT support. The trade-off is electrical: moving and processing that much data per cycle draws more current and produces more heat than the same clock speed running non-AVX code. A processor overclock that is perfectly stable for gaming or rendering can therefore be unstable, or simply too hot, the moment a sustained AVX workload arrives. Motherboard makers added the AVX offset as the compromise: keep the high multiplier for ordinary work, and automatically step down by a few multiplier steps when AVX instructions are detected, trading a little AVX performance for stability and manageable temperatures.

Why Prime95 is the classic trigger

Many programs use AVX only in bursts, so the offset engages briefly and invisibly. Prime95’s Torture Test is different: on a supported processor it runs AVX-heavy FFT calculations on every worker, continuously, for as long as the test runs. That has two practical consequences. First, the clock speed you see during Prime95 is the offset clock, not your headline overclock, which surprises users who expected the higher number. Second, Prime95 is the standard way people discover whether their offset is large enough: if the system is stable at the non-AVX clock but produces errors at the AVX clock, the offset, the voltage, or both need attention. Observing the actual clock during a test, in a monitoring tool, is how you confirm the offset is engaging as intended.

Setting an offset: principles, not numbers

The setting is usually found in the BIOS or firmware overclocking section, near the CPU multiplier controls, under a name resembling AVX Offset or AVX Negative Offset; the exact name and menu location vary by board maker and model, so consult your motherboard manual rather than a guide written for a different board. In general terms, the value states how many multiplier steps to subtract when AVX is detected. The working method is iterative: start from stable settings, apply or increase the offset in small steps, and run Prime95 after each change, noting the AVX clock, temperatures and whether errors appear. A larger offset lowers AVX clocks and heat further but gives up more AVX performance; a smaller offset keeps performance but demands more from voltage and cooling. There is no universally correct value, because it depends on your processor sample, cooling and voltage settings, and this site will not publish per-model numbers it cannot verify for your hardware. Change one variable at a time, and treat stability at stock settings as the baseline every tuned result is compared against.

How to tell whether your offset is doing enough

Run Prime95 with a monitoring tool open and record three observations: the clock speed the processor settles at under the Torture Test, the temperature it settles at, and whether any worker reports an error. If clocks settle at the expected offset level, temperatures settle below your model’s published limit, and a long run completes without errors, the offset is doing its job for that workload. If errors appear at the offset clock, the problem is no longer the headline overclock: the offset clock itself, its voltage, or the cooling behind it needs work, and the correct response is a larger offset, a conservative voltage adjustment within documented limits, or better cooling, changed one at a time. If temperatures settle but remain at the model’s limit with throttling, the offset has traded an error problem for a cooling problem, and the cooling path in our overheating guide is the next step.

Which approach should you use?

If your goal is a system that is stable for real AVX workloads – rendering, encoding, scientific software and modern games can all use AVX – the offset is the more honest tool, because the workload still runs, just at a clock the system can sustain. Use the in-program option, described in how to disable AVX in Prime95, when your goal is narrower: for example, reproducing the lighter heat profile associated with the old 26.6 version, or isolating whether AVX specifically is the source of heat or errors on a test system. Be clear with yourself about which question each run answers, and do not present a pass with AVX disabled as proof that an AVX overclock is stable. For generation-specific context on recent Intel processors, see our upcoming guide to Prime95 on Intel 13th and 14th gen, and return to the troubleshooting hub if the offset work uncovers errors you need to diagnose.

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.

The verification order after a worker stops

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.

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

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.

Short answer: A temperature near 100°C in Prime95 does not automatically mean your cooler has failed, and it does not automatically mean everything is fine. Small FFTs is defined in the program’s own Torture Test menu as the preset for maximum power, heat and CPU stress, so the highest temperatures your cooling will ever see are expected in exactly this test. At the same time, a weak cooler mounting, dried thermal paste, poor case airflow or a failing fan or pump will show up here first. The job is to separate those two explanations in order, without guessing. If you are new to this cluster, the troubleshooting hub gives the overview.

Step zero: know your processor’s actual limit

Prime95’s documentation gives no universal safe temperature, and this site will not invent one. The number that matters is the specification for your exact CPU model, published by Intel or AMD in its product database, often labelled as a maximum junction temperature (TjMax) or maximum operating temperature. Look up your specific model there before you run a long test, because limits differ between models and generations. As one narrow, dated example of why model matters: stress.txt, written in a 2019 context, notes that first-generation Ryzen processors could show heat-related instability above 70°C. That note applies to that generation in that document; it is not a general limit for modern processors. For the reasoning behind temperature limits in full, read Prime95 temperatures explained when it lands in our cooling cluster.

The troubleshooting ladder, in order

1. Stop the test and let the system cool. If the temperature reaches your model’s limit or climbs without levelling off, stop. Note the preset, the time taken to reach the peak, and whether the temperature jumped instantly or crept up over minutes. An instant jump suggests the heat is not leaving the chip efficiently; a slow climb suggests the case or cooler is gradually saturating.
2. Check the cooler mounting and thermal paste. With the system off and unplugged, confirm the cooler is evenly and firmly mounted, that any protective film was removed from the contact plate at installation, and that fans or the pump are actually running and connected to the right headers. Old, dried or poorly spread thermal paste is a common, cheap cause. Clean and reapply paste according to its maker’s instructions if you reseat the cooler.
3. Check case airflow. Confirm intake and exhaust fans spin in the intended directions, filters and vents are clear of dust, and cables are not blocking the path to the cooler. A cooler can only reject heat into the air inside the case; if that air is already hot and stagnant, even a good cooler will struggle during a maximum-heat preset.
4. Retest with AVX disabled to separate variables. Prime95 can be told not to use AVX code paths by adding settings such as CpuSupportsAVX=0 to prime.txt, as our guide to disabling AVX in Prime95 explains step by step. If temperatures fall sharply with AVX off while the cooler mounting and airflow check out, you have learned that the AVX workload’s power draw is the main driver on your system, not necessarily a broken cooler. Remember that this changes what the test covers.
5. Only then consider upgraded cooling. If the mounting, paste and airflow are correct and the processor still reaches its limit quickly in Small FFTs at stock settings, the cooler itself may simply be undersized for a sustained maximum-power workload on your processor.

Watching temperature and throttling with HWiNFO

Run a sensor monitor alongside Prime95 so you can see more than a single temperature number. HWiNFO is a free monitoring program available from hwinfo.com; we recommend it purely as a monitoring companion and have no partnership or commercial relationship with it. Open its Sensors window before starting the test, and watch the per-core or package temperature, the current clock speeds, and any thermal throttling indicators it reports for your processor. The pattern tells the story: clocks falling while the temperature sits at the limit means the processor is protecting itself by slowing down, which confirms a cooling ceiling rather than a measurement quirk. Record the values at one minute, five minutes and fifteen minutes so you can compare runs after each fix. For the wider safety picture, see Is Prime95 safe to run?

If you do upgrade cooling: parts that fit this job

The products below are the cooling parts this site’s guides are built around for sustained stress-test loads. Full selection reasoning is in best CPU coolers for stress testing. Disclosure: the four product links in this section are affiliate links; if you buy through them we may earn a commission at no extra cost to you. Please read our affiliate disclosure for how these links work.

Frequently asked questions

Why does Prime95 make my CPU reach 100 degrees Celsius?

Small FFTs is defined by the program itself as the maximum power, heat and CPU stress preset, with its data held in the CPU caches. A very high temperature under Small FFTs is therefore partly the design of that test: it is meant to show the highest heat your cooling will face. It can also expose a real cooling problem, such as a poorly seated cooler, old thermal paste, blocked airflow or a fan or pump failure. The test result alone does not tell you which of those applies; work through the cooling checks before deciding anything is broken.

Should I stop Prime95 if the temperature reaches 100 degrees Celsius?

If the temperature reaches the limit shown for your processor or keeps climbing with no sign of levelling off, stop the test. There is no reason to let a diagnostic run continue at a temperature you are not comfortable with. Note the preset and how quickly the temperature rose, let the system cool, then check the cooler mounting, thermal paste and case airflow before testing again with a lighter preset.

Is there a single safe temperature for Prime95?

No. Prime95’s own documentation gives no universal safe temperature number. The limit that matters is the specification for your exact processor model, published by Intel or AMD, often listed as a maximum operating or junction temperature such as TjMax. Check that specification for your model rather than relying on a generic number from a forum.

Does disabling AVX help with Prime95 temperatures?

It can. Current versions of Prime95 can use AVX, AVX2 and AVX-512 code paths, which raise power draw and heat on supported processors. Prime95 documents settings in prime.txt such as CpuSupportsAVX=0 that stop the program using those paths, which produces a lighter, 26.6-style heat load. That changes what the test covers, so treat a pass with AVX disabled as a pass for that configuration, not as proof the AVX workload is stable.

Still overheating after the ladder above? Return to the troubleshooting hub and check whether your system also shows instability symptoms, since heat and instability often travel together.

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

A decision tree you can follow

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.

Short answer: When Prime95 reports FATAL ERROR: Rounding was 0.5, expected less than 0.4 (the exact numbers vary), it means the processor produced a result that does not match the known correct result for that calculation. The Torture Test works by comparing every computation against a known correct answer, so a rounding error is the test doing its job: it found that your hardware calculated wrong under load. In almost all cases this points to instability – an overclock that is not fully stable, memory that is not fully stable, insufficient voltage for the chosen settings, or heat – rather than a fault in the program itself. Start from the troubleshooting hub if you are seeing several different symptoms at once.

What the numbers in the message actually mean

Prime95 knows what the correct result of each FFT calculation should be, within a small expected margin of rounding error. Normal floating point arithmetic is not infinitely precise, so a tiny rounding difference is expected and allowed. The error appears when the observed rounding is larger than the allowed margin: in plain terms, the answer came back too far from correct to be explained by normal rounding. That is why the message prints two numbers, what was observed and what was expected as the limit. A single wrong bit in a long calculation is enough to push the result outside that margin. The worker that hit the error stops, writes the failure to results.txt, and the other workers may keep running, which is why you should read the full log rather than only the last line on screen. Our guide to reading Prime95 results explains how results.txt is structured.

Common causes, in the order to suspect them

Use the worker number to locate the problem

Each worker in Prime95 tests an assigned slice of work, and on a modern processor each worker is associated with particular threads. When only one worker reports the rounding error and stops while the others continue, that pattern matters: it suggests the instability is tied to a particular core or thread path, a per-core overclock setting, or the voltage delivered under that specific load, rather than a total system failure. Write down which worker failed, how long it ran before failing, and which FFT size was running at the time. If the same worker fails early and repeatedly at stock settings, that is stronger evidence than a single late failure. Our guide to a worker that stopped in Prime95 covers this isolation process in more depth.

Step-by-step troubleshooting order

1. Save the evidence first. Copy the error line, the worker number, the preset (Small FFTs, Large FFTs or Blend) and the elapsed time from results.txt before you change anything.
2. Return the whole system to default settings. Load optimised defaults in the BIOS or firmware, remove CPU and memory overclocks, and run the same preset again. If the error disappears at stock settings, the hardware is most likely fine at stock and your previous settings were not fully stable.
3. Isolate CPU from memory with the presets. Small FFTs keep data in the CPU caches and put maximum power, heat and CPU stress on the processor, by the program’s own definition. Large FFTs stress the memory controller and RAM. Blend tests everything. The Torture Test menu itself notes that if Blend fails but Small FFTs passes, the problem is often in memory or the memory controller. Test one preset at a time so the result tells you which subsystem to investigate.
4. Check temperature while the test runs. A monitoring tool alongside Prime95 shows whether temperatures climb steadily until the failure. If errors arrive only when hot, work through the cooling checks in our overheating guide before changing electrical settings.
5. Change one electrical setting at a time, conservatively. If you choose to re-apply an overclock, restore it in small steps, staying within the limits in your CPU and motherboard documentation, and retest after each step. Never treat a voltage copied from a forum post for a different processor as a safe value for yours.
6. Retest for a meaningful length. A five minute pass does not undo a rounding error. The official stress.txt guide recommends 6 to 24 hours for a thorough check, and notes that unstable systems often fail within minutes, while others only fail after hours.

What not to do

Do not ignore the error and keep using the same settings for important work. A machine that calculates wrong under load can corrupt files, saves and calculations silently; the error you saw is the visible version of a problem that does not always announce itself. Do not raise several voltages at once to make the error go away, because you will not know which change mattered, and excessive voltage creates its own risks. Do not assume the program is buggy: according to stress.txt, you should suspect the hardware first, and only consider a software problem if the exact same error repeats at the exact same place every time. Finally, do not declare the system fixed after one short run; instability that took an hour to appear needs a longer run to rule out.

Next steps

If the error persists at fully default settings with reasonable temperatures, work through the broader decision tree in Hardware failure detected in Prime95, and read Prime95 errors vs an unstable system to judge how serious a single error is for your use case. Both guides stay within the same rule: change one variable at a time, keep notes, and let longer tests have the final say.