0x124, 0x9C and 0x101: when a blue screen means hardware

Verified 2026-10-292 min read

Distinguish the bugchecks that point at CPU, memory or power delivery from ones that point at drivers, and run the checks in the right order.

Tested onPro (26H2) / Server · Build 26300.9457 / 26100.33650 · x64

Build: 26300.9457 / 26100.33650
Edition: Pro (26H2) / Server
Architecture: x64
Support: Documentation (E1)
Evidence: E1Official documentation
Verified: 2026-10-29
Page type: Troubleshoot

The short answer

Three bugchecks are worth learning because they change what you do next:

Code	Meaning	First suspect
`0x124`	WHEA_UNCORRECTABLE_ERROR	CPU, memory, PCIe, thermals
`0x9C`	MACHINE_CHECK_EXCEPTION	CPU-level fault, power delivery
`0x101`	CLOCK_WATCHDOG_TIMEOUT	CPU stuck, microcode, power

Everything else (0x1A, 0x50, 0x3B, 0x7E) can be hardware, but is more often memory stability or a driver.

The distinction matters because the wrong first move costs days: reinstalling Windows on a machine with a failing CPU changes nothing, and replacing a CPU on a machine with a bad driver changes nothing either.

Step 1: stop the obvious variables

Before analysing anything:

Turn off XMP/EXPO and any overclock (CPU, GPU, memory).
Update firmware/microcode — a supported CPU with current microcode is the baseline.
Check temperatures under load; a 0x101 on a hot machine is a cooling problem.
Remove recent hardware — a new PCIe card, a second RAM kit, a dock.

If the machine becomes stable, you have your answer without reading a single dump.

Step 2: read the dump properly

!analyze -v

For 0x124, !analyze -v usually points at a WHEA error record; decode it:

!errrec <address>

The record tells you the bank and type (cache, memory, PCIe, TLB) and whether it was corrected. That is what turns “a blue screen” into “a CPU cache error” or “a PCIe link error”.

Bugcheck parameters also carry information:

0x124 parameter 1: error source (machine check / corrected platform error …);
0x9C parameter 1: 0 = machine check, 1 = corrected machine check, etc.;
0x101 parameters: the processor that timed out.

Read the parameter meanings in the bug check reference rather than guessing.

Step 3: isolate the component

Evidence	Next test
WHEA names a memory bank	test/replace that module; check the slot
WHEA names a PCIe device	remove/reseat the card, check the slot and power
`0x101` on one core repeatedly	CPU or power delivery; check VRM temps
Errors only under sustained load	thermals, PSU, VRM
Errors at idle	memory, firmware, power saving states
Errors only with the GPU loaded	GPU, PSU transient, PCIe link

Step 4: the tests that actually discriminate

# sustained load + counters (run for 10+ minutes)
Get-Counter '\Processor Information(_Total)\% Processor Performance',
            '\Processor Information(_Total)\% of Maximum Frequency' -MaxSamples 30 -SampleInterval 10

# hardware error log
Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Microsoft-Windows-WHEA-Logger'} -MaxEvents 50 |
  Select-Object TimeCreated,Id,Message | Format-List

Memory: several full passes, one module at a time, stock settings.
Storage: SMART and filesystem scan — a failing SSD produces 0x7A/0x7E and corrupts pages.
PSU: reduce load (one GPU, fewer drives) and repeat the workload.
Thermals: clean the cooler, replace paste, retest before buying parts.

When to stop testing and replace

0x124/0x9C at stock settings with updated firmware, on a clean install, and no dump-configuration excuse.
Errors that follow the CPU when moved to another board (if you can test that).
Memory errors that persist after replacing the module and the slot.
A pattern that appears within minutes under any load — that is a hardware fault, not a tuning problem.

Lab boundary

E1. Bugcheck semantics are Microsoft-documented. The lab cannot produce a machine check in a VM, so no dump analysis was performed here.