⚠ CrashDecoder

0x0000012B FAULTY_HARDWARE_CORRUPTED_PAGE

Most stop codes name a symptom and leave you to work out whether software or hardware is behind it. This one is different. Windows found memory whose contents changed in a way that no correctly behaving software could have caused, and the name says what Microsoft concluded. In the most common form, a page that should have been all zeroes had exactly one bit set - a single-bit error, which is a hardware memory error. That makes this one of the most diagnostically valuable codes on this site.

Updated 2026-07-28Stop error - strongly indicates failing memoryAlso written: 0x12B, FAULTY HARDWARE CORRUPTED PAGE, faulty_hardware_corrupted_page, 0x0000012b

What you are looking at

:(

Your PC ran into a problem and needs to restart.

Stop code: FAULTY_HARDWARE_CORRUPTED_PAGE

In Event Viewer the matching entries look like this:

Log Name:      System
Source:        BugCheck
Event ID:      1001
Level:         Error

The computer has rebooted from a bugcheck.  The bugcheck was: 0x0000012b (0xffffa08e2c4d1000, 0x0000000000a3f21c, 0x0000000000000000, 0x0000000000000000).
Log Name:      System
Source:        Microsoft-Windows-WHEA-Logger
Event ID:      47
Level:         Warning

A corrected hardware error has occurred. Reported by component: Memory. Error Source: Corrected Machine Check.

What the error actually means

Windows keeps track of what memory should contain. When the memory manager finds a page whose contents contradict that record, and the discrepancy is of a kind that only direct physical access could produce, it raises this bugcheck. Microsoft's framing is exact: the corruption could only have been caused by a component accessing memory using physical addressing.

The classic case is a page the memory manager had zeroed and expected to still be zero, which now has a single bit set to 1. Nothing in normal operation flips one bit in a page nobody is using. Microsoft's own text is unambiguous about what that means: this error is a hardware memory error.

There is a second, less-known route to the same code, and it is worth knowing about because it changes what you are looking at. Windows compresses memory pages to save physical RAM, and the Compressed Store Manager verifies each page as it decompresses. If a page fails that check, this bugcheck is raised too - with a completely different set of parameters. Which of the two you are looking at is decided entirely by parameters 3 and 4.

Reading the parameters

This code has two different parameter tables, and reading the wrong one will mislead you completely. Check parameters 3 and 4 first: if both are zero, use the first table. If either is non-zero, use the second.

ParameterWhat it holds
3 and 4Read these first - they decide which table applies. Both zero means the memory manager found a single-bit error on a page it expected to be zeroed. Non-zero means the Compressed Store Manager failed to decompress a page. Everything below depends on this.
1Both 3 and 4 zero: the virtual address that maps to the corrupted page.
Otherwise: FailStatus - indicates the type of failure.
2Both 3 and 4 zero: the physical page number.
Otherwise: the CompressedSize of the page being read.
3Zero in the single-bit error case. Otherwise, the source buffer.
4Zero in the single-bit error case. Otherwise, the target buffer.

What actually triggers it

Microsoft states plainly that this bugcheck can only occur by memory corruption due to physical memory access, and gives three causes. This is a much narrower list than most stop codes carry, and the narrowness is the useful part.

CauseHow oftenDetail
Defective RAMCommonMicrosoft's first listed cause, and the one to assume until you have ruled it out. A module with a failing cell will flip bits, and the single-bit error form of this code is close to a direct readout of that happening.
Memory running beyond its stable limitsCommonNot separately listed by Microsoft, but it produces defective behaviour from physically sound modules. XMP and EXPO profiles are overclocks - they are not guaranteed stable on every board and CPU combination, and instability shows up exactly like a failing module. Always test at default speeds before condemning the RAM.
A driver or device performing an incorrect DMA operationOccasionalMicrosoft names this directly: a driver or device incorrectly modifying physical pages via an incorrect DMA operation or associated MDL. Direct memory access bypasses the memory manager entirely, so a driver that gets it wrong writes over pages Windows believes it owns. This is the one genuinely software-shaped cause.
Firmware corrupting memory across a power transitionOccasionalAlso named by Microsoft, and unusually specific - firmware illegally modifying physical pages across a power transition. If the crashes cluster around sleep, hibernate or resume rather than appearing at random, this moves sharply up the list.
A failing memory controllerRareThe controller lives on the CPU on modern systems. If several modules and several slots all produce errors, the fault may be upstream of the RAM itself.

Narrowing it down

Read parameters 3 and 4 before anything else - they split this into two quite different investigations.

Determine which failure you have

Find the bugcheck parameters in Event Viewer, Event ID 1001 from source BugCheck, or in the dump. Look at the third and fourth values.

Both zero: a single-bit error on a page expected to be zeroed. Either non-zero: a Compressed Store Manager decompression failure.

What it tells you

Both zero is the stronger and simpler signal - Microsoft calls it a hardware memory error outright, and you can go straight to testing RAM.

If it came from the store manager, note what that implies

There is a detail here that most write-ups miss, and it matters. Microsoft notes that the Compressed Store Manager can detect if the corruption was caused by a single-bit error and automatically corrects this condition without raising a bug check.

So a bugcheck from this path means the corruption was not a correctable single-bit error - it was something the store manager could not repair.

What it tells you

Counterintuitively, this form indicates worse corruption than the single-bit case, not a milder one. The store manager already silently fixes the mild version. Treat multi-bit corruption as urgent and stop trusting the machine with unbacked-up data.

Check whether XMP or EXPO is enabled

Before condemning any module, find out whether the RAM is running at its rated JEDEC speed or an enabled memory profile. Check in the firmware setup, or from Windows with:

Get-CimInstance Win32_PhysicalMemory |
  Select-Object Manufacturer, PartNumber, Capacity, Speed, ConfiguredClockSpeed
What it tells you

If ConfiguredClockSpeed is above the JEDEC default for your modules, a memory profile is active. That is an overclock, and it must be disabled before any test result means anything.

Look for WHEA memory events alongside

Check for WHEA-Logger Event 47 corrected memory errors, and Event 46 or 18 for uncorrected ones.

Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Microsoft-Windows-WHEA-Logger'} -MaxEvents 50 |
  Select-Object TimeCreated, Id, LevelDisplayName, Message | Format-List
What it tells you

Corrected memory errors in the log alongside this stop code is about as clear as hardware evidence gets - the platform and the memory manager independently reporting the same thing.

Fixes, cheapest first

Because the cause list is short and hardware-weighted, testing comes before fixing here. Do not skip the default-speed step - it is the most common reason a test result turns out to be meaningless.

  1. Return memory to default speed

    Effort: 15 minutes · Risk: Low

    Enter firmware setup and disable XMP, EXPO or any memory profile, returning the RAM to its JEDEC default. Note the current settings before you change them so you can restore them.

    Then run the machine normally for a few days.

    Watch out

    If the crashes stop, the modules are not necessarily faulty - they are not stable at the advertised profile on this board and CPU. That is common and is not a defect you can fix in software. Either run at default, or try the profile at a slightly relaxed speed.

  2. Run Windows Memory Diagnostic

    Effort: 30 minutes · Risk: Low

    Microsoft's documented resolution for this code. Press Win+R, run mdsched.exe, and choose to restart and check.

    Results are not shown on screen afterwards. Open Event Viewer, go to Windows Logs then System, and find the MemoryDiagnostics-Results entry.

    Watch out

    Treat a pass as weak evidence. This tool is quick and catches only fairly obvious faults - a clean result does not clear the memory, it just fails to convict it.

  3. Run MemTest86 properly

    Effort: 6-12 hours · Risk: Low

    The real test, and the one worth planning around. MemTest86 boots from USB and tests memory outside Windows entirely.

    Run four full passes - or eight if you can leave it overnight and the fault is intermittent. Errors are usually intermittent, so a single pass proves very little.

    The RAM testing guide covers the setup and how to read the results.

    Watch out

    Any error at all is a failure. There is no acceptable number of memory errors - one is enough to act on.

  4. Test modules individually

    Effort: Several evenings · Risk: Low

    If MemTest86 reports errors and you have more than one module, find out which. Run with a single module fitted, then swap. Use the same slot each time so you are testing the module rather than the slot.

    Then repeat the working module across different slots - that separates a bad module from a bad slot or a marginal CPU memory controller.

    Watch out

    Power down and unplug fully before moving anything, and hold the power button for ten seconds to discharge. Handle modules by the edges.

  5. Reseat memory and clean the contacts

    Effort: 20 minutes · Risk: Low

    Cheap and occasionally decisive. Power down, unplug, discharge. Remove each module, check the gold contacts for dust or discolouration, and refit firmly until both retention clips close on their own.

    Watch out

    On laptops this often means removing a service panel, which may affect warranty terms on some machines. Check before opening if that matters to you.

  6. Investigate a driver doing bad DMA

    Effort: 1-2 days · Risk: Medium

    Only worth reaching for once memory has been properly cleared, since Microsoft lists incorrect DMA as a genuine cause. Driver Verifier's DMA checks can catch a driver mishandling physical pages.

    1. Note which third-party drivers are installed, especially for storage controllers, capture devices, virtualisation and network adapters.
    2. Run verifier /standard /driver name1.sys name2.sys against third-party drivers only - never against all drivers.
    3. Use the machine normally and wait for a crash naming a specific driver.
    4. Turn it off afterwards with verifier /reset and reboot.
    Watch out

    Driver Verifier makes crashes deliberately more likely and can leave the machine unable to boot. Before enabling it, set the escape route: verifier /bootmode resetonbootfail. If it still loops, boot into Safe Mode and run verifier /reset there.

  7. Update firmware if crashes cluster around sleep

    Effort: 45 minutes · Risk: Medium

    Microsoft specifically names firmware illegally modifying physical pages across a power transition. If your crashes happen at resume, after hibernate, or on shutdown rather than during ordinary use, this is worth pursuing.

    1. Check BitLocker status with manage-bde -status and retrieve your recovery key from account.microsoft.com/devices/recoverykey if encryption is on - a firmware update can trigger a recovery prompt at next boot.
    2. Download firmware from the manufacturer's support page for your exact model or service tag.
    3. Run the update on mains power, never on battery.
    4. Do not interrupt it once started.
    Watch out

    An interrupted firmware update can leave the machine unbootable. Only do this after the memory testing above, and only with the manufacturer's own file for your exact model.

When it is the hardware, not Windows

This code is a hardware signal by design, so the question is less whether hardware is involved than which part. These point at memory specifically:

The distinguishing test is whether errors follow the module or stay with the slot. Following the module means replacing that module. Staying with the slot, or appearing with every module tried, points at the board or the CPU's memory controller instead - and that is a more expensive conversation. Either way, back up your data before troubleshooting further: memory that corrupts pages can corrupt what you write to disk.

Frequently asked

What is a single-bit error, really?

One bit that was 0 became 1, or the reverse, without anything writing to it. Windows had zeroed a page and set it aside; when it looked again, exactly one bit had changed.

Cells hold charge, and a cell that is degrading - or disturbed by electrical noise, or by neighbouring activity - can lose or gain enough charge to read back wrong. No software can do this to a page nobody is using, which is why Microsoft treats it as a hardware memory error rather than a possibility to investigate.

Does this always mean I need new RAM?

Not always, and it is worth checking the cheaper explanations first. Memory running above its rated JEDEC speed via XMP or EXPO produces identical symptoms from physically sound modules, so return to default speed before buying anything. Modules can also simply be seated poorly.

Microsoft also lists incorrect DMA from a driver and firmware misbehaving across power transitions as genuine causes. But if memory tests clean at default speed and the crashes continue, those are where to look - and if it tests dirty, the RAM is the answer.

Windows Memory Diagnostic said my memory is fine. Can I rule it out?

No. It is a quick screening tool and it misses a great deal - a pass means it did not find anything, not that there is nothing to find. Intermittent faults in particular slip past it routinely.

Run MemTest86 for four full passes before drawing any conclusion, and eight if the crashes are infrequent. A clean short test against a stop code that Microsoft describes as a hardware memory error should not settle the question.

My parameters 3 and 4 are not zero. Is that better or worse?

Worse, which surprises people. That form comes from the Compressed Store Manager failing to decompress a page - and Microsoft notes that the store manager already detects and silently corrects single-bit corruption without any bugcheck at all.

So reaching a bugcheck by this route means the corruption was beyond a single flipped bit. Test memory the same way, but treat it with more urgency, and stop keeping anything important only on that machine until it is resolved.

Could ECC memory have prevented this?

It would have corrected the single-bit case transparently, which is exactly what ECC exists for - and it would have logged the event so you learned the module was degrading without ever crashing.

Consumer desktops and laptops overwhelmingly do not have ECC, and it needs support from the CPU and board as well as the modules, so it is not something you can simply add. It is a reason this code is far more visible on consumer hardware than on servers.