WHEA_UNCORRECTABLE_ERROR 0x00000124 – diagnosing a real hardware fault

Fix it now

0x00000124 is a fatal hardware error reported through the Windows Hardware Error Architecture. Parameter 1 says which error source raised it and parameter 2 is the address of the error record, which is the only thing that tells you what actually failed.

wevtutil qe System /c:40 /rd:true /f:text

1. Read the System log around the crash. Hardware error entries logged before the bug check name the component far more usefully than the stop screen does, and Microsoft’s own resolution list starts with checking Event Viewer.
2. Undo any overclock, including memory profiles and any board-level automatic tuning. Microsoft names over-clocking in the cause list for this code.
3. Check that cooling is working: fans spinning, heatsink seated, vents clear, and the machine not thermally throttling under load.
4. Get parameter 1 from the BugCheck event or the dump. 0x0 is a machine check exception, 0x3 an NMI, 0x4 an uncorrectable PCI Express error, 0x10 a device driver error source – and each sends you somewhere different.
5. Update the system firmware and the chipset package from the machine or board vendor, then re-test.
6. Run the hardware diagnostics the system manufacturer supplies, and Windows Memory Diagnostics on top of them.

If you have the dump open in WinDbg, !errrec against parameter 2 decodes the WHEA error record, which names the component far more precisely than anything on the stop screen.

If the machine is stable with the overclock removed and firmware current, stop here. The next section covers reading the error source and the codes that look like this one but are not.

Why it happens

The Windows Hardware Error Architecture is the path by which platform hardware reports errors to the operating system. Processors, memory controllers, PCI Express root ports and platform error sources all feed into it. Correctable errors are logged and life goes on. When an error arrives that cannot be corrected and cannot be contained, Windows bug checks with 0x00000124 and records what it was told.

That recording is the point. Parameter 2 is the address of a WHEA_ERROR_RECORD structure, and !errrec on it in the debugger produces the specific error: which processor bank, which memory address, which PCI Express device. Without it you are guessing which component to swap, which is why this code produces so much fruitless hardware replacement.

Parameter 1 identifies the error source and narrows the field before you even open the dump. 0x0 is a machine check exception and 0x1 a corrected one; 0x2 a corrected platform error; 0x3 a non-maskable interrupt; 0x4 an uncorrectable PCI Express error; 0x5 a generic hardware error; 0x6 an initialisation error; 0x7 a BOOT error; 0x10 a device driver error source; 0x11 and 0x12 Arm synchronous external abort and SError interrupt. A 0x4 sends you to an add-in card or a riser; a 0x0 sends you to the processor, memory or the path between them.

Microsoft’s cause list is heat, defective hardware, memory or a processor beginning to fail, and over-clocking – and then, explicitly, ‘less likely, but possible: a driver is causing the hardware to fail with this bug check’. That last line matters. It is not true that software cannot cause this, and a machine that only produces 0x124 under one workload with one device attached is worth investigating as a driver problem before it is stripped for parts.

Full reference

Parameter 1: the error source types

Debugger commands for a WHEA dump

The codes that arrive with this one

0x00000122 points at software, not silicon

This one is worth separating out. WHEA_INTERNAL_ERROR is an error inside the error-handling machinery, and Microsoft attributes it to a bug in a vendor-supplied PSHED plug-in, or to the firmware’s implementation of error records or error injection. So a 0x122 is a reason to update firmware and platform software, not to start pulling memory. Getting this the wrong way round wastes a lot of parts.

0x0000009C is not simply the old version of 0x124

It was replaced by 0x124 from Windows Vista onwards, but it is still issued on current Windows in two documented circumstances: when WHEA is not fully initialised, and when all the processors that rendezvous have no errors in their registers. Both mean the machine could not produce a usable error record, which is itself information – it usually points at the very earliest part of start-up, or at firmware.

When the evidence runs out

• Read the WHEA-Logger entries in the System log across the whole period, not just the crash. Corrected errors accumulate before an uncorrectable one arrives.
• Test with the minimum viable hardware: one memory module, no add-in cards, integrated graphics if the platform has it.
• Swap the power supply if you have a known-good one. It is not in Microsoft’s cause list, but an unstable rail produces symptoms that read as processor and memory faults.
• Try a clean current build of Windows on a spare disk. If it crashes there too, software is ruled out cheaply.
• Where parameter 1 is 0x10, treat it as a driver problem and work the driver rather than the hardware.

Microsoft’s advice for 0x00000080 is short and worth following literally: remove any hardware or drivers that were recently installed, and make sure all memory modules are of the same type. There are no parameters to read on that code, and it says so.

Every code this article covers

Confirm the fix worked

1. Firmware is at stock settings with no memory profile enabled, and the machine has completed a sustained load test.
2. The WHEA-Logger source in the System log records no new errors over several days.
3. Windows Memory Diagnostics and the manufacturer’s own diagnostics both pass.
4. System firmware and chipset drivers are at the versions currently published for that model.
5. If a component was replaced, the decoded error record no longer names it.

Questions people ask about this