Hardware · Processor
CPU problems: throttling, heat and instability — with the tests that matter
Three words cover almost every processor complaint: throttling, heat, and instability. They overlap — a cooling problem becomes a throttling problem becomes a performance problem — but they are different failure modes with different evidence and different fixes, and most misdiagnoses come from treating them as one blob called "my CPU is slow." This guide is organized around the separation: what each mode actually is, what the monitoring data looks like for each one, and the tests that can tell them apart.
The second organizing idea is that a CPU is measurable. Temperature, effective clock, package power, throttle flags, error logs — every step of the method below is a number you can record before and after a change. A CPU problem that has been measured is a CPU problem that can be diagnosed, and the gap between "it feels slow" and "the effective all-core clock fell from 4.1 to 3.4 GHz at 98°C" is the entire difference between troubleshooting and guessing.
The third: tests are instruments, not verdicts. Each major test — render loops, torture loads, memory tests, real workloads — stresses specific paths and answers specific questions, and none of them, not even the harshest, proves a whole system stable. A pass is always scoped to what it covered. The testing sections below are organized by what each test can and cannot tell you, because that is the knowledge that keeps a diagnosis honest. The 32 topics follow in seven categories, and the decision tree near the end routes a live symptom to the right ones.
The model
Three failure modes, one measurement method
Throttling is the CPU choosing a lower performance to stay inside a limit. Heat is the environment that sets where that limit sits. Instability is the CPU (or its neighbors) producing wrong results or stopping entirely. A cooling failure typically walks across all three: the temperature rises, the firmware throttles, and if the voltage or power path is also marginal, the same heat that caused the throttle can tip the system into errors. That's why the three are taught together, and it's why the method below always measures before it assigns blame.
The diagram shows the three paths a CPU problem can travel: power in from the VRM, heat out through the cooler, and telemetry back to whatever is monitoring the machine. When something goes wrong, one of those three paths is the cause — and the monitoring data is how you find out which.
Definition
What throttling actually means
Throttling is the CPU's firmware deliberately lowering performance to stay inside a limit — a thermal limit, a power limit, or a current limit. It is protection, not failure: the chip would rather run slow than run hot, draw more power than the delivery path supports, or exceed a configured budget. The diagnostic consequence is that throttling is always normal behavior responding to a constraint, and the constraint is what you're looking for. A constraint can be physical (the cooler can't move the heat, the VRM can't deliver the current) or configured (a power limit set by the OEM, a BIOS default, a power plan), and the monitoring data is what separates the two: a temperature at the limit points at the physical thermal path, while a power number pinned at a clean, round value points at a limit.
It's also worth being precise about what throttling is not. It is not a defect in the CPU, and it is not always a problem at all: a bursty workload that briefly hits a power window, or a thin laptop under a sustained load, will throttle by design. The question that turns throttling into a problem is a performance question — what is the effective clock during the load that matters to you, and is it lower than it should be for this hardware and these settings? That is the question every section of this guide ultimately answers, and the throttle reason (the flag that names which limit fired) is the fastest pointer to which section to open.
Thermal behavior
How heat changes what a CPU does
Heat is the CPU's operating environment, and its effect on behavior is stepwise rather than smooth. Well below the model's maximum, temperature costs nothing measurable — a 45°C CPU and a 65°C CPU run the same clocks at the same voltage. As a sustained load pushes the temperature toward the limit, the firmware starts trading clock for temperature, and that is throttling. At the limit, the clock drops to whatever the thermal budget allows and stays there until the heat goes down. The practical reading: temperature only matters in relation to the limit, and the limit is a per-model specification (the manufacturer's datasheet lists it; general desktop designs sit in the high 90s to around 100+°C, laptops lower). The useful comparison is "how far below the limit is my CPU under this load," not "is this number hot" — and looking up your specific model beats any generic rule written for a different part.
Two heat behaviors cause most of the confusion, and both are about the shape of the curve rather than a single reading. The first is the transient: temperature climbs over the first minutes of a load and then settles at a steady state, and the clocks do the reverse — comparing the first-minute clock to the settled clock and calling the drop a "problem" is a measurement error, not a diagnosis. The second is heat-soak, where the cooler and the surrounding air stay warm after long idle and the first load back spikes before settling — a fan-curve and ambient behavior, not a failing CPU (topic B11 covers it). Both are curve phenomena, which is why the method in this guide records the curve over time instead of reading one number off a screenshot.
The method
Seven steps, in order
Every topic on this page is one step of this sequence applied to one situation. The order matters: changing something before measuring means you can't tell what the change did, and testing before categorizing means you'll run the wrong test.
- Establish the baseline. While the system is in its current state, record the numbers that matter for your complaint: temperature, effective clock, package power, throttle flags, error count, a benchmark score, the workload and its duration. The baseline is what "before" means in every later comparison.
- Reproduce the problem under a controlled workload — the real workload if it's reproducible, a sustained synthetic load if not. A problem you can't reproduce on demand can still be diagnosed, but only with the event log as your witness.
- Monitor the values that matter during the reproduction: temperature, effective clock, power, and the throttle flag, together, and note when each one changes. The timing of the changes is the evidence — what moves first is usually the cause.
- Determine the failure category: thermal (temperature at the limit, clocks following), power/current (power pinned at a limit, clocks falling, temperature fine), stability (errors, crashes, WHEA), memory (errors that follow the memory path), platform (power delivery, settings), or software. The category picks the test.
- Change one major variable at a time — the cooler, or the power limit, or the voltage, or the memory setting. Not two. Each single change is one clean experiment; a multi-variable change is a mystery you created.
- Retest with the appropriate instrument, run the same way, with the same monitoring. The retest result is the experiment's result, and it goes in the log next to the baseline.
- Verify with the real workload — the workload that actually failed, run the way it failed, long enough that it would have failed before. The synthetic retest found the category; the real workload confirms the fix.
The instrument
What to measure, and why each field earns its place
The log fields below are the minimum set that answers the three questions — thermal? power? stable? — and each field earns its place by ruling something in or out. Copy the template and fill it in before and after each change; the file is the memory your future self can't be trusted with.
| Field | Why it matters |
|---|---|
| Temperature — peak and settled | Says whether the thermal limit is the constraint. Compare against the model's own limit, not a generic number. |
| Effective clock (sustained) | The performance number that actually changed. A usage percentage is not a substitute for it. |
| Reported / current clock | Context only — it samples between boost and base from instant to instant. Don't diagnose from it. |
| Package power | A reading pinned at a clean round value means a power or current limit is the constraint, whatever the temperature says. |
| Utilization | Measures demand, not capability. 100% at a low clock is itself the throttle signature. |
| Throttle flag / reason | Names the limit that fired (thermal vs power) when your monitoring tool exposes it — the fastest confirmation there is. |
| Errors — WHEA, bugchecks, log entries | The stability layer. Copy them out with timestamps before any retest; they're the before/after evidence. |
| Benchmark score or result | The before/after performance evidence. Same workload every time, or it isn't comparable. |
| Workload and duration | The conditions. A number without its conditions is not a measurement — it's an anecdote. |
CPU model: Cooler: Settings (stock / OC / undervolt / XMP):
Date & time:
BEFORE
Load: (e.g. Cinebench multi-core, 10 min)
Temp peak / settled (C):
Effective clock (GHz):
Package power (W):
Throttle flag: none / thermal / power
Errors (WHEA / bugcheck / other):
Score or result:
AFTER (change made: ____________________)
Load:
Temp peak / settled (C):
Effective clock (GHz):
Package power (W):
Throttle flag:
Errors:
Score or result:Keep one file per diagnostic session. Every "is it better?" answer in this guide comes from two filled-in blocks in this file.
Jump to a topic
All 32 topics, filterable by category
The full cluster at a glance — filter by category or jump straight to a topic. The symptom selector below does the same thing from the other direction: start with what you're seeing and get routed to the topics that match.
32 of 32 topics
Or start from your symptom
Category A · Topics 1–5
CPU throttling
The five topics in this category answer one question each: which limit is doing the limiting, and how do you know from the data. They're ordered from the distinction that starts every throttle diagnosis down to the reading skills that make the distinction possible.
Thermal throttling vs power-limit throttling: how to tell them apart
Both look identical from the user's chair — a performance drop under sustained load — and the only way to tell them apart is what the temperature and power numbers are doing at the moment the clock drops. Thermal throttling is the silicon protecting itself: the temperature reaches the model's limit and the firmware lowers clocks until it cools. Power-limit throttling is the power budget running out: package power hits its configured ceiling (PL1/PL2, or a current limit) and clocks drop even when the temperature is well below the thermal cap. The two need opposite fixes — one wants a better thermal path, the other wants a limit checked against the hardware that's actually installed — which is why the distinction is the entire first step of the diagnosis.
The test is a single sustained load while watching three numbers: temperature, package power, and effective clock. If the temperature touches the limit a few seconds before the clock falls, it's thermal. If the clock falls while the temperature still has headroom and the power reading is pinned at a limit value, it's a power or current limit. There's a third common confusion worth naming: a power plan or BIOS setting that caps the limits well below what the hardware could handle — same monitoring signature as "power throttling," a different fix. The monitoring data decides; the guess doesn't.
Boost and all-core behavior: why the clock "drops" and when that's normal
A CPU's clock is not a fixed number. Most modern designs boost a few cores high when the load is light and the power and temperature headroom allow it, then fall back to a lower sustained all-core frequency when every core is busy. A game driving six cores at a high frequency and a render driving all of them at a lower one are the same CPU working correctly. The trap in troubleshooting is treating the all-core number as a drop: if you've only ever seen the boost number, a healthy sustained load looks like a failure.
The way to know what your CPU should do is to compare it against itself under the same conditions, not against a headline frequency. Record the sustained all-core clocks and temperature on a known-good day — or straight after resetting to known stock settings — and use that as the baseline. Anything meaningfully below that baseline under the same load and same cooling is the anomaly worth chasing. "It's lower than the spec sheet says" is not, by itself, a symptom; it's a description of how boost works.
Identifying throttling from monitoring data
Most monitoring tools expose the throttle reason directly — a flag or counter that says "temperature" or "power" while the firmware is actively limiting — and that flag is the fastest confirmation available. What's more useful is the correlation: the moment the throttle flag turns on should match the moment the effective clock falls and, for thermal throttling, the moment the temperature crosses the limit. When the flag, the clock, and the temperature all tell the same story at the same timestamp, the diagnosis is done in one run.
The flag can mislead in two ways worth knowing. Some tools report a stale throttle state, so a flag that stays lit long after the load stopped means nothing — check when it changed, not just that it's set. And a CPU can lose performance without ever raising a formal throttle flag: a power-plan cap, a background process eating cores, or a workload shape that simply doesn't boost. That's why the effective-clock-versus-expected comparison (topic E2) is the check that doesn't depend on the flag existing at all — the clock is always telling you something, even when the flag is silent.
Power limits and current limits: the ceilings that aren't the CPU
Power limits are the configured ceilings on how much power the CPU may draw. Modern desktop designs typically have a sustained limit (PL1) and a shorter burst limit (PL2) allowed for a time window, plus a current limit that can cap things lower still. When a workload exceeds a ceiling, the firmware drops clocks to fit inside it — and from the user's perspective that looks exactly like a "CPU problem." The critical diagnostic fact is that these limits are settings, not physics: they can be set conservatively by the OEM, left at a BIOS default, applied by a power plan, or chosen by a user, and any of them can be wrong for the cooling and power hardware that's actually in the box.
Finding out whether a limit is the cause means watching the package power number during a sustained load. If the power reading sits exactly on a clean value while the clocks fall, that's a limit doing its job, and the next question is what that limit is set to and whether the cooler and the motherboard's power delivery can support raising it. Raising a limit is a setting change, not a repair — it only helps if the thermal path and the power path can actually absorb the higher power, which is exactly what the retest after the change exists to find out.
Sustained-load vs burst performance: the slope is the signal
A short burst and a sustained load exercise different parts of the design. A 30-second task can draw the burst power limit, run at maximum clocks, and finish before either the thermal or the power budget becomes a problem — which is why a CPU can feel fast in quick tasks and slow in long ones. The sustained number is what the cooler determines: after a few minutes the temperature has reached its steady state and the clock settles at the highest value the thermal and power budgets allow together. "Fast in short tasks, slow in long ones" is the classic signature of a thermal or power ceiling, not of a slow CPU.
The diagnostic version of this is the slope: watch the clock over the first five to ten minutes of a fixed load. A clock that starts high and settles lower as the temperature rises is a normal transient ending at a steady state — measure where it lands, not where it started. A clock that never climbs properly, or that keeps dropping in steps during a stable load, is a different story and points at a limit or a cooling problem. The shape of the curve over time is information a single screenshot of the number never gives you.
Category B · Topics 6–11
CPU heat & cooling
This category separates the thermometer from the problem: reading the number correctly (6), then working down the physical path that sets it — mount (7), interface (8), airflow and ambient (9), the laptop's fixed budget (10), and the after-idle spike that isn't any of them (11).
Reading CPU temperature numbers: what the reading actually is
The "CPU temperature" any tool shows you is a computed value, not a direct reading of the silicon. Sensors report a case or diode temperature and the software applies a model-specific offset to estimate the junction temperature, so two tools can disagree by several degrees on the same CPU and both be "right" within their offset error. The practical rule: use one tool consistently and compare its numbers against each other over time, not against another tool's absolute numbers or against a spec sheet.
What matters more than the absolute number is where it sits relative to the CPU's throttle point and how it behaves over time. A CPU at 70°C under full load with headroom to its limit is a different situation from one at 85°C with five degrees of headroom, even though neither number is "dangerous" in isolation. The limit value itself is per-model — the manufacturer's datasheet lists it, and general desktop designs land somewhere in the high 90s to 100+°C, with laptops lower — so look up your specific CPU rather than trusting a generic "under 80" rule that was written for a different part.
Determining whether a cooler is inadequately mounted
The single most common "cooling problem" is not a broken cooler — it's an under-mounted one. A mount a few grams light on one side, a misaligned contact plate, or a cooler installed over a slightly uneven paste application can cost 10–20°C, which is the difference between a CPU that never throttles and one that throttles on every render. The symptom is usually a temperature that's high but "not crazy" under load, or a temperature that's fine in one workload and high in another.
The check is physical and quick: power off, remove the cooler, and inspect the paste pattern. A healthy mount leaves a thin, even film across the integrated heat spreader with a slight depression in the center where the die sits; a star pattern, dry patches, or a lopsided smear all indicate uneven contact. Reinstall using the manufacturer's torque and sequence (diagonal, two passes, to spec), retest with the same load, and compare against your recorded baseline. If the temperature drops by 5°C or more, the mount was the problem — and it was fixable without buying anything.
Thermal paste: when it actually matters and how to know it failed
Thermal paste (or a liquid-metal interface, or the factory pad on some coolers) fills the microscopic gaps between the cooler's contact plate and the CPU's heat spreader. Fresh, well-applied paste performs nearly as well as bare metal contact; degraded paste doesn't. The honest limitation: you can't see the paste's performance, so its state is inferred from the temperature. A CPU that used to hold 75°C under a known load and now holds 90°C on the same setup is the thermal path telling you something degraded — paste, mount, or fan.
Two patterns point specifically at the interface: a gradual warming over months to years (paste drying is slow), and a step change after the machine was moved or dropped (a shifted mount). Either warrants a repaste — which is also the right moment to check the mount while the cooler is off, because the two problems share a cause and a fix. Set the expectation correctly: a repaste on a well-mounted cooler typically recovers a few degrees at best if the paste was only mildly aged, and a large recovery if the interface had truly failed. If the temperature doesn't improve at all after a clean re-application, the problem is not the paste — it's the cooler's capacity, the airflow, or the ambient.
Case airflow and ambient temperature: the cooler's environment
A cooler moves heat from the CPU to the air; the case then has to move that air out. When the case can't exhaust, the air the cooler is blowing into is already warm, and every component in the box runs several degrees hotter than it would in a ventilated setup — which raises the CPU's steady state and, in the worst case, pushes it into throttling. The ambient around the machine matters the same way: a PC in a warm closet in summer can throttle on a load that was fine in a cool room in winter, with nothing about the hardware having changed.
The cheap diagnostic is the delta: measure the case's intake air temperature (a basic thermometer at the front mesh) and compare it with the CPU's idle temperature. A CPU idling 15–20°C above the intake air is normal; idling 30°C or more above it suggests the case isn't moving air — a blocked intake, a dead fan, or a cable mess starving the mesh. The fixes are in order of cost: clear the intake, restore or replace a dead case fan, and only then consider that the cooler itself is undersized for the CPU — because an "undersized cooler" diagnosis made inside a stifled case is often wrong, and the fix was airflow, not hardware.
Laptop cooling limitations: why they throttle differently
A laptop's cooler is a fixed budget: a small heatsink, one or two small fans, and a chassis that constrains both. That budget can be fine at idle and office loads and exhausted by a sustained CPU load — which is why laptops throttle far more than desktops, and why the throttle is usually the design working as intended rather than a fault. The diagnostic question on a laptop is therefore different from a desktop's: not "why is it throttling" (often: because that's what it does under sustained load) but "is it throttling more than this model should, given its age and the state of its thermal path."
The laptop-specific checks, in order: the age of the thermal path (paste and pads dry out on a laptop's integrated cooler, and a several-year-old machine can run 10°C or more hotter than when new — a service and repaste is the fix), the intakes (laptop intakes clog with dust faster than desktop cases, and a choked intake costs degrees), and the power profile (a "performance" mode on a thin chassis can push the CPU past what the cooler can sustain, trading clocks for brief bursts). Set the honest expectation: a thin laptop under a 30-minute CPU load will throttle, and the goal is to manage that — with power limits and workload scheduling — not to eliminate it.
Heat-soak: why the first load after idle spikes the temperature
Some systems show a strange pattern: the CPU idles cool, runs medium loads fine, but the first heavy load after long idle spikes the temperature dramatically before settling. This is heat-soak — while the CPU sat idle, the cooler and the surrounding case air kept absorbing residual heat, so when the load returns, the cooler's sink is already warm and the temperature overshoots before the fan ramp and the airflow catch up. It looks alarming, and it's usually the fan curve and the ambient, not a failing CPU.
The way to confirm it is the pattern itself: the spike happens after idle, not after load; the peak lasts seconds to a couple of minutes; and the temperature then settles to the normal load value. If that's your pattern, the fixes are behavioral, not hardware: a fan curve that keeps the fan at a moderate floor instead of near-silent at idle, a cooler with more thermal mass, or a case with better airflow. What it is not: a sign of a failing CPU or a dried paste — those show as a raised steady state across all loads, which is a different measurement and a different problem.
Category C · Topics 12–16
CPU instability
Instability is the category where the CPU produces wrong results or stops, and it's the one most likely to be misattributed — to the RAM, to the power supply, to a driver — because its symptoms are shared. These five topics are about attribution: what each failure shape means, what WHEA does and doesn't prove, and how to keep the CPU's own settings from masquerading as its own hardware.
Crashes, freezes and reboots: what each failure shape means
The three failure shapes point at different layers, and sorting them out is the first diagnostic step. A crash with a bugcheck code is the operating system catching a fault it can name — the code is a clue, and the dump file it writes is evidence. A freeze (locked screen, frozen cursor, no response) is often a component that stopped answering — a stalled read, a locked bus, a failed calculation path — with the OS unable to proceed and unable to record the cause. A sudden reboot with no log entry is the hardest: it's usually a power-delivery event (the system simply stops) or a fault severe enough to bypass logging entirely.
The correlation that makes the shapes useful is timing: all three, when CPU-related, appear under load and disappear at idle, and the load that triggers them is a clue in itself — a pure CPU load, a memory-heavy load, a specific game, a render. Record the workload, the duration into the workload, and what the log actually contains (or doesn't) for each event, and the pattern sorts the suspects: memory-heavy workloads point at RAM or the memory controller, pure CPU loads point at the CPU or its voltage, and instant-off reboots with nothing logged point at power delivery. One event is a coincidence; three events with the same trigger is a diagnosis.
WHEA CPU errors: what they do and don't prove
WHEA (Windows Hardware Error Architecture) errors are the firmware reporting a hardware-level problem to Windows, and the "WHEA-Logger" entries people find in the event log are usually correctable errors — the hardware caught a bad calculation or a bad read, fixed it, and logged the event. A handful of correctable WHEA CPU errors over months is background noise on many systems; a cluster of them, especially ones that appear under load and not at idle, is the hardware telling you its margins are thin. The key interpretive fact: WHEA is a symptom-reporting system, not a diagnosis — it tells you an error happened at a layer, not why.
The follow-through depends on the pattern. Correctable WHEA CPU errors that appear only under heavy load point at voltage margins (an undervolt or a tight overclock), a cooling limit, or — less commonly — a degrading component, and the test sequence is the standard one: confirm the load correlation, check the settings and voltage history, and run the controlled stress tests while watching for the errors to recur in the log. Uncorrectable WHEA errors, which crash the system, are a much harder stop: at that point the component has failed past its correction, and the move is data, warranty, or replacement — not more testing. Copy the log entries out with timestamps before any retest, because they're the before/after evidence.
Undervolt instability: the margin you removed is the bug
An undervolt — running the CPU at lower voltage for the same clocks to cut heat and power — is one of the most common causes of intermittent instability, and the sneakiest, because the margin it removes is small. A −50 mV undervolt might pass an hour of stress testing and still be a few millivolts short of what a rare load pattern needs — a specific instruction mix, a burst of AVX work, a power transient. The result is instability that appears without warning, in specific workloads, and with a low hit rate: exactly the pattern people write off as "random."
The diagnostic signature is the correlation with the setting: instability that appeared after the undervolt was applied, passes most tests, and disappears when the undervolt is removed. That before/after is the proof, and it's why the undervolt belongs on the change-history list before any hardware suspicion. The practical rule for undervolts: apply one step at a time (10–25 mV), retest with the same load that was originally failing, and treat the first appearance of any artifact, freeze, or WHEA as the line — not a warning to test a little harder. A stable undervolt is worth its heat savings; an unstable one is a mystery you installed yourself.
CPU instability vs memory instability: the separation procedure
CPU and memory instability share symptoms (crashes, freezes, artifacts) because the CPU and the memory controller are neighbors — on many modern designs the memory controller sits inside the CPU package — so a weak memory setting can look like a CPU problem and a marginal CPU can corrupt data in a way that looks like a memory error. The separation is procedural, not visual: run the memory-dedicated test first (a full pass of a proper pattern-based test). If it's clean, the memory path is exonerated for the purposes of the CPU test results; if it fails, the RAM or the memory controller is the suspect and the CPU-only tests are meaningless until it's fixed.
The order matters because of cross-contamination: a CPU stress test that also hammers the memory (which most of them do, at least partly) can fail on a memory problem and hand you a false CPU diagnosis. So the clean sequence is: memory test, clean; then a CPU-focused test that keeps the memory load light; only then a combined load. Failures that appear only in the memory test point at RAM/IMC; failures in the light-memory CPU test point at the CPU or its voltage; failures that appear only under the combined load are the hardest to attribute — and that's the case where the power delivery (VRM, PSU) enters the suspect list too.
Stock-setting instability: "I'm not overclocking" and the rest of the story
"I'm not overclocking" is a common and sometimes false comfort. Stock settings are a starting point, not a guarantee: a BIOS or microcode update can change voltage behavior, an OEM's power limits can be set aggressively, some boards' "stock" profiles include a factory overclock, and a marginal chip can be stable at its rated specs one day and unstable the next, because "stock" is a spec and the silicon's margin above that spec varies from chip to chip. Stock-setting instability is a real category, and dismissing it as "but I'm not overclocking" is how it goes undiagnosed for months.
The diagnostic approach is the same discipline as for an overclock, applied to the history: when did the instability start, and what changed — a BIOS update, a power-limit change, a Windows update, a cooler failure that raised the temperature? Then the controlled tests at documented settings, with the actual setting values recorded rather than assumed, because "stock" should mean specific numbers on your board. If the instability persists at genuinely conservative settings — default power limits, default voltages, a known-good cooler — the remaining suspects are the silicon itself, the memory controller, or the power delivery, and that's the point where the problem stops being a settings problem and becomes a hardware conversation: warranty, replacement, or a professional diagnosis.
Category D · Topics 17–21
CPU testing: what each instrument is for
These five topics are organized by the question each test answers, not by the software's marketing. The through-line is the scope of a pass: every pass is evidence about the path that test covered, and no pass — however harsh — is a certificate for the paths it didn't.
What Cinebench-style renders actually test
A multi-core render loop is a sustained, mixed integer-and-floating-point load that keeps every core busy for as long as you let it, and it's useful for three specific things: a repeatable performance number you can compare before and after a change, a sustained thermal load (the temperature reaches its steady state within minutes), and a moderate stability signal — it will catch gross instability, a crash or a score collapse, but it is not a margin tester. The score is the feature: it's the same workload every time on the same machine, so a 10% drop between two runs is a real signal that something changed.
The limitation people miss: a clean render run proves the CPU can sustain a rendering load without crashing. It does not prove the memory is stable, that the voltage margin covers every instruction mix, or that the power delivery survives a transient. People who "passed the benchmark" and still crash in other workloads aren't wrong about either fact — the test simply doesn't cover those paths. Use the render as the before/after measurement instrument (its score is your thermometer for performance) and as the thermal load, and reach for the dedicated tests when the question is stability rather than speed.
Prime95 workloads: small FFT, blend, and what each stresses
Prime95 is the classic heavy load, and its different torture-test options stress different things — which is the whole point of knowing which one you're running. The in-place / small-FFT variants keep the working set in cache and push the CPU cores and their voltage hard: the classic thermal and core-margin test, and the one that runs hottest. Blend adds a memory-bandwidth load on top of the CPU load, which raises power and temperature further and starts to involve the memory path. The large-FFT-style tests lean on memory bandwidth and run cooler than small FFT, closer to a memory-subsystem stress than a core test.
The interpretation rule: a failure in small FFT with clean memory tests points at the CPU cores or their voltage; a failure in blend that doesn't reproduce in small FFT points more toward the memory path or the combined power draw; a system that fails only under the heaviest variant may be hitting its power-delivery limit rather than a silicon limit. And the honest scope: Prime95 is deliberately beyond real-world demands — it's a margin amplifier. Passing it is strong evidence; failing it doesn't automatically mean your daily system is broken, and passing your real workloads after a Prime95 failure can be a legitimate "it's fine for my use" conclusion. It's the strongest general-purpose tool, not the only one.
OCCT and error-focused stability tests
OCCT-style tools are built around a different idea than a benchmark: instead of measuring a score, they run a specific subsystem load (CPU, memory, cache, power) and actively check the results for errors, reporting the first bad value. That makes them better than a score-based benchmark for the question "is there an error in the computation," and worse for the question "how fast is it" — two different questions that need different instruments. The power and voltage stress variants deliberately create the kind of electrical transient that exposes marginal VRMs and PSUs, which a smooth render load never produces.
The interpretation caveat: an OCCT error is evidence of instability somewhere in the path that test exercises, and the path includes more than the CPU die — the cache, the memory controller, and the voltage regulation all sit between "the test" and "the CPU." So a failed OCCT CPU test means "something in the CPU path is unstable under this load," and narrowing it to the die versus the cache versus the voltage is the same one-variable process as everywhere else on this page. Use the tool for what it's good at — error detection — and use the controlled comparison runs to do the attribution.
Memory testing: how much CPU diagnosis it actually covers
A dedicated memory test — a full pass of a proper pattern-based test, not a quick diagnostic — is the instrument for the memory path: the RAM modules, their timings, and, critically, the memory controller inside the CPU, because on modern platforms a "memory error" and an "IMC error" are often the same physical problem wearing two names. Its role in CPU diagnosis is to exonerate or implicate: a clean full pass lets you remove the memory path from the suspect list when you see a CPU-test failure, and a failure sends you to the RAM/IMC side — seating, timings, the XMP/EXPO profile, the module — before you touch any CPU conclusion.
Two practical notes change how people use it. Duration: a single quick pass catches gross failures; intermittent margin problems need the longer run, several full passes, which is why "I ran the memory test for ten minutes" is not the same statement as "I tested the memory." And load shape: a memory test is a memory test — it doesn't exercise the cores the way a render does, so a clean memory test doesn't exonerate the CPU any more than a clean render exonerates the memory. Each test clears its own path. The combined picture — memory clean, CPU test failing — is what narrows the diagnosis.
Real-world validation: the workload that actually failed
Every synthetic test on this page is a controlled load, and controlled loads have a blind spot: they don't run your actual workloads. A CPU that passes every torture test but stutters in one game, or a system that's stable in renders but freezes in a specific application, is telling you that the failing load shape — the instruction mix, the memory access pattern, the power transients of that particular software — isn't covered by what you ran. Real-world validation is the final step because it's the only test that includes the actual trigger.
The method that makes it diagnostic rather than just confirmatory: use the workload that actually failed as the test. Run it the same way it failed, for the same duration, while monitoring (temperature, clocks, the event log), and record the result against your baseline. If the original failure reproduces, you have a controlled reproduction — the most valuable thing in the whole process, because now you can change one variable and rerun the same failing workload. If it doesn't reproduce after a fix, that's the verification the G-category topics describe. The synthetic tests find the category of problem; the real workload confirms the fix, because it's the one that was broken.
Category E · Topics 22–25
Diagnosis & interpretation
The four skills that turn measurements into conclusions: reading the clock numbers correctly, keeping the before/after discipline, attributing failures to the right layer, and mining the event log for the intermittent ones.
Effective clock vs reported clock: the mismatch that carries the diagnosis
Monitoring tools show you two kinds of clock numbers, and confusing them is a classic misdiagnosis. The "reported" or "current" clock is what the CPU's frequency counter says at a sample instant — it can jump between boost and base from one sample to the next and tells you almost nothing by itself. The useful number is the effective clock under a defined load: what the CPU is actually sustaining while doing the work. The diagnostic question is always "what is the effective clock during this load, compared to what it should be for this load and these settings" — not "what number is the tool showing right now."
The comparison that carries the diagnosis is the delta under identical conditions: the effective all-core clock during a sustained render, run today, versus the same run recorded when the system was known-good. A gap of a few percent is sampling noise and workload variance; a gap of 10% or more is a real performance change that the temperature and power numbers then explain — thermal, power limit, or a settings change. Recording the effective clock as part of every before/after log is what turns "it feels slower" into a measurable, attributable change.
Before/after measurement discipline: why the log comes first
The rule that saves more diagnoses than any test: record the numbers before you change anything. Temperature, effective clock, package power, throttle flags, error count, benchmark score, workload and duration — a short logged set, captured while the system is in its current state. The reason is that after you've changed the cooler, the voltage, and the BIOS settings, "was it worse before?" is no longer answerable from memory, and most troubleshooting dead-ends are actually unanswerable questions that a ten-minute baseline log would have answered.
The companion rule is one variable at a time. Change the cooler and retest; change the power limit and retest; change the voltage and retest. Change all three and the result tells you nothing — an improvement could be any of the three, and a persistence of the problem could mean the third change masked the first. Each single-variable change with a retest between them is one clean experiment; a triple change is one confused experiment. The before/after log is the instrument that makes the single-variable method work, and it costs nothing but a text file — the template in section 5 is made to be copied and filled in.
Separating CPU problems from motherboard and power problems
Some "CPU problems" are the platform around the CPU: the VRMs that deliver its power, the PSU that feeds the VRMs, the board's power limits and settings. The signature that points at the platform rather than the die: failures that follow power delivery — instant reboots with no log under heavy load, instability that appears at high package power, VRMs that run hot enough to derate, a system that's stable at a low power limit and unstable above it. A CPU that's marginal at 90W and rock-solid at 65W is telling you about the power path, not the silicon.
The separation tests are power-based, not workload-based: run the same heavy load with the power limit lowered, and if the instability disappears, the power delivery — VRM, PSU, or the limit itself — is on the suspect list; check the VRM temperature under load (a monitoring tool or a non-contact thermometer at the heatsink); and test the power limit in the other direction as a diagnostic, raising it temporarily to see if behavior changes, with the caution that you're asking more of the power path. The motherboard's BIOS settings — power limits, current limits, VRM settings — are part of this layer too: a board misconfigured for its own hardware produces exactly the "CPU instability" that isn't the CPU's fault.
Intermittent failures: what the event log actually tells you
Intermittent is the hardest category, because the failure isn't there when you're looking, and the standard response — reboot, retry, "it's fine now" — is exactly what destroys the evidence. The event log is the instrument for intermittency: it records what the system saw when you weren't watching — WHEA entries with timestamps, unexpected-shutdown entries with (or without) a bugcheck field, thermal events, driver errors. The method is to pull the log before every retest (export it, copy it out), timestamp your changes against it, and look for the pattern: which entries cluster with which of your logged workloads and changes.
Two log facts that people miss. An unexpected-shutdown entry with no bugcheck code is the signature of a power event — the system stopped before it could record a fault — and it points at power delivery rather than the CPU's logic. And a cluster of correctable WHEA entries that stops after a settings change is your proof that the setting was the cause, even if the visible crashes were rare. The log turns "it happens sometimes" into a dated, attributable record, which is the difference between diagnosing an intermittent problem and waiting for it to happen again.
Category F · Topics 26–29
Fixes, as controlled changes
Every fix on this page is one variable in the seven-step method. The difference between a fix and a hope is the retest that follows it — each topic below ends at that retest.
Reverting an overclock safely (and verifying the revert)
When a system is unstable and an overclock — or an XMP/EXPO memory profile, or a factory "boost" profile — is in effect, the first fix is the revert, not because it's most likely the cause but because it's the one change that removes the largest variable with the least risk. A stable stock system is the baseline every other diagnosis needs; you cannot attribute a failure to cooling or power delivery while the voltage and clock settings are also above spec. The revert is the control experiment, and it has to be a full revert: CPU ratio and voltage, the memory profile, and the "auto" settings the board applies on top.
Verifying the revert matters as much as the revert itself: after the reset, rerun the same load that was failing and record the result. If the instability is gone, you've proven the settings were involved, and the path forward is to re-apply one adjustment at a time — clocks, then voltage, then memory — with a test between each step, rebuilding the overclock deliberately instead of rediscovering it by accident. If the instability persists at verified stock, the settings are exonerated and the diagnosis moves to cooling, power delivery, or the hardware itself — a conclusion you couldn't have reached while the overclock was masking it.
Power limits and fan curves: the two BIOS-side dials that do most of the tuning
Two BIOS-side settings do most of the legitimate tuning for thermal and performance problems, and both are reversible with zero hardware risk. Power limits (PL1/PL2, and the current limit) set how much the CPU may draw, and setting them deliberately — matched to what the cooler and the power delivery can sustain — is the cleanest way to trade a bit of peak performance for a stable, cooler system. Fan curves set how the cooling responds to temperature, and a curve with a sensible floor (the fan never quite stops) plus an earlier ramp is the standard fix for heat-soak spikes and for a system that idles near-silent and then spikes.
The discipline is the same as everywhere on this page: change one setting, retest with the same load, record the before/after — temperature, effective clock, power, score. A power-limit change should show up as a lower package-power ceiling and a stable effective clock; a fan-curve change as a lower peak temperature and a reduced after-idle spike — each with its own measurable signature. What settings should not do is hide a real problem: a power limit set low to stop throttling is treating the symptom, and the underlying cooling limit is still there, just quieter. The settings manage the trade; they don't replace a working thermal path.
Cooler remount and repaste as a diagnostic procedure
The cooler work — remove, inspect, reapply the interface, remount to torque — is both a fix and a diagnosis, because the inspection answers questions the temperature alone can't: how even was the contact, how degraded is the paste, is the mount hardware intact, is the contact plate flat. As a procedure it has a specific order for a reason: power off and unplug (the CPU and the cooler are both hot and both fragile), remove the cooler, photograph the paste pattern (the before-evidence), clean both surfaces, apply a fresh and correct amount of interface, and remount in the manufacturer's diagonal sequence to the specified torque.
The measurement that closes the loop is the same sustained load, run after the work and compared against the recorded pre-work baseline — same tool, same load, same duration. A recovery of 5°C or more confirms the interface or the mount was the problem; a recovery of 1–2°C means the interface was only mildly aged and the bigger limit lies elsewhere — airflow, ambient, cooler capacity; no recovery means the paste was never the problem. Keep the photograph of the old paste pattern — a star pattern or a dry patch is the physical proof that the mount was the cause, and it's the difference between a fix you can explain and a fix you hope worked.
BIOS and firmware: the invisible settings layer
The BIOS/firmware layer is where a surprising number of "CPU problems" live, and where the least understood changes happen. A BIOS update can change voltage behavior, power-limit defaults, and microcode — any of which can fix or introduce instability; a "load optimized defaults" can silently reset the power limits and fan curves you had tuned; and a corrupted or misconfigured BIOS state — a half-applied setting, a failed update — can produce exactly the intermittent, hard-to-attribute instability that makes people suspect the silicon. The layer is invisible in the monitoring tools, which is why it's both a common cause and a common miss.
The safe working order with firmware: first, record the current settings (a screenshot of each BIOS page, or the board's save-to-file feature) so you can revert; second, if a BIOS update is suspect, note its version and date against your event-log timeline before doing anything; third, if a reset is needed, do a full reset (clear CMOS, load defaults) as the clean state, re-verify the baseline, and re-apply settings one at a time with a test between — the same single-variable discipline, applied to the settings layer. Firmware is the one "fix" that can change the behavior of every other layer at once, which is exactly why it gets its own careful procedure instead of a quick button press.
Category G · Topics 30–32
Verification: proving it's actually fixed
The three topics that end every diagnosis: the retest standard (30), how long the evidence has to run (31), and what the goal actually is (32) — because a cooler temperature by itself is not the goal.
Proving a fix actually worked
The standard that separates "it seems better" from "it's fixed": rerun the same test that originally failed, under the same conditions, and get a clean result — plus the before/after numbers showing the change the fix was supposed to produce. A cooler fix is verified by a lower steady-state temperature and a recovered effective clock, not by "the fan is quieter." A power-limit fix is verified by a stable clock under the same load at the new limit. A settings revert is verified by the original failing workload running clean. Each fix has its own measurable signature, and the verification is checking that signature — not checking your feelings.
The second half of verification is the original trigger: the real workload that actually failed, run the way it failed, for long enough that it would have failed before. A fix that passes the synthetic retest but hasn't faced the original failing workload is a hypothesis, not a conclusion — the synthetic test found the category, and the real workload is the one that was broken. Both results, clean, is what "fixed" means, and logging both against the baseline (the numbers from before the fix) is what makes the claim defensible to your future self when the question comes up again.
Long-duration validation: how long is long enough
"How long is long enough?" has no universal answer, because the question determines the duration. Thermal behavior — where the temperature lands, whether it throttles — reaches its steady state in minutes, so a 15–30 minute sustained load answers the heat question completely; running it for three hours learns nothing new about heat. Stability margins, on the other hand, are about rare events: the specific load pattern that exposes a thin voltage margin may need hours of the right load to hit, which is why the stability tests run long and why "I ran it for ten minutes" is an answer to a different question. Match the duration to the question you're answering.
The practical protocol: after a fix, run the relevant sustained load for a duration that covers both the thermal steady state and a stability margin — a couple of hours of the heavy test is a reasonable general target for a stability question, longer if the original failure was intermittent — and then the real workload for a full session. If the original problem was intermittent with a low hit rate, the honest verification is a longer period of actual use: the fix is proven when the failure stops happening over the time it used to happen, not when one clean test run completes. Duration is evidence, and the amount of evidence required is set by how rare the failure was.
Stability vs temperature: why a lower number is not the goal
The goal confusion that ends most CPU troubleshooting in the wrong place: treating a lower temperature as the objective, when the actual objective is a system that performs and doesn't fail. A cooler that drops the peak by 8°C but leaves the CPU throttling at a lower temperature has changed the number without changing the problem; a system that runs 5°C hotter than its neighbor but never throttles and never errors is not the problem system. Temperature is a means to staying inside the limits, and the limits — thermal, power, voltage margin — are what the verification should be measured against.
The correct end state, stated as checks: the effective clock under the sustained load is at or near the expected value (performance restored); the throttle flags are not raising during that load (inside the limits); the error count is not growing (stable); and the real workload runs clean (the original problem gone). A lower temperature that doesn't move any of those four is a cosmetic result — pleasant, maybe, but not a fix. This is why the before/after log in section 5 records all four categories of measurement and not just the thermometer: the thermometer tells you the means changed; the other three tell you whether the goal was reached.
The instruments, compared
The testing matrix
Category D in table form: each major test organized by what it can tell you. The columns answer the four questions every test selection should start with — what does it stress, is it a good thermal load, is it a good stability load, and what does a pass not prove?
| Test | What it stresses | Good for heat? | Good for stability? | Memory involvement | Main limitation |
|---|---|---|---|---|---|
| Cinebench-style render loop | All cores, sustained mixed load | Yes — reaches steady state in minutes | Limited — catches gross failures only | Low–moderate | Not a stability proof; score is its real value |
| Prime95 — small/in-place FFT | Cores + voltage, hardest standard load | Excellent — runs hottest | Strong for core margins | Low | Deliberately beyond real-world; failure ≠ daily-use problem |
| Prime95 — blend | Cores + memory bandwidth together | Yes — higher than small FFT on power | Strong, broader path | Higher | A failure can be CPU, memory, or power delivery |
| OCCT CPU / power tests | Specific subsystem, checked for errors | Yes | Strong — reports the first error | Depends on the variant | Error location needs attribution work |
| Memory test (full passes) | RAM, timings, memory controller | Indirect only | Useful for the memory path | High — that's the point | Doesn't prove the CPU cores are stable |
| Real workload (the failing one) | Your actual instruction mix and transients | Variable | Valuable — it's the actual trigger | Workload-dependent | Less controlled; needs monitoring to be diagnostic |
Quick reference
Symptom → likely cause → useful test
The compact version of the whole page. Start at your symptom, run the suggested test with the monitoring from section 5, and let the numbers pick the category.
| Symptom | Likely cause | Useful test |
|---|---|---|
| Performance drops as a load continues | Thermal or power ceiling | Sustained load + temperature/power/clock monitoring |
| Clocks drop while temperature is acceptable | Power or current limit, power plan | Package power reading + limit check in BIOS/OS |
| 100% usage at low clocks | Throttling, any type | Throttle flag + temperature/power correlation |
| High temperature at idle or after idle | Heat-soak, ambient, fan curve | Idle-to-first-load temperature curve |
| Random reboot under heavy load | Instability or power delivery | Stress test + event log (bugcheck field, WHEA) |
| WHEA CPU errors under load | Voltage margin, undervolt, degrading component | Load-correlated log review + controlled stress |
| Crashes only in memory-heavy workloads | RAM or memory controller | Dedicated memory test first, then CPU tests |
| Crashes only in one game or app | Workload-specific margin, driver, settings | Rerun the failing workload while monitoring |
| Slower after a BIOS or Windows update | Settings or microcode change | Before/after log + settings diff against history |
| Laptop throttles immediately on load | Design limits + thermal path age | Model expectations + intake/thermal service check |
Guided route
Diagnostic decision tree
Answer the questions in order and the tree routes you to the topics that match your situation. It's a navigator, not a diagnosis — and where a measurement is needed, it tells you which one instead of guessing.
Step 1
FAQ
CPU questions, answered
Is 100°C always dangerous for a CPU?
Not by itself. Every CPU model has its own maximum operating temperature (listed in the datasheet; many desktop designs sit in the 90–105°C range, laptops lower). Reaching that limit is what triggers thermal throttling — the CPU lowers its clocks to stay safe — so a reading at the limit means the cooling is the bottleneck, not that the chip is being damaged by that reading. What matters is how long the CPU spends at the limit and what you lose in clocks while it's there.
Does thermal throttling damage a CPU?
Throttling is the protection working, and brief episodes are normal. Chronic throttling — the CPU spending most of a load at the limit — means the thermal path is undersized for the workload, and running hot for long periods is harder on the hardware than running cool, but the throttle action itself is not the damage. The fix is the cooling, and the verification is that the clocks recover.
Why does CPU usage stay at 100% while the clock drops?
Because utilization measures demand, not capability. A throttled CPU is still working as hard as it's allowed to — it's just doing less work per cycle at the reduced clock. 100% usage at low clocks is in fact the classic signature of throttling, which is why the clock and the throttle flag belong in the same log as the usage number.
Why does my CPU pass Cinebench but crash in games?
Because the two loads are different. A render loop is a sustained, predictable core load; a game drives the cores, the memory controller, the cache, and the power delivery in a different, less predictable pattern. Passing one test is evidence about that test's path, not a stability certificate for every path — which is why the real failing workload gets its own re-test.
Can high temperatures cause WHEA errors?
Heat by itself usually produces throttling, not calculation errors — the firmware lowers clocks before the silicon misbehaves. WHEA errors under load more typically point at voltage margins (an undervolt, a tight overclock) or a degrading component, and heat can aggravate both. Treat a cluster of load-correlated WHEA entries as an instability signal and work the settings and margins before suspecting the die.
Can an undervolt cause intermittent instability?
Yes — it's one of the most common causes of rare, hard-to-reproduce instability, because the removed margin only matters under specific load patterns. The signature is instability that appeared after the undervolt, passes most tests, and disappears when the undervolt is removed. If that before/after matches your history, the undervolt is the diagnosis, and the fix is to back it off to a margin that survives your actual workloads.
How long should I stress-test a CPU?
It depends on the question. Thermal behavior reaches steady state in minutes, so 15–30 minutes of sustained load answers the heat question. Stability margins are about rare events, so stability questions need longer runs (hours of the heavy test) and, for intermittent failures, a period of real use. There is no single duration that "proves" stability — the duration is set by what you're trying to find.
How do I tell if the CPU or the RAM is causing crashes?
By test order, not by the symptom. Run a full memory test first: if it fails, the memory or the memory controller is the suspect and the CPU test results are contaminated. If it's clean, run the CPU-focused tests — failures there point at the CPU or its voltage. Failures only under combined heavy loads add the power delivery (VRM, PSU) to the list. Each test clears its own path; the combination narrows the diagnosis.