# WHEA and bugchecks: building a hardware evidence chain

> Which event IDs and bugcheck codes point at hardware, how to read them together, and what to collect before an RMA.

**Tested on**

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

## The short answer

Hardware problems leave evidence in three places, and you need all three:

1. **WHEA-Logger** events — firmware/CPU reported hardware errors.
2. **Bugcheck codes** — how Windows died, and the first parameter.
3. **Crash dumps** — the only place that shows *which* component was involved.

A bugcheck alone is a symptom. A WHEA event alone may be a corrected error. Together they are a case.

## Collect the evidence

```powershell
# 1. hardware errors
Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Microsoft-Windows-WHEA-Logger'} -MaxEvents 50 |
  Select-Object TimeCreated,Id,LevelDisplayName,Message | Format-List

# 2. unexpected shutdowns / bugchecks
Get-WinEvent -FilterHashtable @{LogName='System'; Id=1001,41,6008} -MaxEvents 50 |
  Select-Object TimeCreated,Id,ProviderName,Message

# 3. dump configuration
Get-CimInstance Win32_OSRecoveryConfiguration |
  Select-Object DebugInfoType,AutoReboot,DebugFilePath,MiniDumpDirectory
```

`DebugInfoType` tells you whether dumps are being written at all — a machine set to "no dump" destroys the evidence you need.

## WHEA event IDs worth knowing

| ID | Meaning | Action |
|---|---|---|
| 17 | corrected hardware error | track frequency; rising = failing component |
| 18 | corrected error, fatal? no — but repeated | investigate |
| 19 | corrected error (machine check) | check firmware/microcode first |
| 20 | uncorrected error | data may be corrupt |
| 46/47 | corrected/uncorrected PCIe or memory | isolate the device/slot |
| 1 | generic WHEA error record | read the message payload |

Exact payloads vary by platform; the **message** field names the component (cache, memory, PCIe, TLB). Read it, do not just count IDs.

## Bugcheck codes that usually mean hardware

| Code | Name | Typical cause |
|---|---|---|
| `0x124` | WHEA_UNCORRECTABLE_ERROR | CPU/memory/PCIe hardware, overheating, bad overclock |
| `0x9C` | MACHINE_CHECK_EXCEPTION | CPU-level fault |
| `0x101` | CLOCK_WATCHDOG_TIMEOUT | CPU stuck, power delivery, microcode |
| `0x1A` | MEMORY_MANAGEMENT | RAM (or a driver corrupting memory) |
| `0x50` | PAGE_FAULT_IN_NONPAGED_AREA | RAM, or a driver |
| `0x7A`/`0x7E` | disk/exception | storage or RAM |
| `0xEF` | CRITICAL_PROCESS_DIED | often storage or RAM corruption |

`0x124` with no overclock and a clean Windows install is a hardware conversation, not a software one.

## Read the dump, not just the code

```text
# with WinDbg (Debugging Tools for Windows)
!analyze -v
!errrec <WHEA_ERROR_RECORD address>
```

`!analyze -v` names the failing module and, for WHEA records, `!errrec` decodes the hardware error record: bank, type (cache/memory/PCIe), and whether it was corrected.

If you cannot install WinDbg, at minimum keep the `.dmp` files. They are the only artefact that lets someone else help.

> **Caution: Do not 「fix」 0x124 by reinstalling Windows**
>
> A clean install that still produces `0x124` proves the OS was not the cause. Reinstalling first destroys the dump evidence and costs a day. Collect dumps, check thermals and memory, then reinstall if you must.

## The order to investigate

1. **Firmware/microcode** — update BIOS/UEFI and check the CPU is supported.
2. **Thermals and power** — is it throttling or starving under load?
3. **Memory** — test modules individually, at stock settings.
4. **Storage** — SMART and filesystem errors can masquerade as memory faults.
5. **Drivers** — a driver can trigger WHEA via bad DMA; check the newest addition.
6. **Overclock** — XMP/EXPO off before anything else.

## What to hand to support

- WHEA events (time, ID, message).
- Bugcheck codes and dates.
- `.dmp` files or `!analyze -v` output.
- Configuration: CPU, RAM kit, BIOS version, overclock state.
- What you already changed and what happened.

## Related

- [Blue screens that mean hardware](https://winbook.fyi/en/hardware/diag/bsod-hardware/)
- [Memory diagnostics](https://winbook.fyi/en/hardware/ram/diagnostics/)
- [CPU support and microcode](https://winbook.fyi/en/hardware/cpu/support-microcode/)

## Lab boundary

E1. Event IDs and bugcheck meanings are documented by Microsoft. The lab cannot inject WHEA errors into a VM, so no dump was produced for this page.

## Sources

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

---

Source: https://winbook.fyi/en/hardware/diag/whea-bugcheck/