WHEA_UNCORRECTABLE_ERROR 0x124: Read the Record

WHEA_UNCORRECTABLE_ERROR is Windows reporting that hardware raised a fatal error it could not contain. The stop code is 0x00000124, usually shortened to 0x124.

That definition tells you what the blue screen does not say. It does not say “replace the CPU.” It does not make AuthenticAMD.sys or a processor name a diagnosis. Windows Hardware Error Architecture (WHEA) collects a record from the component or platform that reported the condition. Your next job is to read that record.

Microsoft’s 0x124 reference gives you the two fields that route the investigation:

• Parameter 1 identifies the kind of error source that reported the problem.
• Parameter 2 points to the WHEA_ERROR_RECORD that describes it.

Preserve those before changing firmware settings, reinstalling Windows or ordering a part.

First, make sure 0x124 was the crash

If the blue screen stayed up, photograph the stop code. If the PC restarted too quickly to read it, start with the random-restart guide. Its Event 41 command converts the saved decimal bug-check value to hexadecimal. Decimal 292 is 0x124.

If a bug-check value of zero is the only evidence you have, stay with the restart guide until a matching photo or dump confirms 0x124. The zero does not establish a stop code for that shutdown; it does not overrule separate evidence from the same crash.

Also keep corrected WHEA events separate from this blue screen. Microsoft’s WHEA error-processing documentation says Windows can log corrected hardware-error information without stopping. A fatal uncorrected condition is saved and followed by a bug check. Both deserve attention, but a corrected event alone is not proof that the machine had a 0x124 crash.

Preserve the dump before changing settings

Check C:\Windows\Minidump for a .dmp file whose timestamp matches the crash. A kernel or automatic dump can instead be at C:\Windows\MEMORY.DMP. Copy the matching file to a working folder so a later crash or cleanup cannot replace the only copy.

If no dump exists, configure the next one through System Properties > Advanced > Startup and Recovery > Settings. Microsoft’s small-dump guide documents the Small memory dump option and %SystemRoot%\Minidump location. A small dump can omit context that a larger kernel dump retains, but it preserves the stop code, parameters and kernel stack.

Write down what changed before the first crash:

• CPU, GPU or memory clock and voltage changes
• XMP or EXPO being enabled
• a BIOS update or settings reset
• newly installed memory or a PCIe device
• a cooler, fan or pump change
• the load that reliably triggers the crash

That list does not convict anything. It gives you reversible comparisons after the record picks a branch.

Read Parameter 1 and the error record in WinDbg

Open the matching dump in WinDbg. Microsoft’s dump-opening guide documents the File > Open crash dump flow. Its documented first-pass command is:

!analyze -v

Find the WHEA_UNCORRECTABLE_ERROR (124) section and its arguments. Keep the full values for Arg1 and Arg2. Then pass the second value to Microsoft’s WHEA record extension:

!errrec <Arg2 value>

For example, if Arg2 is ffffa10b12345028, the command is !errrec ffffa10b12345028. Do not copy that example address into your own analysis; use the address printed by your dump.

The !errrec reference says the command displays the contents of the WHEA error record. Save the output with the dump. Start with the notification or source type, severity and record-section headings.

If !errrec cannot read the record from a small dump, keep that dump rather than treating the failed command as a diagnosis. For a future crash, use System Properties > Advanced > Startup and Recovery > Settings to choose Automatic memory dump or Kernel memory dump. Microsoft’s system-failure and recovery reference documents both options and their paging-file requirements. A later, larger dump may retain the needed record; it is not guaranteed to make every record readable.

Parameter 1 picks the branch, not the replacement part

Microsoft’s table defines these useful routes:

The restraint in the machine-check row is deliberate. Microsoft’s hardware-error source documentation says one processor machine-check source can report processor, cache, memory and system-bus errors. “Processor” in the source line therefore does not, by itself, prove a failed processor.

The record can contain processor, platform-memory, PCIe, bus, device, NMI or generic sections. Microsoft’s error-record documentation defines those section families. Treat a section as a routing clue. A single filename, vendor string or bus label is not a purchase order.

Put deliberate tuning back to default

Microsoft lists heat, defective hardware, memory and a processor beginning to fail among 0x124 possibilities. It specifically says to disable overclocking, confirm cooling works and run memory diagnostics.

If you changed a clock, voltage, power limit or memory profile, record the current value and restore only those deliberate changes to their documented defaults. Test the same workload again before making a second change. One change at a time is what tells you whether stability returned.

Entering UEFI settings is also the point to make sure you can retrieve the device’s BitLocker recovery key. Microsoft says a security or hardware change can cause a recovery prompt, and it cannot recreate a lost key. Use its recovery-key instructions before the firmware-settings step. Do not change TPM or Secure Boot settings as part of this diagnosis.

This step tests configuration stability. It does not prove a component is healthy or defective. If the crash continues at defaults, keep the defaults while you isolate the branch.

Follow the record’s branch

Machine-check or processor section

Start with cooling and settings because they are reversible. Confirm that the fans or pump operate and compare CPU temperature under the triggering load with the processor maker’s limit. The CPU overheating guide covers the temperature and cooler checks without turning a hot reading into an automatic replacement.

If the record points toward memory or the crash began with a memory-profile change, use the MEMORY_MANAGEMENT test sequence: default memory speed first, then a real memory test, then one-stick isolation if the test reports errors. A machine check can include memory and bus faults, so this is evidence-led isolation rather than a claim that 0x124 means bad RAM.

If cooling, defaults and memory isolation are clean, keep the dump and exact record output for the system or motherboard maker. A CPU swap is a late isolation test, not the interpretation of a vendor name in WinDbg.

PCIe section or Parameter 1 0x4

Record the exact PCIe section fields and compare them with what changed: a new GPU, storage adapter, add-in card, riser, slot or firmware revision. Power down before touching hardware and use the board and device maker’s service instructions for reseating or moving a device. Change one device or slot at a time, then repeat the same workload.

Do not assume every PCIe error is the graphics card. The bus also carries NVMe drives, network adapters and other devices. The record and the board’s slot map should narrow the path before isolation.

Generic, NMI or platform-specific section

Preserve the full record and use the exact computer or motherboard maker’s hardware diagnostics and firmware notes. These branches are where a generic “replace the CPU” answer is least defensible. The platform can add information that Windows’ generic source label does not explain.

What not to do first

• Do not reinstall Windows before reading the dump. It does not identify the hardware source and can discard the evidence window.
• Do not raise voltages to make the crash disappear. That changes the electrical conditions and creates a second variable.
• Do not replace the CPU because WinDbg prints a processor vendor string. A machine-check source can cover cache, memory and system bus errors too.
• Do not treat every WHEA-Logger warning as a fatal crash. Preserve the corrected event and compare timestamps, but keep its severity distinct.
• Do not buy several parts at once. A pile of simultaneous swaps can hide which comparison mattered.

Microsoft Support’s consumer WHEA fix page also recommends Windows and driver updates, recovery options after a recent change, and general blue-screen troubleshooting. Apply an update or rollback when the timing and record point at that device or change. The WHEA record is what keeps that step targeted.

The stopping rule

Escalate with the dump, !analyze -v output, !errrec output, settings history and isolation result together. Replace a component when the error follows that component or a manufacturer diagnostic condemns it, not because the stop code’s name sounded like a CPU failure.

If the dump is missing or unreadable, keep the system at documented defaults and configure the next dump. The next reproducible crash with a preserved record is more useful than a guess made from the blue screen alone.

Sources

• Microsoft Learn: Bug Check 0x124 WHEA_UNCORRECTABLE_ERROR
• Microsoft Learn: Hardware Errors and Error Sources
• Microsoft Learn: WHEA Error Records
• Microsoft Learn: WHEA Error Processing
• Microsoft Learn: !errrec in WinDbg
• Microsoft Learn: Read Small Memory Dump Files
• Microsoft Learn: Configure System Failure and Recovery Options
• Microsoft Learn: Open a Dump File with WinDbg
• Microsoft Support: How to Fix WHEA_UNCORRECTABLE_ERROR
• Microsoft Support: Find Your BitLocker Recovery Key