⚠ CrashDecoder

WHEA-Logger 19 A corrected hardware error has occurred - Processor Core

The processor detected a fault and corrected it before anything was lost. Nothing crashed and no data was harmed. This is the corrected twin of Event 18 - identical template, identical fields, differing only in severity - and the honest answer to whether it matters is that it depends on how many you have, and that experts disagree about where the line sits.

Updated 2026-07-28Warning - corrected, machine keeps runningAlso written: WHEA-Logger Event ID 19, whea logger event 19, corrected hardware error processor core, whea 19

What you are looking at

In Event Viewer the matching entries look like this:

Log Name:      System
Source:        Microsoft-Windows-WHEA-Logger
Event ID:      19
Level:         Warning

A corrected hardware error has occurred.

Reported by component: Processor Core
Error Source: Corrected Machine Check
Error Type: Cache Hierarchy Error
Processor APIC ID: 7

The details view of this entry contains further information.

What the error actually means

Processors correct errors constantly and silently. Caches carry error-correcting codes, and when a bit goes wrong in a way the code can fix, the hardware fixes it and carries on. Most of that never reaches the operating system at all.

Event 19 is what happens when the correction is reported rather than merely performed. Something went wrong, the hardware handled it, and Windows recorded that it happened.

So a single Event 19 is a report of a problem that was already solved. That is genuinely different from Event 18, where the hardware could not solve it. The diagnostic question is never "is this event bad" - it is how many, and is the number growing.

Structurally identical to Event 18

These two events use the same template, the same field list and the same Error Type map. The only difference is the first line of the message and the severity level. Everything on the Event 18 page about reading the fields applies here unchanged.

Reading the parameters

Three fields render in the message; the event carries seventeen. The Error Type is the one worth reading.

ParameterWhat it holds
Error TypeMost commonly 9 Cache Hierarchy Error, 8 Translation Lookaside Buffer Error, or 12 Internal parity error. The full map: 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 SourceUsually 1, rendering as "Corrected Machine Check". Remember that this numbering is the event provider's own and does not match bugcheck 0x124's parameter 1.
Processor APIC IDWhich logical processor reported it. The most useful field to track across events - a single ID recurring points at one physical core.
MCABankWhich machine check bank reported it. A consistent bank across events means a consistent subsystem within the processor.
MciStat / MciAddr / MciMiscRaw machine check register values for that bank. Record them if you escalate to a vendor; decoding needs the architecture manual.

What actually triggers it

Overwhelmingly about voltage and settings rather than a defective part.

CauseHow oftenDetail
Unstable overclock, undervolt or curve optimiserCommonThe dominant cause. AMD's Precision Boost Overdrive with negative curve optimiser offsets is a particularly frequent source - it is well known for passing extended stress tests while producing corrected errors during ordinary light use, because that is where single cores boost highest at lowest voltage.
Unstable memory profileCommonXMP and EXPO drive the memory controller, which sits on the processor die. A profile beyond what your specific controller sustains surfaces here rather than as an obvious memory error.
A known processor defectOccasionalIntel's 13th and 14th generation parts had a widely reported instability problem that generated large volumes of Events 18 and 19, addressed through microcode delivered in UEFI updates. Check firmware before concluding anything about your settings or your silicon.
Thermal or power delivery marginalityOccasionalA cooler past its best or a supply that dips under transient load. Produces corrected errors before it produces uncorrected ones.
A processor beginning to degradeOccasionalWhere a rising rate at stock settings eventually points. Corrected errors are the early stage of exactly this.

Narrowing it down

The single event tells you nothing. The distribution over time tells you almost everything.

Count them and plot them

Get the shape before anything else:

Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Microsoft-Windows-WHEA-Logger'} |
  Group-Object Id | Sort-Object Count -Descending |
  Format-Table Name, Count -AutoSize

Then by day, to see the trend:

Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Microsoft-Windows-WHEA-Logger'; Id=19} |
  Group-Object { $_.TimeCreated.ToString('yyyy-MM-dd') } |
  Sort-Object Name | Format-Table Name, Count -AutoSize
What it tells you

A handful spread over months is background. Dozens per day, or a count that climbs week over week, is a machine telling you something. The trend matters far more than the absolute number.

Check whether one core is responsible

Pull the APIC ID from the structured data:

Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Microsoft-Windows-WHEA-Logger'; Id=19} |
  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 }
  } | Group-Object Apic | Format-Table Name, Count -AutoSize
What it tells you

All events on one APIC ID points at a specific weak core - directly relevant if your platform supports per-core tuning, and useful evidence if the part is under warranty. Spread across many cores points at something system-wide: memory, power delivery or firmware.

Return everything to stock

Load optimised defaults, then check individually: XMP and EXPO off, no multiplier or voltage offset, PBO and curve optimiser disabled, no undervolt. Uninstall vendor tuning software rather than disabling it, since it can reapply settings at Windows startup.

What it tells you

If the events stop, your settings were the cause and the silicon is fine. This is the most common resolution by a wide margin.

Watch for escalation to Event 18

Check whether any uncorrected errors have appeared alongside the corrected ones.

What it tells you

Corrected errors escalating into Event 18 is the clearest degradation signal available at this level. It is also the strongest thing to bring to a warranty conversation, because it documents a trend rather than an incident.

Fixes, cheapest first

Stock settings first. On a machine that has never been tuned, go straight to firmware.

  1. Clear all overclocking and undervolting

    Effort: 10 minutes · Risk: Low

    Load optimised defaults and verify each item separately - defaults do not always clear everything, and vendor software can reapply an undervolt after boot.

    Run at stock for several days. If the events stop, reintroduce settings one at a time to find which one was responsible, and expect to need slightly more voltage than you did a year ago.

  2. Update firmware

    Effort: 45 minutes · Risk: Medium

    Check the board vendor's changelog for microcode, stability or AGESA entries. On recent Intel platforms in particular this has been the actual fix rather than a formality.

    Watch out

    If 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 -status and save your key from account.microsoft.com/devices/recoverykey first.

    Run the update on mains power and do not interrupt it.

  3. Test memory at stock

    Effort: Overnight · Risk: None

    With profiles disabled, run MemTest86 from USB for at least four passes. The memory controller lives on the processor, so the two are not cleanly separable. See the memory testing guide.

  4. Check cooling

    Effort: 1-2 hours · Risk: Low

    Clear dust, confirm fans spin, and log temperatures under sustained load. Marginal cooling produces corrected errors well before it produces anything dramatic.

When it is the hardware, not Windows

Signals that the processor is degrading rather than merely mis-set:

Corrected errors are the early-warning stage of the same fault that eventually produces uncorrected ones. That makes this the useful moment to document what is happening - export the events, note the dates, and keep the record. A support conversation backed by a rising corrected-error count over several months goes very differently from one that starts after the machine has already begun crashing.

Frequently asked

Is a small number of Event 19s normal?

This is genuinely contested, and it would be dishonest to give you a confident number.

One position: corrected machine checks are what error correction is for, a handful over months is the system working as designed, and reacting to them is superstition. The other: any corrected machine check on a stock consumer system indicates something marginal, because most correction never surfaces as an event at all.

Both are held by credible people and neither is settled by documentation. What everyone agrees on is the trend: a stable low background rate is not worth acting on, and a rising rate is - regardless of where you think the baseline sits.

Will Event 19 crash my computer?

No. Corrected means the hardware fixed it and execution continued. Event 19 never causes a bugcheck.

What it can do is precede one. If the same underlying weakness eventually produces an error the hardware cannot correct, that arrives as Event 18 or bugcheck 0x124.

My machine is completely stock and I still get these.

Then check firmware before anything else - particularly on recent Intel platforms, where a manufacturing-level instability problem produced exactly this pattern on stock systems and was addressed through microcode updates delivered in UEFI.

After that, test memory at stock, check temperatures, and consider the power supply. If all of those are clean and the rate is rising, you have a documentable hardware case.

Where do the Error Type values on this page come from?

Windows renders these events from a provider manifest compiled into whealogr.dll. You can dump it yourself rather than trusting anyone's transcription:

wevtutil gp Microsoft-Windows-WHEA-Logger /ge /gm:true

Microsoft does not publish these values as documentation, which is why the versions circulating elsewhere tend to disagree with each other.