0x00000124 WHEA_UNCORRECTABLE_ERROR
Most stop codes describe Windows noticing that something has gone wrong. This one is different: the hardware reported the fault itself, through the platform's own error reporting, and the error was not correctable. Microsoft's own guidance says it is typically a physical hardware failure. That makes it the most diagnostically honest stop code Windows produces - and the one where software fixes are least likely to help.
What you are looking at
Your PC ran into a problem and needs to restart.
Stop code: WHEA_UNCORRECTABLE_ERROR
In Event Viewer the matching entries look like this:
Log Name: System
Source: Microsoft-Windows-WHEA-Logger
Event ID: 18
Level: Error
A fatal hardware error has occurred.
Reported by component: Processor Core
Error Source: Machine Check Exception
Error Type: Cache Hierarchy Error
Processor ID: 4What the error actually means
Modern processors and chipsets carry their own error detection. Caches are parity-protected, memory paths are checked, PCI Express links validate what they receive. When one of those mechanisms finds a problem it cannot fix, it raises a machine check exception or an equivalent platform interrupt, and the Windows Hardware Error Architecture records what happened.
Bugcheck 0x124 is Windows relaying that report. It is not an inference drawn from a crash - it is a fault the silicon itself declared. That distinction matters, because it removes most of the ambiguity that makes other stop codes hard to diagnose.
The corollary is that reinstalling Windows, running sfc, or reinstalling drivers will almost never help. Microsoft's documentation is unusually direct about this: it notes the bug check is typically related to physical hardware failures, can be heat related, and says that if overclocking is enabled you should try disabling it.
Reading the parameters
Parameter 1 identifies which error source reported the fault, and parameter 2 always holds the address of the error record - which is the key to the whole diagnosis. Parameters 3 and 4 only carry meaning when parameter 1 is zero.
| Parameter | What it holds |
|---|---|
| 1 = 0x0 | A machine check exception occurred - the processor's own error reporting. The most common value on desktop hardware. Here parameter 3 holds the high 32 bits and parameter 4 the low 32 bits of the MCi_STATUS register for the machine check bank that reported the error. |
| 1 = 0x1 | A corrected machine check exception occurred. |
| 1 = 0x2 | A corrected platform error occurred. |
| 1 = 0x3 | A non-maskable interrupt error occurred. |
| 1 = 0x4 | An uncorrectable PCI Express error occurred. This is the fatal counterpart of the corrected PCIe errors logged as WHEA-Logger Event 17 - if you have been watching corrected errors accumulate, this is what they escalate into. |
| 1 = 0x5 | A generic hardware error occurred. |
| 1 = 0x6 / 0x7 | An initialization error, or a BOOT error. |
| 2 | The address of the WHEA_ERROR_RECORD structure describing the fault. Always populated regardless of parameter 1, and the single most useful value here - see the triage step below. |
| 3 / 4 | Reserved for every parameter 1 value except 0x0, where they hold the two halves of the MCi_STATUS register. |
What actually triggers it
Microsoft's own cause guidance leads with physical hardware, heat, and overclocking. In practice the ordering below reflects what actually turns out to be responsible.
| Cause | How often | Detail |
|---|---|---|
| Unstable overclock, undervolt or memory profile | Common | The most frequent cause on enthusiast machines, and the first thing to eliminate because it is free. This includes XMP and EXPO profiles, Precision Boost Overdrive, curve optimiser settings and undervolts - all of them, not just deliberate frequency overclocks. A curve that passes an hour of benchmarking can still be unstable at the light bursty loads of ordinary desktop use. |
| Thermal problems | Common | Microsoft explicitly notes this can be heat related. A cooler that has come loose, dried thermal paste, blocked intakes, or a failed fan. Check that temperatures are sane under load before assuming a component is defective. |
| Power delivery | Common | An ageing or overloaded supply produces voltage dips under transient load that the processor reports as machine checks. This is under-diagnosed because the PSU is rarely anyone's first suspect and rarely produces an obvious symptom. |
| Failing memory | Occasional | Uncorrectable memory errors surface here, particularly on systems with ECC. Testable, and worth testing. |
| Failing processor or motherboard | Occasional | Where the diagnosis lands when settings are stock, temperatures are fine and the power supply is good. Decoding the error record narrows which one. |
| Drivers | Rare | Microsoft describes it as less likely but possible that a driver causes the hardware to fail this way. Treat a driver explanation as a last resort here, not a first move. |
Narrowing it down
There is one step that matters far more than the others on this code, and it is not the usual one.
Decode the error record with !errrec
This is the whole game. Open the dump in WinDbg, run !analyze -v, note the address in Arg2, then run:
!errrec <address from Arg2>The output names the reporting component and the error type in plain language - Processor Core, Memory, PCI Express Root Port, and a type such as Cache Hierarchy Error or Bus/Interconnect Error. The !whea and !errpkt extensions display further detail.
This converts a generic hardware failure into a specific subsystem. A cache hierarchy error points at the processor; a memory controller error points at RAM or the controller; a PCI Express error points at a card, slot or link. Nothing else on this page substitutes for it.
Return every setting to stock
Before any hardware is suspected, remove every tuning variable: disable XMP and EXPO, clear any CPU overclock, disable Precision Boost Overdrive and curve optimiser, remove any undervolt, and reset the UEFI to defaults if you are unsure what is set.
If the crashes stop, the hardware is fine and the settings were not achievable on your particular silicon. This is the single most common resolution for this bugcheck and it costs nothing but a small amount of performance.
Check temperatures under sustained load
Log CPU package temperature and, if available, individual core temperatures with HWiNFO64 during a sustained load. Compare against the processor's rated maximum.
Sustained operation at or near the thermal limit explains the fault without any component being defective. A cooler mounted badly or paste that has dried out is a repair, not a replacement.
Look for corrected errors preceding the fatal one
Filter the System log for WHEA-Logger and look at the days before the crash:
Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Microsoft-Windows-WHEA-Logger'} |
Group-Object Id | Sort-Object Count -Descending |
Format-Table Name, Count -AutoSizeA history of corrected errors escalating into an uncorrectable one is the clearest possible evidence of a component degrading rather than failing suddenly. It is also the strongest thing you can bring to a warranty conversation.
Fixes, cheapest first
The first two resolve a large share of cases and cost nothing. Beyond them, this stop code mostly leads to replacing a part.
Clear all overclocking and tuning
Enter UEFI and load optimised defaults, then verify individually that XMP or EXPO is off, no CPU multiplier or voltage offset is set, PBO and curve optimiser are disabled, and no undervolt is applied through software either - vendor utilities can apply one at Windows startup independently of firmware.
Run at stock for several days before concluding anything. If it holds, reintroduce one setting at a time.
Fix cooling
Clear dust from heatsinks, radiators and filters. Confirm every fan spins. Check that the case has real airflow rather than several intakes and no exhaust.
If the machine is more than a few years old, or if temperatures spike unusually fast under load, reseating the cooler with fresh thermal paste is a cheap and frequently effective repair.
Test and stabilise memory
With profiles disabled, run MemTest86 from USB for at least four passes. If errors appear, test each module individually in the same slot to identify which one.
Rule out the power supply
Use separate PCIe cables for each connector on the graphics card rather than daisy-chaining. If you can borrow a known-good supply with adequate headroom, run on it for a week.
As a cheaper diagnostic, cap the CPU and GPU power limits in firmware or vendor software. If the crashes stop at reduced power, the fault is in delivery rather than in the components themselves.
Update firmware
Microsoft's guidance specifically mentions checking for an updated system BIOS, ACPI or other firmware. Microcode updates shipped through UEFI have genuinely resolved machine check errors on specific processor steppings.
Watch outIf the drive is protected by BitLocker or Device Encryption, a firmware update can change TPM measurements and trigger a recovery-key prompt on the next boot. Check with
manage-bde -statusand save your key from account.microsoft.com/devices/recoverykey first - Windows 11 enables Device Encryption by default on much consumer hardware.Run the update on mains power and do not interrupt it.
When it is the hardware, not Windows
This stop code starts from the assumption of hardware, so the question is which part rather than whether. These narrow it:
!errrecnames a specific component - processor core, memory, or PCI Express.- The crashes continue at completely stock settings with good temperatures.
- Corrected WHEA errors were accumulating before the first fatal one.
- A clean Windows install makes no difference.
- Crashes occur at idle or shortly after waking, rather than under load.
- The rate is increasing week over week.
Once stock settings, cooling and the power supply are eliminated, this is a component replacement rather than a repair. Keep the dumps, export the WHEA history, and note the dates - the escalation from corrected to uncorrectable errors is a documented degradation curve and it is far more persuasive than a description of symptoms. Vendor diagnostics frequently pass machines that produce this bugcheck, so a passing test is one data point, not a verdict.
Frequently asked
My overclock has been stable for two years. Why would it be the cause now?
Because silicon ages. Electromigration gradually shifts the voltage a processor needs to hold a given frequency, so a setting that had adequate margin when new can fall below it years later. The overclock did not change; the part did. This is one of the most common patterns behind this bugcheck, and it is why returning to stock is worth doing even when the settings have a long track record.
Is XMP really an overclock?
Technically yes. XMP and EXPO run memory above the JEDEC-standard speed, validated by the module manufacturer on their own test platform - not on your CPU's memory controller or your board's trace layout. It is normal and usually works, but on a machine producing machine check exceptions it is a variable to remove, not an assumption to protect. Testing at stock costs ten minutes.
How does this relate to WHEA-Logger Event 17?
They are the same reporting architecture at two severity levels. Event 17 is a corrected error - the hardware detected a problem and recovered. Bugcheck 0x124 is an uncorrectable one, where recovery was not possible. A machine logging increasing numbers of corrected errors that eventually produces a 0x124 has shown you the full progression, and that sequence is the strongest hardware evidence available short of a part failing outright.
Can a driver really cause this?
Microsoft says it is less likely but possible - a driver can drive hardware into a state that produces a fatal error. In practice it is rare enough that pursuing it before eliminating overclocking, temperatures and power is a poor use of time. If !errrec points at a PCI Express error and one device is implicated, a driver for that device becomes worth considering.
I get 0x9C MACHINE_CHECK_EXCEPTION instead. Is it different?
Same underlying category, different reporting path. Bugcheck 0x124 was introduced with Windows Vista; before that, machine check exceptions were reported as bugcheck 0x9C.
On a current Windows version, Microsoft documents 0x9C as still firing in only two circumstances: when WHEA was not yet fully initialised - meaning the fault happened very early in boot - or when all the processors that rendezvoused to report the error had no error information in their registers. Everything else is reported as 0x124.
So seeing 0x9C rather than 0x124 is itself informative, and the 0x9C page covers what each of those two cases implies. The diagnostic approach is the same either way: stock settings, temperatures, power, then components.
Related errors
- WHEA-Logger 17A corrected hardware error has occurredHardware reported an error and recovered. One is noise. A burst of them is a warning.
- GuideHow to Read a Windows Crash Dump File with WinDbgInstall WinDbg, open the dump, run one command. Fifteen minutes, and it usually names the driver.
- 0x0000001AMEMORY_MANAGEMENTWindows' memory bookkeeping is corrupt. The first parameter tells you which kind, and that changes everything.