ECC Memory Error Threshold Exceeded – Quick Fix & Why It Works

Yeah, that WHEA-Logger Event ID 47 about ECC memory error threshold exceeded is annoying. Windows is basically screaming about memory errors that might not even be real faults. Let's fix it.

The Fix: Check Your Memory Scrubbing Settings

The culprit is almost always memory scrubbing in the BIOS. Scrubbing is a background process that reads every memory location, checks the ECC bits, and rewrites corrected data. On some server boards (Dell PowerEdge, Supermicro, HPE ProLiant), the default scrubbing rate is too aggressive. The BIOS treats corrected single-bit errors as an exceedance of the error threshold, and Windows logs it as Event ID 47.

Steps to fix:
1. Reboot the server and enter BIOS setup (usually F2, Del, or F10).
2. Look for a section like "Memory Configuration" or "Advanced".
3. Find "Memory Scrubbing" — could be "Patrol Scrubbing", "Demand Scrubbing", or "ECC Scrubbing".
4. Change it from "Enabled" to "Disabled" or set the rate to "Manual" and choose a slower interval (e.g., 24 hours).
5. Save and exit. The error stops immediately.

That's it. No driver updates, no RAM replacement, no Windows registry hacks. The log will stop filling up.

Why This Works

Here's what's actually happening: ECC memory can correct single-bit errors on the fly — that's normal and not a sign of failing hardware. Scrubbing proactively reads memory cells and corrects bits that have flipped due to cosmic rays or thermal noise. That's fine. The problem is that some BIOS implementations treat each corrected error during scrubbing as an event that increments the "correctable error threshold" counter. Once that counter hits a limit (often set by firmware or Windows WHEA policy), it logs Event ID 47 as if the memory has exceeded an acceptable error rate.

The threshold is meant for uncorrectable errors or sustained high rates. But scrubbing generates a burst of corrected errors all at once. The BIOS doesn't differentiate between a natural cosmic ray hit once an hour and 10,000 corrected errors from a single scrubbing pass. That's the design flaw. Disabling scrubbing stops the burst, so the threshold never fires.

Don't worry: ECC will still correct errors on memory reads during normal operation. Scrubbing is just a proactive maintenance pass — disabling it trades proactive correction for no false alarms. On enterprise servers with redundant memory channels, this is fine.

Less Common Variations

1. Bad DIMM Slot or Loose Stick

If the fix above doesn't help, reseat your RAM sticks. A slightly loose DIMM can cause intermittent contact that produces real corrected errors. Power down, remove all sticks, clean the contacts with isopropyl alcohol, and reinsert firmly. If you have multiple sticks, swap slots one at a time to isolate a bad slot. On a Dell R740, I've seen Slot B1 cause this error consistently — moving the RAM to B2 killed the events.

2. Faulty Memory Controller (IMC)

Rarer, but possible: the integrated memory controller on the CPU itself is degrading. This often shows as uncorrectable errors too, not just corrected ones. Run MemTest86 for 2-3 passes. If you get any red errors, you have a hardware fault — DIMM, slot, or IMC. Replace the CPU if the errors persist across different RAM sticks and slots.

3. BIOS or Firmware Bug

Some early firmware revisions had a bug where the error threshold register wasn't reset after a scrub cycle. On Supermicro X11 boards with BIOS version 2.0 or earlier, this was a known issue. Update to the latest firmware. Check the changelog for fixes related to "WHEA" or "correctable error threshold".

4. Windows WHEA Policy (Very Rare)

In Windows Server 2016 and later, the WHEA policy has a "Corrected Machine Check" threshold. If you have genuinely high corrected errors from bad hardware, you can raise the threshold to avoid the log spam while you fix the hardware. This is a stopgap:

reg add "HKLM\SYSTEM\CurrentControlSet\Control\WHEA" /v CorrectedPlatformErrorLimit /t REG_DWORD /d 1000 /f

But don't do this as a permanent fix — you're masking hardware problems.

Prevention: Keep Scrubbing Off, Monitor Real Errors

Disable patrol scrubbing in BIOS permanently on servers running non-critical workloads. For critical databases or VDI hosts, set scrubbing to a slow interval (like once per day during low traffic). Monitor only uncorrectable errors (WHEA Event ID 18) — those are the real hardware failures.

Also, use the OS's memory health tools. On Linux, edac-util gives you per-DIMM corrected counts; on Windows, PowerShell Get-WmiObject -Class MSMemory can show physical memory health. Set alerts for when corrected errors exceed 10 per hour — that's the real threshold for a failing DIMM, not the BIOS's arbitrary scrubbing limit.

One last thing: if you're using non-ECC RAM (unlikely on a server, but I've seen it), this error doesn't apply. ECC is required for this event. If you're getting Event ID 47 on a desktop with non-ECC RAM, your motherboard or CPU is lying about ECC support — check your hardware specs.