Fix WHEA_UNCORRECTABLE_ERROR in Windows 11

Your PC restarts on its own, sometimes mid-game, sometimes just sitting idle at the desktop, and Windows 11 shows a blue screen with WHEA_UNCORRECTABLE_ERROR before it reboots. I've had this happen on a client's workstation that had run fine for two years, then started dropping every few hours after a BIOS update went bad. Nothing in the software had changed. That's the first thing to understand about this one: it almost never starts with an app or a Windows update, it starts with a piece of hardware reporting a problem it can't recover from.

WHEA_UNCORRECTABLE_ERROR is bug check 0x00000124. WHEA stands for Windows Hardware Error Architecture, the subsystem Windows uses to catch and log hardware faults reported by the CPU, chipset, or firmware. According to Microsoft's bug check reference, this stop code fires when WHEA receives a fatal hardware error it cannot correct, and Microsoft explicitly says it's "typically related to physical hardware failures" — heat, defective memory, a failing or overclocked processor, or a dying power delivery component. It is not, by design, a driver crash, even though a driver is sometimes the thing that surfaces a marginal piece of hardware under load.

What WHEA_UNCORRECTABLE_ERROR actually means

When a CPU core, memory controller, or PCIe device detects an error it can't correct on its own, it raises a machine check exception. The Windows kernel's WHEA layer catches that exception, packages the details into a WHEA_ERROR_RECORD, and if there's no way to keep running safely, it bugchecks the system with code 0x124 rather than let it continue with corrupted data. The record it saves before going down almost always names the component that failed — that record is the single most useful piece of evidence you have, and most people troubleshooting this error never look at it.

You don't need a debugger to read it. Open Event Viewer, expand Windows Logs → System, and filter the current log for the source WHEA-Logger (Action → Filter Current Log → Event sources → WHEA-Logger). Look for Event ID 1 (a fatal error, matching your BSOD) or Event ID 17/18/19 for corrected errors that preceded it. Open one and read the "Reported by component" line in the General tab. That single line tells you which of three very different investigations to run next.

Symptom, confirming check, and fix at a glance

What you're seeing	Confirming check	Fix to apply
BSOD names WHEA_UNCORRECTABLE_ERROR, "Reported by component: Processor Core"	WHEA-Logger event, Error Type: Internal Parity Error or Cache Hierarchy Error	Undo overclock/undervolt, check VRM temps, reseat CPU, retest at stock clocks
BSOD happens under load (gaming, compiling, rendering)	Reliability Monitor shows crashes cluster with CPU/GPU-heavy apps; HWiNFO shows thermal throttling near the crash timestamp	Improve cooling, reapply thermal paste, check case airflow, cap boost clocks
WHEA-Logger event lists "Reported by component: Memory" or references a DIMM/bank	Windows Memory Diagnostic (mdsched.exe) in extended mode, or MemTest86 overnight	Disable XMP/EXPO, reseat RAM, test one stick at a time, replace failing stick
Event lists "Reported by component: PCI Express Root Port"	Check which slot that root port maps to (GPU, NVMe, add-in card) in motherboard manual	Reseat the card, try a different slot, update its firmware, test with it removed
Crashes started right after a BIOS/UEFI update	Compare BIOS version in msinfo32 against the motherboard vendor's release notes for known issues	Check for a newer BIOS revision or documented rollback path from the vendor first
Crashes started after a Windows Update, no hardware changed	Check Settings → Windows Update → Update history for the exact KB, then the KB's Microsoft support page for known issues	Apply Microsoft's documented fix or the superseding update if one exists

That table only works if you actually open the event log entry — don't skip straight to the fixes column.

Rule out a known, already-fixed issue first

Before you touch hardware, check whether this is something Microsoft or your motherboard vendor already has a documented fix for. Microsoft's own support article for this error puts "use Windows Update to get the latest updates and drivers" as step one, ahead of anything manual, and that's the right order — a chipset or storage driver bug that's already been patched is a five-minute fix, not a hardware investigation. Open Settings → Windows Update → Check for updates, and separately open Settings → Windows Update → Advanced options → Optional updates to see if there's a driver update sitting unapplied. If your BSOD started right after a specific cumulative update, search that KB number plus "known issues" on support.microsoft.com before doing anything else — Microsoft documents known-issue rollbacks there when a patch causes regressions.

What I would not do

Run SFC and DISM as a first move. They fix corrupted system files, not machine check exceptions from silicon. I still run them eventually, but only after ruling out hardware, because they waste twenty minutes solving a problem you don't have.
Reinstall Windows immediately. If the underlying cause is a marginal RAM stick or a CPU running too hot, a clean install will crash again within days. I've watched people do three reinstalls before finally running a memory test.
Turn on Driver Verifier as a general troubleshooting step. It's a legitimate diagnostic tool, but WHEA 0x124 is fundamentally a hardware-reported error, and Verifier is built to stress driver code paths, not memory chips or CPU cores. It's worth trying only after you've confirmed drivers, not hardware, are implicated — and even then, expect more crashes while it's enabled, so create a restore point first and don't leave it on indefinitely.
Assume it's the GPU because gaming triggers it. Games load the CPU, RAM, PSU, and cooling simultaneously. "It happens when I game" tells you the system is under stress, not which component is failing.
Buy new RAM before testing the RAM you have. Run the diagnostic first. I've seen this turn out to be a loose DIMM that just needed reseating.

Fix it in this order

1. Update Windows and drivers, then check BIOS separately

Run Windows Update fully, including optional driver updates. Then check your motherboard (or laptop) vendor's support page for a BIOS/UEFI version newer than what msinfo32 reports under "BIOS Version/Date." Firmware bugs in early UEFI revisions for a new CPU generation are common and vendor release notes will often say so directly — read them before flashing anything.

2. Undo any overclock, XMP, or EXPO profile

Go into BIOS/UEFI and set CPU clocks, voltages, and memory timings back to their JEDEC/stock defaults, including turning off XMP or EXPO memory profiles. This is the single highest-value non-destructive step for this specific error. Overclocking and aggressive memory profiles push components outside the tolerances the manufacturer validated, and WHEA is exactly the mechanism that catches the instability that results. If the crashes stop, you've found your answer, and you can reintroduce a lighter, more conservative overclock later if you want to chase it.

If your board doesn't have a "load optimized defaults" option that's obviously labeled, a CMOS reset (removing the battery for a minute, or using the board's clear-CMOS jumper/button) accomplishes the same thing and is safe on virtually every consumer board.

3. Run Windows Memory Diagnostic in extended mode

Press Windows key + R, type mdsched.exe, and choose to restart and check for problems. When the tool starts, press F1 immediately to switch to extended test mode, which runs more thorough pattern tests than the default pass. Let it run overnight if you can — a stick that fails only after hours of testing is still a failing stick. If it hangs at a fixed percentage for hours, that itself is a sign of a memory fault, not a frozen tool.

mdsched.exe

If you'd rather use a more thorough third-party tool, MemTest86 (the standalone bootable version, not the old memtest86+ fork exclusively) is the one I reach for when mdsched comes back clean but I still suspect memory — it's more sensitive to marginal timings.

4. Reseat and isolate memory and expansion cards

Power down, unplug, and reseat every RAM stick and any add-in card (GPU, NVMe add-in card, capture card) that sits in a slot reported by the WHEA event. If you have more than one RAM stick, pull all but one and test with a single stick at a time in the primary slot — this is how you isolate a bad stick from a bad slot. It's tedious. It's also the check that actually tells you which part to replace instead of guessing.

5. Check temperatures under the load that triggers the crash

Run HWiNFO or your motherboard vendor's monitoring tool while reproducing the workload that crashes the machine — gaming, video export, a compile job. Watch CPU package temperature and VRM temperature if your board exposes it. Sustained temps near your CPU's documented thermal limit, or any sign of thermal throttling right before the crash timestamp in Event Viewer, points at cooling: reseated thermal paste, a stuck fan curve, or blocked airflow from dust.

6. Check the power supply

This is the one people skip because it's not exciting, but marginal PSUs under load are a real and underappreciated cause of CPU/memory-reported errors, especially in systems that were fine at stock and only started faulting after a GPU upgrade increased peak draw. If you have a spare PSU of adequate wattage, swapping it in for a stress test is a cheap way to rule this out before you replace a CPU or motherboard.

7. Last resort: reinstall Windows or replace hardware

If every check above comes back clean — updated firmware, stock clocks, memory tests pass overnight, temps are normal, PSU tests fine — and the crashes continue, you're looking at either a genuinely failing CPU, a marginal motherboard (VRM or PCIe controller), or a Windows installation with corrupted system files masking as hardware instability. At that point, back up your data, run sfc /scannow and DISM /Online /Cleanup-Image /RestoreHealth from an elevated prompt to rule out the software side, and if it still crashes, plan for a motherboard or CPU RMA rather than more reinstalls. A failing CPU rarely announces itself any other way than exactly this error.

sfc /scannow
DISM /Online /Cleanup-Image /RestoreHealth

Before you close the ticket

Confirmed you read the WHEA-Logger event and know which component it named
Updated Windows, drivers, and checked for a newer BIOS release specifically
Reset overclock/XMP/EXPO to stock and retested
Ran Windows Memory Diagnostic in extended mode (or MemTest86 overnight)
Reseated RAM and cards, isolated single-stick if multiple DIMMs are installed
Checked temps and PSU under the exact workload that triggers the crash
Only reached for SFC/DISM or a rebuild after hardware checks came back clean