⚠ CrashDecoder

0x0000001A MEMORY_MANAGEMENT

The memory manager checks its own structures constantly, and when it finds one in a state that should be impossible it stops the machine rather than continue with corrupted bookkeeping. Of all the stop codes, this is the one most likely to genuinely be the RAM - but not reliably enough to buy memory on the strength of it, and the first parameter is what tells you which case you have.

Updated 2026-07-27Stop errorAlso written: 0x1A, MEMORY MANAGEMENT, memory management error, memory management bsod

What you are looking at

:(

Your PC ran into a problem and needs to restart.

Stop code: MEMORY_MANAGEMENT

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: 0x0000001a (0x0000000000041790, 0xfffff68000138000, 0x000000000000ffff, 0x0000000000000000).

What the error actually means

The memory manager tracks which physical pages exist, which are in use, what each one holds, and how virtual addresses map onto them. That bookkeeping lives in structures like the page frame number database and the page tables.

Those structures are internally consistent by construction. If the manager finds an entry that contradicts another - a page marked free that is still mapped, a page table entry pointing somewhere impossible - then something has damaged memory that Windows relies on absolutely. Continuing would mean writing user data into unpredictable places.

So it stops. And because the damage could have come from failing hardware, a misbehaving driver, or corrupted data read back from disk, the code itself is broad. The subtype in parameter 1 is where the real information is.

Reading the parameters

Parameter 1 is a subtype code and it changes the entire diagnosis. Microsoft documents around forty values; these are the ones you are most likely to meet, with what parameters 2 to 4 carry for each. Note that parameters 2, 3 and 4 mean different things depending on the subtype - there is no single interpretation.

ParameterWhat it holds
0x403The page table and page frame numbers are out of sync. Microsoft states this is probably a hardware error - especially if parameters 3 and 4 differ by only one bit. That single-bit detail is the most useful thing on this page: a one-bit discrepancy is the classic signature of a memory bit flip, and it distinguishes failing hardware from a driver writing nonsense.
0x404While deleting a system page, an inconsistency was found between the PFN and the current page table entry pointer. Parameter 2 is the expected PTE, parameter 3 the PTE contents, parameter 4 the PFN's PTE.
0x41790A page table page has been corrupted. On 64-bit Windows, parameter 2 holds the address of the PFN for the corrupted page table page. Strongly associated with hardware.
0x41792A corrupted PTE was detected. Parameter 2 is the address of the PTE; parameters 3 and 4 hold its low and high parts.
0x61941The paging hierarchy is corrupted. Parameter 2 points at the virtual address that caused the fault.
0x3fAn inpage operation failed a cyclic redundancy check. Parameter 2 is the pagefile offset, parameter 3 the page's CRC, parameter 4 the expected CRC. This one implicates storage rather than memory - data came back from the page file wrong. Check the drive before the RAM.
0x6001The memory store component's private memory range is corrupted and has become inaccessible. Worth knowing because it connects this bugcheck to UNEXPECTED_STORE_EXCEPTION - both involve the memory compression store.
0x31The image relocation fix-up table or code stream has been corrupted. Microsoft notes this is probably a hardware error.
0x5100The allocation bitmap is corrupted - the memory manager was about to overwrite a virtual address already in use.
0x9696A PFN was found with corrupted linkage, no longer connected to its top-level process. Indicates corrupted PFN structures.

What actually triggers it

This is the stop code where memory hardware genuinely leads the list, which is unusual.

CauseHow oftenDetail
Failing RAMCommonA defective cell corrupts whatever is stored in it. When that happens to be page table data, this is the result. Of all the common stop codes, this is the one where a memory test is most likely to actually find something.
Unstable memory profileCommonXMP and EXPO profiles are tested by the module maker, not validated against your specific CPU memory controller and board. A profile that is slightly out of reach produces exactly this pattern, intermittently, on hardware that tests clean at stock.
Drivers corrupting pool memoryOccasionalA driver that writes past the end of an allocation damages whatever is next to it. The memory manager notices later, at a point unrelated to the guilty code.
Storage or filesystem corruptionOccasionalPaged data read back incorrectly from a failing drive arrives in memory already wrong. A failing SSD or a corrupt page file can produce this.
CPU memory controller or board faultRareWhere you end up when memory tests clean in another machine but the fault stays with this one.

Narrowing it down

Record the subtype first. It decides which of the following is even worth doing.

Write down parameter 1 from every crash

Pull the bugcheck records from the event log so you have the full parameter set for each occurrence:

Get-WinEvent -FilterHashtable @{LogName='System'; Id=1001} |
  Where-Object { $_.Message -match '0x0000001a' } |
  Select-Object TimeCreated, Message |
  Format-List
What it tells you

A consistent subtype across crashes is a coherent single fault. Subtypes that vary point at general memory corruption rather than one specific broken thing - which favours hardware.

If your subtype is not in the table above, check Microsoft's full reference - values such as 0x41284, 0x41201 and 0x5003 are documented as belonging to earlier Windows versions, so seeing one on a current build is unusual and worth noting.

Test memory at stock settings

Disable XMP or EXPO first, then run MemTest86 from USB for at least four full passes. Test at stock before testing with the profile enabled, so you can tell a bad module from an over-ambitious profile.

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 achievable on this board and CPU - which is a settings problem, not a purchase.

Check the drive

Run chkdsk /scan on the system volume and check SMART attributes with CrystalDiskInfo. Pay attention to reallocated sector counts on a hard drive, and to remaining life and media errors on an SSD.

What it tells you

Storage problems produce memory-manager crashes because paged data comes back wrong. A drive flagged as anything other than healthy moves to the front of the queue.

Fixes, cheapest first

Ordered so that the free tests come before anything you would pay for.

  1. Drop to stock memory settings

    Effort: 10 minutes · Risk: Low

    In UEFI, disable XMP, EXPO or any manual memory tuning and let the modules run at their JEDEC default speed. Performance loss is modest and it costs nothing.

    Run this way for several days. If the crashes stop, you have your answer - and the fix is either to accept stock, loosen the primary timings, or nudge the memory controller voltage rather than assume the advertised speed is guaranteed on your combination of parts.

  2. Test each module individually

    Effort: Overnight per module · Risk: None

    If MemTest86 reports errors with everything installed, find out which module by testing them one at a time - and test each one in the same slot, so a faulty slot does not get blamed on a good module.

    1. Power down and remove all but one module.
    2. Run MemTest86 for at least four passes.
    3. Repeat with each module in that same slot.
    4. If every module passes alone but the set fails together, suspect the slot, the board, or the memory controller.
    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 often reintroduces instability.

  3. Verify system files and the drive

    Effort: 45 minutes · Risk: None

    Corrupted paged data produces this bugcheck even when the memory is perfect.

    1. sfc /scannow
    2. DISM /Online /Cleanup-Image /RestoreHealth
    3. chkdsk C: /scan
    4. Check SMART data for the system drive and update its firmware if the vendor has a newer version.

  4. Rebuild the page file

    Effort: 15 minutes · Risk: Low

    A corrupted page file feeds bad data straight back into memory. Set the page file to None in System Properties, reboot, then set it back to system-managed and reboot again. This forces a fresh one.

    Worth doing specifically if the crashes began after an unclean shutdown or a storage problem.

  5. Hunt the driver with Verifier

    Effort: Several hours · Risk: Medium

    If memory tests clean and the drive is healthy, a driver is corrupting pool memory. Driver Verifier with Special Pool enabled is built precisely to catch that - it places allocations so that an overrun faults immediately rather than silently damaging a neighbour.

    Enable it for non-Microsoft drivers only, use the machine until it bugchecks, then read the dump and run verifier /reset afterwards.

    Watch out

    Verifier deliberately increases crashes and can cause a boot loop. Run verifier /bootmode resetonbootfail before enabling any checks - it makes Verifier disable itself automatically if the machine fails to start, which removes most of the risk. Your manual exit is Safe Mode followed by verifier /reset. Full settings and the escape route are in the Driver Verifier guide.

When it is the hardware, not Windows

Signals that this is memory or board hardware rather than software:

Memory is one of the few components you can test conclusively at home and, if it is at fault, one of the cheapest to replace. That makes this bugcheck unusually solvable - work through the tests properly and you will normally arrive at a definite answer rather than a guess.

Frequently asked

Windows Memory Diagnostic passed. Is my RAM fine?

Not established. The built-in tool runs a short, limited set of patterns and misses faults that a thorough tester finds in the first hour. Treat a pass from it as almost no information. MemTest86 booted from USB, run for several passes, is the test worth trusting - and even then a clean run does not fully exonerate memory against intermittent faults.

Is XMP actually risky? It is an advertised speed.

It is advertised by the module manufacturer, who validated it on their own test platform. Whether it works depends on your CPU's memory controller and your board's trace layout, and neither is covered by that validation. Running XMP is normal and usually fine - but when a machine is producing memory-manager bugchecks, treating the profile as above suspicion is a mistake. Testing at stock costs ten minutes.

Can a failing SSD cause a MEMORY_MANAGEMENT crash?

Yes, and it is under-considered. Windows pages memory to disk continuously. If the drive returns corrupted data, that corruption lands in memory and the manager finds an inconsistency it cannot explain. Check drive health before concluding the RAM is bad - the symptom points at memory, but the cause can be one layer down.

I get a different parameter 1 every time. What does that mean?

It favours hardware. A driver bug tends to damage the same structure in the same way, producing a consistent subtype. Corruption that lands somewhere different on each occasion is what failing memory looks like, because which bits go bad depends on what happened to be stored where.