MEMORY_MANAGEMENT Blue Screen 0x1A: What Parameter 1 Tells You

A MEMORY_MANAGEMENT blue screen is stop code 0x0000001A (usually shortened to 0x1A). Microsoft's definition is a single line: the bug check "indicates that a severe memory management error occurred." The useful detail is not in the name but in parameter 1, the first of the four numbers Windows records with the crash. Microsoft publishes what each parameter 1 value means, and a few of them are flagged as probable hardware errors. This page shows you how to find that number, how to read it, and which two steps Microsoft gives for resolving the error.

Everything here comes from the Microsoft Learn page "Bug Check 0x1A: MEMORY_MANAGEMENT" and Microsoft's general page on analysing blue screen data, both read on 12 October 2026 and checked against the Microsoft Docs source files. Microsoft marks the 0x1A page as written for programmers and sends everyday users to a separate help page. We point out which parts are for whom, and where the page says nothing, we say that rather than filling the gap.

What does stop code 0x1A mean?

Windows manages memory through structures such as page tables, page table entries (PTEs) and page frame numbers (PFNs). When one of these is found in a state that should be impossible, Windows stops with MEMORY_MANAGEMENT rather than risk carrying on with corrupted memory bookkeeping. The stop code itself does not say whether the cause was a faulty memory module, a driver that misused memory, or something else. That is the job of parameter 1.

Microsoft's page states it directly: "Parameter 1 identifies the exact violation." Parameters 2, 3 and 4 only have a meaning in the context of a particular parameter 1 value. For some values they hold an address or an expected value; for many they are not described at all.

Where do you find parameter 1?

There are three ways, and only the first one needs no extra software.

• Event Viewer. Microsoft's general guide to blue screen data says the event properties for the bug check in the Windows system log list the four stop code parameters. Open Event Viewer, go to Windows Logs, System, and find the entry logged at the time of the crash.
• A crash dump in WinDbg. Loading the dump and running !analyze prints the parameters, along with Microsoft's description of the stop code.
• A kernel debugger attached at the time of the crash. The output lists the four parameters after the stop code value. This is a developer setup, not something a home user will have.

Write the four values down exactly, or take a phone photo of the event details. A single digit makes a different code.

Which parameter 1 values point to hardware?

Microsoft's 0x1A table is long: more than 35 current values plus a second table of values used in earlier versions of Windows. We have not copied the whole table. The rows below are the ones most useful for a first look, because Microsoft either names hardware as the probable cause or names a driver as the actor. The wording is a close summary of Microsoft's own.

Parameter 1	What Microsoft says it means	Hint in the text
0x31	The image relocation fix-up table or code stream has been corrupted	"probably is a hardware error"
0x3f	An inpage operation failed with a cyclic redundancy check (CRC) error	Parameter 2 is the pagefile offset
0x403	The page table and page frame numbers are out of sync	Probably hardware, especially if parameters 3 and 4 differ by only one bit
0x1233	A driver tried to map a physical memory page that wasn't locked	A bug in the code made the call
0x4477	A driver tried to write to an unallocated address in the system process's user space	Driver named as the actor
0x41790	A page table page has been corrupted	No cause named
0x41792	A corrupted PTE has been detected	No cause named
0x5003 (older Windows)	The working set free list is corrupted	"probably a hardware error"
0x61946 (older Windows)	The MDL being created is flawed	Almost always the driver calling MmProbeAndLockPages

Two cautions. First, "probably" is Microsoft's word, and it is not a diagnosis of your particular PC. Second, most rows in the full table describe corruption without naming a cause at all. If your value is not in this short list, look it up in the full table on the Microsoft page linked at the bottom.

What does Microsoft say to do about it?

This is where the 0x1A page is unusually short. The resolution section has exactly two items:

• Run the !analyze debug extension. Microsoft says it "displays information about the bug check" and might help identify the root cause. This needs WinDbg and a crash dump.
• Run the Windows Memory Diagnostic tool. Microsoft says you "might find it helpful" to run it "to check for problems that affect physical memory modules."

That is the full list on the 0x1A page. Microsoft does not add a driver checklist or a long list of general tips for this particular code, and we are not going to invent one and present it as Microsoft's.

How do you run Windows Memory Diagnostic?

The 0x1A page names the tool but does not describe the steps. Microsoft does describe them on its page for a related stop code, Bug Check 0x50 PAGE_FAULT_IN_NONPAGED_AREA (https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/bug-check-0x50--page-fault-in-nonpaged-area). Following that page:

• Open Control Panel and type Memory in its search box.
• Select Diagnose your computer's memory problems.
• Let the test run to the end. Save your work first; the page does not describe the test screen itself.
• Afterwards, open Event Viewer, go to the System log and look for the entry named MemoryDiagnostics-Results.

Microsoft's pages do not say how long the test takes, how many passes it runs, or what to do if it passes but the blue screen keeps returning. Treat a clean result as one piece of evidence, not as proof that memory is fine.

What if the memory test is clean?

Here we step outside the 0x1A page, and we label it clearly. Microsoft's general page "Analyze bug check (stop code error) data" says that "about three quarters of stop code errors are caused by faulting drivers," an estimate in Microsoft's own wording. The same page describes Driver Verifier, a tool built into Windows that watches drivers in real time: you start it by typing Verifier at a command prompt, choose which drivers to check, and keep the list as short as possible because verification adds overhead. Microsoft's general page also says the goal, when the fault is not in your own code, is to isolate and remove the hardware or software component at fault.

Notice what parameter 1 already told you. Values such as 0x1233 and 0x4477 name a driver as the actor, so Driver Verifier is the more natural next step for those. Values flagged as probable hardware errors point first to the memory test and to the hardware itself.

Checklist: what to collect before you change anything

• The stop code text on screen: MEMORY_MANAGEMENT, 0x0000001A
• All four parameters from Event Viewer (System log, bug check event)
• The time of each crash, so repeat events can be compared
• Anything that changed just before the first crash: memory added, a new driver, an update
• The MemoryDiagnostics-Results entry, once the test has run
• Whether parameter 1 is the same each time or changes between crashes

The last line matters. Microsoft's page gives no rule for it, but a parameter 1 that changes from crash to crash and one that repeats exactly are different facts worth recording before anyone else looks at the machine.

For developers: what the page offers

If you are writing or debugging a driver, the 0x1A table is the main tool. Many entries name the routine or structure involved: MmUnsecureVirtualMemory called in the wrong process context (0x15001), an MDL built for a non-resident range (0x1240), an invalid pool address being freed (0x5305 and 0x41286), and an illegal page fault while holding working set synchronization (0x41287). Run !analyze first, then match parameter 1 against the table. Microsoft notes that value 0x41793 was deprecated and is no longer available after Windows 10 version 1803.

What this page does not cover

• A fix that is guaranteed to work. Microsoft lists two steps for 0x1A and ranks neither by success rate.
• Registry edits, paging file tweaks or third-party repair tools. None of these appear on the Microsoft page for this code.
• Buying new memory. Microsoft's text says some values are "probably" hardware errors. It does not tell you to replace parts, and we will not either.
• Other stop codes. Each code has its own Microsoft page. Our PC and phone fix index lists the stop code guides we have, searchable by code name or hex value.

Sources and how to check

• Bug Check 0x1A: MEMORY_MANAGEMENT, Microsoft Learn: https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/bug-check-0x1a--memory-management
• Analyze bug check (stop code error) data, Microsoft Learn: https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/blue-screen-data
• Bug Check 0x50: PAGE_FAULT_IN_NONPAGED_AREA (Memory Diagnostic steps): https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/bug-check-0x50--page-fault-in-nonpaged-area
• Troubleshoot blue screen errors (for regular users): https://www.windows.com/stopcode
• Source: Microsoft Learn, as of 12 October 2026. Checked against the Microsoft Docs source files (MicrosoftDocs/windows-driver-docs). Microsoft documentation is licensed under Creative Commons Attribution 4.0 (CC BY 4.0); this article adapts and summarises it with credit to Microsoft and links to the originals. Microsoft does not endorse this site.

Editor's note

Checked: the meaning sentence for 0x1A, every parameter 1 row in our table, the two resolution items, the Memory Diagnostic steps on the 0x50 page, and the "three quarters" estimate on the general page, all against the Microsoft source files on 12 October 2026.

Not checked: how often 0x1A turns out to be memory hardware rather than a driver. Microsoft gives no figure for this code, and we did not test it on hardware.

Left out on purpose: the full 50-plus row parameter table (linked instead), registry tweaks, paid tools and any step that is not on a Microsoft page.