⚠ CrashDecoder

WHEA-Logger 47 A corrected hardware error has occurred - Memory

Memory reported an error and it was corrected before anything was lost. What makes this event frustrating is that the message body shows you almost nothing - two lines, neither of them actionable. Everything worth knowing, including which physical memory module reported it, is in the event's structured data, which Event Viewer hides behind a tab nobody clicks.

Updated 2026-07-28Warning - corrected, machine keeps runningAlso written: WHEA-Logger Event ID 47, whea logger event 47, corrected memory error, whea memory error

What you are looking at

In Event Viewer the matching entries look like this:

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

A corrected hardware error has occurred.

Component: Memory
Error Source: Corrected Machine Check

The details view of this entry contains further information.

What the error actually means

Systems with error-correcting memory detect and repair single-bit errors as a matter of routine. The correction happens in hardware, the data is right, and execution continues. Event 47 is the record that it happened.

Its uncorrected twin is Event 46 - identical layout, but the error could not be fixed. That one is associated with bugcheck 0x124. Event 47 never crashes anything.

The message deliberately shows you almost nothing

Event 47's message renders exactly two fields: Component and Error Source. But the event itself carries the physical address, the DIMM's node, card, module, bank, rank, row, column and bit position, the error type, and a field-replaceable-unit identifier.

None of that appears on the General tab. This is the single reason most pages about Event 47 are thin - they describe what the message says rather than what the event contains. Click Details, and use the PowerShell below.

Reading the parameters

Present in the event's structured data, absent from the message. These are what make the event useful.

ParameterWhat it holds
ErrorTypeWhat kind of memory error. 2 Single-Bit ECC is the overwhelmingly common value on a healthy-ish system. 3 Multi-Bit ECC is more serious. Others include 4 Single-Symbol ChipKill, 5 Multi-Symbol ChipKill, 8 Parity Error, 10 Invalid Address, 11 Broken Mirror, 12 Memory Sparing Error.
Card / Module / Bank / RankNumberThe physical location. These are what identify which DIMM reported the error, and they are the reason to look at the structured data at all. Consistent values across events mean one module.
PhysicalAddressThe physical memory address involved. Repeated errors at the same address are a much stronger signal than the same count spread randomly.
Row / Column / BitPositionLocation within the memory device. Rarely actionable for an end user, but it is what a vendor's failure analysis would want.
FRUId / FRUTextField-replaceable-unit identifier and text. On server hardware this often names the slot directly - which is exactly what you want before opening the machine.
Error SourceUsually 1, "Corrected Machine Check". Note this numbering is the event provider's own and does not match bugcheck 0x124's parameter 1.

What actually triggers it

On systems with ECC memory the interpretation is well understood. On consumer hardware it is considerably less clear - see the FAQ.

CauseHow oftenDetail
A memory module beginning to degradeCommonThe standard interpretation on ECC systems, and what server vendors document it as. A rising corrected-error count on one module is the classic signature of a DIMM on its way out.
Unstable memory profileCommonXMP or EXPO beyond what the memory controller sustains produces correctable errors long before it produces obvious instability. Test at stock before concluding the module is faulty.
Marginal memory controller or boardOccasionalThe fault can sit in the controller or the traces rather than the module. Distinguished by whether the errors follow the module when you move it to a different slot.
Thermal or power marginalityOccasionalMemory running hot, or a supply that dips under load, produces correctable errors at a rate that rises with temperature.
Cosmic-ray-style single-event upsetsRareGenuinely real, genuinely rare, and the reason a truly isolated single-bit correction over a long period is not evidence of anything. It is also the explanation people reach for far too readily when the rate is clearly climbing.

Narrowing it down

Get at the structured data first - without it you cannot tell one bad module from a general problem.

Extract the physical location

The message will not give you this. The XML will:

Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Microsoft-Windows-WHEA-Logger'; Id=46,47} -EA SilentlyContinue |
  ForEach-Object {
    $x = [xml]$_.ToXml(); $d = @{}
    $x.Event.EventData.Data | ForEach-Object { $d[$_.Name] = $_.'#text' }
    [pscustomobject]@{
      Time = $_.TimeCreated; Id = $_.Id
      Type = $d.ErrorType; Card = $d.Card; Module = $d.Module
      Bank = $d.Bank; Rank = $d.RankNumber
      PhysAddr = $d.PhysicalAddress; FRU = $d.FRUText
    }
  } | Format-Table -AutoSize
What it tells you

Consistent Card, Module and Rank values across events identify one physical DIMM. Values that vary point at the controller, the board, or a memory profile that is too aggressive for all of them.

Check the rate and the trend

Count by day:

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

An isolated correction over months is not evidence of a fault. A count that climbs is. Windows itself uses a threshold-based approach here - its predictive failure analysis retires memory pages after a configured number of errors in a window, which tells you Microsoft treats accumulation rather than occurrence as the signal.

Test at stock before blaming the module

Disable XMP or EXPO and run MemTest86 from USB for at least four passes. See the memory testing guide - and note the distinction it draws between testing for a defective module and testing whether your settings are achievable.

What it tells you

Errors at stock mean a genuinely defective module. Clean at stock but errors with the profile enabled means the modules are fine and the profile is not - which costs nothing to fix and does not require buying anything.

Check whether Event 46 has appeared

Look for the uncorrected twin in the same log.

What it tells you

Event 47 escalating into Event 46 means corrections stopped being sufficient. That progression is the strongest evidence available for a warranty claim, and it is the point at which this stops being something to monitor.

Fixes, cheapest first

Cheapest and most reversible first.

  1. Return memory to stock settings

    Effort: 10 minutes · Risk: Low

    Disable XMP, EXPO and any manual timings in UEFI. Run for several days and recount the events.

    If they stop, the modules were never the problem - the profile was asking for more than your particular controller and board can deliver. Loosen the primary timings a step or accept a lower speed.

  2. Identify and test the individual module

    Effort: Overnight per module · Risk: None

    Use the Card and Module values from the triage step to work out which physical slot is reporting, then confirm by testing.

    1. Power down fully and unplug at the wall.
    2. Remove all modules except the suspected one, in the same slot each time.
    3. Run MemTest86 for at least four passes.
    4. Repeat with each module in that same slot, so you separate a bad module from a bad slot.
    Watch out

    Memory is usually sold in matched kits. If one module is faulty and under warranty, claim the kit rather than the single stick - mixing a replacement into a kit frequently reintroduces instability.

  3. Move the module to a different slot

    Effort: 20 minutes · Risk: Low

    The cleanest discriminator available. If the errors follow the module, the module is at fault. If they stay with the slot, the board or the memory controller is - and replacing memory would have achieved nothing.

  4. Check memory temperature and airflow

    Effort: 1 hour · Risk: Low

    Log memory temperatures under sustained load if your platform reports them. High-density modules in a poorly ventilated case produce correctable errors at a rate that climbs with temperature, and the fix is airflow rather than replacement.

When it is the hardware, not Windows

Signals that a module genuinely needs replacing:

Memory is one of the few components you can test conclusively at home and, if faulty, one of the cheapest to replace - and it usually carries a long or lifetime warranty that manufacturers honour on a MemTest86 error report. That makes this a comparatively good problem to have. Photograph the error screen, note the module, and claim.

Frequently asked

I have Event 47 but my RAM is not ECC. How is anything being corrected?

Honest answer: this is not well established, and anyone giving you a confident mechanism is probably guessing.

Event 47 is architecturally a corrected-memory-error report, and correction is what ECC does. Reports of it on consumer non-ECC systems exist, but I have not found a credible published explanation of what is doing the correcting - candidates include on-die ECC in DDR5, which is a different thing from ECC memory and is not usually reported to the operating system, and firmware-level reporting paths.

What to do about it is clearer than what causes it: test the memory at stock settings, and treat a rising rate as a problem regardless of the mechanism.

How many corrected memory errors are too many?

There is no published consumer figure, but Windows itself implements a threshold. Its predictive failure analysis retires memory pages after a configured number of errors within a time window - the defaults sit in the region of a couple of dozen errors per day per page before a page is taken out of service.

That is not a rule for when to replace a DIMM, but it does tell you how Microsoft thinks about it: accumulation within a window, not any single occurrence. Apply the same logic. One is nothing. A dozen a day is something.

What is the difference between Event 46 and Event 47?

Correction. They use identical templates and identical field lists. Event 47 is corrected - the error was fixed and nothing was lost. Event 46 is uncorrected, and it is the one associated with bugcheck 0x124. Seeing 47s accumulate and then a 46 appear is the full degradation curve in one log.

Why does the event say so little?

Because the message template only renders two of its twenty-five fields. It is a limitation of the message text, not of the event - the physical address, DIMM location, error type and everything else are all present, just not displayed.

Use the Details tab, or the PowerShell in the triage section above. This is the main reason pages about Event 47 elsewhere tend to be a paragraph long.