WHEA-Logger 18 A fatal hardware error has occurred - Processor Core
The processor's own error detection found a fault it could not fix. This is the uncorrected counterpart of Event 19 - byte for byte the same event, differing only in severity - and it always concerns the processor core. Two things about it are widely misreported, and both change what you conclude.
What you are looking at
In Event Viewer the matching entries look like this:
Log Name: System
Source: Microsoft-Windows-WHEA-Logger
Event ID: 18
Level: Error
A fatal hardware error has occurred.
Reported by component: Processor Core
Error Source: Machine Check Exception
Error Type: Cache Hierarchy Error
Processor APIC ID: 0
The details view of this entry contains further information.What the error actually means
Processors carry error detection throughout - caches are parity-protected, interconnects are checked, memory paths are validated. When one of those mechanisms finds a fault it cannot correct, it raises a machine check exception, and Windows records what the processor reported.
"Reported by component: Processor Core" is not a variable. It is a fixed string in this event. Event 18 is always the processor core - AMD Northbridge errors are Events 20 and 21, memory is 46 and 47, PCI Express is 16 and 17. So the component line tells you nothing you did not already know from the event ID; the information is in the Error Type field.
Event 18 frequently appears with no stop error at all. When a fault kills the machine outright, the record is held in firmware and written to the log on the next boot - which is why these events often cluster at startup times rather than at the moment of failure.
So do not assume a missing bugcheck means the event was harmless. It can equally mean the machine died too hard to write one.
Reading the parameters
The message renders only three fields. Everything else is in the Details tab, and some of it is worth reading. The Error Type map below is the practically useful one.
| Parameter | What it holds |
|---|---|
| Error Type | What the processor actually detected. 9 Cache Hierarchy Error and 8 Translation Lookaside Buffer Error are the values you will most often see, along with 12 Internal parity error. Others: 0 No Error, 1 Unclassified, 2 Microcode ROM Parity, 3 External, 4 FRC, 5 Internal Timer, 6 Internal Unclassified, 7 Generic Cache Hierarchy, 10 Bus/Interconnect, 11 Memory Controller, 256 Unknown. |
| Error Source | Usually 3, rendering as "Machine Check Exception". See the warning below - this numbering is not the same as bugcheck 0x124's parameter 1, despite describing the same categories. |
| Processor APIC ID | Which logical processor reported it. Worth recording across several events: the same ID every time points at one physical core, which is meaningful evidence for a warranty conversation. |
| MCABank | Which machine check bank reported the fault. Different banks correspond to different parts of the processor, so a consistent bank number indicates a consistent subsystem. |
| MciStat / MciAddr / MciMisc | The raw IA32_MCi_STATUS, _ADDR and _MISC register values for that bank. Decoding them needs Intel's or AMD's architecture manual, but recording them costs nothing and vendor support may ask. |
| TransactionType, Participation, RequestType, MemorIO, MemHierarchyLvl, Timeout, OperationType | A decode of the machine check compound error code - what kind of operation was in flight when the fault hit. Present in the Details tab, absent from the message. A value of 256 renders as "N/A" throughout. |
What actually triggers it
The WHEA-Logger provider uses its own display map, and it diverges from the documented error-source enum that bugcheck 0x124 parameter 1 uses.
In an event, 3 means Machine Check Exception. In a 0x124 bugcheck, parameter 1 of 3 means a non-maskable interrupt. They agree on 1, 2, 4 and 7 and disagree on 0, 3, 5, 6 and 8. Do not carry a number across from one to the other.
What actually produces these:
| Cause | How often | Detail |
|---|---|---|
| Unstable overclock, undervolt or curve optimiser | Common | The leading cause on any tuned machine. Ryzen Precision Boost Overdrive with negative curve optimiser offsets is a particularly frequent source, as are Intel undervolts. Both are notorious for passing hours of stress testing and failing at light bursty loads. |
| Unstable memory profile | Common | XMP and EXPO push the memory controller, which lives on the processor die. A profile beyond what your controller sustains surfaces as processor-level machine checks rather than as obvious memory errors. |
| A known processor defect | Occasional | Worth checking before blaming your settings. Intel's 13th and 14th generation Raptor Lake parts had a widely reported instability problem that produced large volumes of Events 18 and 19, addressed through microcode updates delivered in UEFI. If you are on that platform, update firmware before concluding anything. |
| Thermal problems | Occasional | A cooler that has come loose, dried paste, or blocked airflow. Microsoft's guidance for the corresponding bugcheck names heat directly. |
| Power delivery | Occasional | A supply that cannot hold voltage under transient load, or board VRMs past their best. Produces machine checks when a core momentarily loses adequate voltage. |
| A genuinely failing processor | Occasional | Where you land when settings are stock, firmware is current, temperatures are fine and the power supply is good. Rare, but this is one of the few signals where it is a serious candidate. |
Narrowing it down
Read the Error Type and the APIC ID, then remove every tuning variable.
Pull the structured fields, not just the message
The message shows three fields; the event carries seventeen. This gets the useful ones:
Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Microsoft-Windows-WHEA-Logger'; Id=18} |
ForEach-Object {
$x = [xml]$_.ToXml(); $d = @{}
$x.Event.EventData.Data | ForEach-Object { $d[$_.Name] = $_.'#text' }
[pscustomobject]@{
Time = $_.TimeCreated; Apic = $d.ApicId; Bank = $d.MCABank
Type = $d.ErrorType; Src = $d.ErrorSource; MciStat = $d.MciStat
}
} | Format-Table -AutoSizeA consistent APIC ID and MCABank across events means one core and one subsystem - a coherent, documentable fault. Values that vary point at something system-wide: power delivery, memory, or thermals.
Return everything to stock
Load optimised defaults in UEFI, then check each item separately: XMP and EXPO off, no CPU multiplier or voltage offset, Precision Boost Overdrive and curve optimiser disabled, no undervolt. Uninstall vendor tuning software rather than just disabling it - Ryzen Master, Intel XTU and ThrottleStop can reapply settings at Windows startup.
If the events stop, the silicon was fine and the settings were not achievable on your particular sample. This resolves a large share of cases and costs nothing but a small amount of performance.
Check for a firmware fix before suspecting the part
Look at your board vendor's BIOS changelog for anything mentioning microcode, stability or AGESA. Note your processor generation while you are at it.
Microcode delivered through UEFI has genuinely resolved processor instability on specific steppings. On affected Intel generations this is the first thing to do, not the last.
Check whether Event 19 was building first
Count both severities over time:
Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Microsoft-Windows-WHEA-Logger'} |
Group-Object Id | Sort-Object Count -Descending |
Format-Table Name, Count -AutoSizeA history of corrected Event 19s escalating into an uncorrected Event 18 is the clearest degradation evidence available at this level, and it is the strongest thing you can bring to a warranty conversation.
Fixes, cheapest first
The first two resolve most cases and cost nothing.
Clear all overclocking and tuning
Load optimised defaults, then verify each setting individually since defaults do not always clear everything - and check Windows too, because vendor utilities can reapply an undervolt after boot.
Run at stock for several days before drawing conclusions. If stability returns, reintroduce one setting at a time.
Watch outAn overclock stable for years can stop being stable. Silicon ages, and the voltage a core needs for a given frequency drifts upward over time - so a long track record is not a reason to leave the setting untested.
Update firmware
Check the board vendor's changelog for microcode or stability entries. This matters more than usual on recent Intel platforms, where a known instability problem was fixed this way.
Watch outIf the drive is protected by BitLocker or Device Encryption, a firmware update can change TPM measurements and trigger a recovery-key prompt on the next boot. Check with
manage-bde -statusand save your key from account.microsoft.com/devices/recoverykey first - Windows 11 enables Device Encryption by default on much consumer hardware.Run the update on mains power and do not interrupt it.
Fix cooling
Clear dust from heatsinks, radiators and filters. Confirm every fan spins. Log package and per-core temperatures under sustained load with HWiNFO64.
On a machine more than a few years old, reseating the cooler with fresh thermal paste is cheap and frequently effective.
Test memory at stock
With profiles disabled, run MemTest86 from USB for at least four passes. The memory controller is part of the processor, so memory instability and processor machine checks are not cleanly separable. See the memory testing guide.
Rule out the power supply
Borrow a known-good supply with adequate headroom and run on it for a week if you can. As a cheaper diagnostic, cap CPU power limits in firmware - if the events stop at reduced power, the fault is in delivery rather than in the processor.
When it is the hardware, not Windows
Signals that the processor itself is at fault rather than its settings:
- Events continue at completely stock settings with current firmware and good temperatures.
- The same APIC ID and MCABank appear every time.
- Corrected Event 19s were accumulating before the first Event 18.
- 0x124 or 0x101 crashes appear in the same period.
- A clean Windows install makes no difference.
- The rate is increasing week over week.
Once stock settings, firmware, cooling and power are eliminated, this is a component replacement rather than a repair. Export the event history first - the combination of a consistent APIC ID, an escalating rate, and corrected errors preceding uncorrected ones is about as strong as consumer-level hardware evidence gets, and it survives a vendor diagnostic coming back clean.
Frequently asked
I have Event 18 but no blue screen. Did something actually go wrong?
Yes. Event 18 is an uncorrected error by definition - the hardware could not fix it. The absence of a stop code usually means the record was written from firmware storage on the next boot rather than by a running Windows, which happens when the machine dies too abruptly to write anything. Check whether the event timestamp coincides with a startup; if it does, that is what happened.
How is this different from Event 19?
Severity, and nothing else structurally - the two events use identical templates and identical field maps. Event 19 is corrected: the hardware detected a fault and fixed it, and the machine carried on. Event 18 is uncorrected: it could not. Practically, 19 is something to monitor and 18 is something to act on.
Does Event 18 mean I will get bugcheck 0x9C?
No, and the pairing is a common error. Bugcheck 0x9C fires specifically in circumstances where WHEA was not available to log anything - so 0x9C and a WHEA-Logger event essentially do not co-occur. The bugcheck that corresponds to Event 18 is 0x124.
Can I see exactly what the processor recorded?
Partially. The Details tab shows the decoded fields, and Event 18 also carries the complete raw error record in a RawData field. Decoding that properly needs a debugger - !errrec works on a memory address in a crash dump, not on an event log entry, so there is no simple supported path from one to the other. For most purposes the decoded Error Type, APIC ID and MCABank are what you need.
Where do these event definitions come from?
Windows renders these events from a provider manifest compiled into whealogr.dll, and you can dump it yourself rather than trusting anyone's transcription:
wevtutil gp Microsoft-Windows-WHEA-Logger /ge /gm:trueThat is where the Error Type values on this page come from. Microsoft does not publish them as documentation, which is why versions of this table circulating elsewhere tend to disagree with each other.
Related errors
- WHEA-Logger 19A corrected hardware error has occurred - Processor CoreThe CPU caught an error and corrected it. Whether to care depends on the rate.
- 0x00000124WHEA_UNCORRECTABLE_ERRORThe hardware reported a fatal error directly. The most hardware-specific stop code there is.
- WHEA-Logger 17A corrected hardware error has occurredHardware reported an error and recovered. One is noise. A burst of them is a warning.