WHEA and bugchecks: building a hardware evidence chain

Verified 2026-10-292 min read

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

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

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

WHEA-Logger events — firmware/CPU reported hardware errors.
Bugcheck codes — how Windows died, and the first parameter.
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

# 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

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

The order to investigate

Firmware/microcode — update BIOS/UEFI and check the CPU is supported.
Thermals and power — is it throttling or starving under load?
Memory — test modules individually, at stock settings.
Storage — SMART and filesystem errors can masquerade as memory faults.
Drivers — a driver can trigger WHEA via bad DMA; check the newest addition.
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.

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.