Windows WHEA Hardware Errors Explained: Corrected, Fatal, CPU, Memory, and PCIe Evidence

Windows Hardware Error Architecture (WHEA) gives Windows a common framework for receiving, recording, and processing hardware error information reported by processors, platform firmware, chipsets, buses, and devices. Seeing WHEA in an event or crash record therefore tells you which reporting architecture carried the evidence; it does not automatically identify one replaceable component as defective.

Microsoft defines a hardware error source as hardware that alerts the operating system to an error condition. Examples include processor machine-check exceptions, chipset error signals, PCI Express root-port reporting, and I/O-device errors. One source can also report more than one kind of underlying fault.

Microsoft documents a distinct processing path for corrected hardware errors. The low-level handler verifies the condition, gathers error information, and creates a WHEA error packet/record. Because the condition was corrected, Windows can log evidence without treating every corrected event as an immediate fatal failure.

Repeated corrected errors can still be diagnostically useful, especially when they correlate with a specific workload, overclock or undervolt, memory configuration, PCIe device, firmware change, temperature condition, or physical link. The count alone does not prove which component is bad; preserve the detailed record and reproduce the circumstances before changing hardware.

A common mistake is to read a processor or machine-check source and conclude that the CPU itself must be defective. Microsoft notes that a processor machine-check exception can report processor, cache, memory, and system-bus errors. The reporting source and the physical root cause are related evidence, not necessarily the same object.

For that reason, diagnosis should combine the record's section type and fields with recent firmware or tuning changes, memory configuration, component topology, and reproducibility. Returning unsupported CPU, memory, or fabric tuning to documented defaults is a cleaner diagnostic step than assigning a failed part from the WHEA label alone.

PCI Express Advanced Error Reporting (AER) provides detailed PCIe error reporting. On Windows, Microsoft documents that the PCI bus driver discovers PCIe AER error sources, while the platform-specific hardware error driver discovers several other WHEA sources. A PCIe AER record can therefore carry link or transaction evidence, but WHEA as a whole is broader than PCIe.

When the record points to PCIe, inspect the reported source, severity, device or root-port context and the timing of the failure. Do not infer that the GPU is bad merely because it is the most visible PCIe device; NVMe drives, add-in cards, links, slots, risers, root ports, firmware and signal-integrity conditions can occupy the same diagnostic layer.

Microsoft's WHEA error-record format is based on the Common Platform Error Record model. A record contains a header plus one or more section descriptors and error sections. Supported section types include generic and architecture-specific processor information, memory-related information, PCIe information, and other platform data depending on the source.

That structure is why the useful question is not simply “Did Event Viewer say WHEA?” Preserve the event or dump, note the event time and workload, and inspect the detailed error record before resetting firmware, reinstalling Windows, or replacing parts.

First record the exact time, workload and symptom, then preserve the WHEA event or crash dump. Check whether the event is corrected or uncorrected and identify the reported source and record sections. Next correlate it with recent BIOS/UEFI changes, CPU or memory tuning, new hardware, driver or firmware updates, and the physical bus or memory topology involved.

If the system is tuned beyond documented defaults, reproduce at defaults before concluding that stock hardware is faulty. If a specific PCIe path is implicated, isolate the device, slot, riser or link methodically. If memory-related evidence repeats, test the memory configuration and supported settings without assuming that every memory-reported error originates in the DIMM itself. The goal is to narrow a reporting path into a reproducible fault boundary rather than turn a generic WHEA label into a guess.