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

> 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 on**

- Build: 26300.9457 / 26100.33650
- Edition: Pro (26H2) / Server
- Architecture: x64
- Evidence: E1
- Verified: 2026-10-29

## 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

```text
!analyze -v
```

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

```text
!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

```powershell
# 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.

> **Danger: A machine that blue-screens under load may be damaging data**
>
> Every unexpected shutdown risks corrupting the filesystem and any open files. Back up before you start "one more test", especially if the machine holds the only copy.

## 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.

## Related

- [WHEA evidence chain](https://windows.homes/en/hardware/diag/whea-bugcheck/)
- [Memory diagnostics](https://windows.homes/en/hardware/ram/diagnostics/)
- [PSU sizing](https://windows.homes/en/hardware/build/psu/)

## 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.

## Sources

- [Microsoft Learn — Bug check code reference](https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/bug-check-code-reference2)
- [Microsoft Learn — WHEA reference](https://learn.microsoft.com/en-us/windows-hardware/drivers/whea/)
- [Microsoft Learn — Debugging tools for Windows](https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/)

---

Source: https://windows.homes/en/hardware/diag/bsod-hardware/