Fix MEMORY_MANAGEMENT BSOD in Windows 11

Your PC restarts on its own, and when it comes back up you get a brief flash of a stop code before it logs back in: MEMORY_MANAGEMENT. Maybe it happened while you were mid-download, maybe it was during a game, maybe it happened while the machine was sitting idle overnight. Whatever you were doing, the fix for the MEMORY_MANAGEMENT blue screen error in Windows 11 depends entirely on which of several unrelated things is actually broken, and guessing wrong wastes hours.

I've chased this one down on desktops, laptops, and one very unlucky mini PC, and the causes I've actually found behind it split pretty evenly between three buckets: RAM that's unstable (sometimes because it's failing, sometimes because someone enabled XMP/EXPO and never checked if it was stable), a driver — usually graphics or storage — writing to memory it shouldn't touch, and corrupted system files left over from an interrupted update. Less often, it's a full disk or a dying storage drive messing with the paging file. This guide walks through how to tell which one you've got before you touch anything.

What MEMORY_MANAGEMENT actually means

Microsoft's own driver documentation defines Bug Check 0x1A as a severe memory management error — something in the way Windows tracks, allocates, or maps memory pages went wrong badly enough that continuing would risk corrupting data, so the kernel stops the machine instead. That's it. It's not a single problem; it's a category of problem, and the exact sub-cause is buried in a parameter value inside the crash dump that most people never look at.

People sometimes ask whether MEMORY_MANAGEMENT always means the RAM sticks themselves are bad. No — a corrupted page table entry, a driver stomping on memory it doesn't own, and physically faulty RAM all produce the same stop code. That's exactly why jumping straight to "buy new RAM" is the wrong first move for most people who see this error.

Symptom, confirming check, and fix at a glance

What you're seeing	Check that confirms it	Fix to apply
Crashes started right after a RAM upgrade or enabling XMP/EXPO	Reset memory profile to JEDEC default in BIOS, see if crashes stop	Lower the memory speed/timings one step, or disable the XMP/EXPO profile entirely
Crashes happen under load (gaming, rendering, compiling)	Windows Memory Diagnostic (mdsched.exe) reports hardware errors	Reseat RAM, test sticks individually, replace the failing module
Crashes started after a Windows Update or driver update	Event Viewer shows the crash timestamp lines up with a recent update; Reliability Monitor shows the same	Roll back the driver, or check Windows Release Health for a known issue before doing anything else
Crash mentions a specific .sys file, or Device Manager shows a device with an error icon	Check the faulting module name in the minidump or Reliability Monitor detail view	Update or roll back that specific driver from the manufacturer's site
sfc /scannow reports it found and fixed corrupt files	Run sfc /scannow after DISM /RestoreHealth and read the CBS.log	Complete the DISM + SFC repair, reboot, confirm a clean scan
Crashes correlate with the disk being nearly full or a failing drive	Check free space and run a SMART/health check on the drive	Free up space, or back up and replace a failing drive before it takes the OS with it

Check for a known Microsoft-documented issue first

Before you spend an evening testing RAM sticks, it's worth two minutes to rule out a bad update. Microsoft tracks confirmed regressions on its Windows release health dashboard, broken out by version (24H2, 25H2, and so on). If a specific cumulative update is causing crashes for a chunk of users, it'll show up there with a resolution date or a workaround, and installing the fix is faster than any manual repair. I check this page before I do anything else when a crash pattern started right after Patch Tuesday — it's saved me from chasing my own tail more than once.

If nothing matches your symptoms there, move to Windows Update itself and make sure you're actually current:

Settings > Windows Update > Check for updates

Install anything pending, including optional driver updates listed under "Advanced options > Optional updates," and reboot before doing further diagnosis. A partially-applied update is a legitimate cause of memory management crashes on its own.

Read what Windows already told you about the crash

You don't need WinDbg for the first pass. Reliability Monitor gives you a plain-language timeline of crashes and, often, the name of the faulting driver.

Press Win + R, type perfmon /rel, press Enter.
Find the red X icons on the days you crashed.
Click one and read the "Problem Event Name" and any listed module — a graphics driver file (nvlddmkm.sys, igdkmd64.sys, amdkmdag.sys) or a security-suite driver here is a strong lead, not a coincidence.

If you want the actual bug check parameter — which tells you whether this is a page table corruption, a pool corruption, or a driver mapping violation — open Event Viewer (eventvwr.msc), go to Windows Logs > System, and filter for Event ID 1001 with source "BugCheck." The description includes four parameter values. If the first one starts with 0x41792, 0x61941, or 0x3f, Microsoft's documentation ties those specifically to corrupted page table entries or CRC failures on the pagefile — both point toward RAM or disk, not a driver bug. I won't pretend every value maps cleanly to one cause; several of them are genuinely ambiguous without a full WinDbg session, and if you're seeing repeated crashes with no clear pattern after the steps below, that's when handing a minidump to someone who can run !analyze -v actually earns its keep.

Rule out RAM with Windows Memory Diagnostic

This is the single most useful non-destructive check you can run, and it takes 10 to 15 minutes on a standard pass.

Press Win + R, type mdsched.exe, press Enter.
Choose "Restart now and check for problems (recommended)."
Let it run. Don't touch the keyboard unless you want to press F1 to switch to the Extended test mix, which I'd recommend if the Standard pass comes back clean but you're still crashing — Extended catches intermittent faults Standard misses.
After the reboot, open Event Viewer, go to Windows Logs > System, and search for the source "MemoryDiagnostics-Results."

If Windows Memory Diagnostic reports hardware errors, stop troubleshooting software. Power down, reseat every RAM stick, and if you have more than one module, test them one at a time to isolate which one is bad. A module reporting errors under Standard test is not going to pass under load in a game later — replace it.

If you built the PC yourself or bought parts separately, check whether the RAM is running at its rated JEDEC speed or an overclocked XMP/EXPO profile. I've seen more MEMORY_MANAGEMENT crashes traced to RAM running faster than the CPU's memory controller comfortably supports than to actual dead sticks. Go into BIOS/UEFI, disable the XMP or EXPO profile, and run at the default JEDEC speed for a few days. If the crashes stop, you've found it — either drop the profile one speed step down or replace the kit with something your board and CPU are actually rated for.

Check for the driver actually causing it

Outdated or buggy graphics drivers are the other frequent culprit, and Microsoft's own troubleshooting guidance for stop errors estimates that roughly 75 percent of stop errors trace back to a faulty driver — that's the first thing to rule out here, not RAM, if Windows Memory Diagnostic came back clean.

Open Device Manager (right-click Start), and look for any device with a yellow warning icon.
Update graphics drivers directly from the manufacturer's site (NVIDIA, AMD, or Intel) rather than relying only on Windows Update — vendor installers do a full clean uninstall option that Windows Update doesn't.
If crashes started right after a driver update, roll it back: Device Manager > right-click the device > Properties > Driver tab > Roll Back Driver (only available if a previous version was recorded).

Third-party security software and virtualization/anti-cheat kernel drivers are worth a look too, especially if the Reliability Monitor detail names a driver you don't recognize. Temporarily uninstalling a suspect third-party security suite and running Microsoft Defender alone for a few days is a legitimate diagnostic step, not just a superstition.

Repair corrupted system files

If RAM tests clean and drivers are current, corrupted system files are next. Run these in order, from an elevated Command Prompt:

DISM /Online /Cleanup-Image /RestoreHealth
sfc /scannow

Microsoft's documented order is DISM first, then SFC — DISM repairs the component store that SFC pulls its replacement files from, so running SFC first against a broken store can make it report files it can't actually fix. DISM can take a while and will appear to hang at certain percentages; that's normal, let it finish. When SFC completes, you'll see one of a few outcomes: no integrity violations found, violations found and repaired, or violations found that it couldn't fix. If it's the last one, check %windir%\Logs\CBS\CBS.log for the specific file it couldn't replace.

If DISM can't reach Windows Update to pull replacement files (error 0x800f081f is the usual sign), you'll need a matching Windows 11 ISO as a local repair source:

DISM /Online /Cleanup-Image /RestoreHealth /Source:D:\sources\install.wim /LimitAccess

replacing D: with wherever you've mounted the ISO.

Check the disk and paging file

MEMORY_MANAGEMENT crashes can also come from the pagefile itself failing to read or write correctly, which usually points at a failing drive or a nearly-full one. Check free space first — Windows wants meaningful headroom to manage virtual memory, and a drive sitting above 90–95% full is asking for trouble. Then check disk health:

chkdsk C: /f /r

This requires a restart if the drive is in use, which it will be for your system drive. Let it complete; on a large or aging drive this can take a long time, especially the /r pass which checks for bad sectors. If chkdsk reports bad sectors on a mechanical or aging SSD, back up your data immediately — that's a symptom of a drive that's failing, not one that's been fixed by the scan.

Driver Verifier — powerful, but not your first move

If you've done all of the above and you're still crashing with no clear pattern, Driver Verifier will force a suspect driver to fail loudly and generate a dump that names it, instead of crashing generically. Microsoft ships it as Verifier.exe in every copy of Windows, and it's documented as a driver-testing tool, not a consumer fix-it tool — it's meant to make things crash, on purpose, so treat it as a diagnostic step rather than a repair.

Create a System Restore point first. Driver Verifier can make an unstable system unbootable, and you'll want an easy way back.
Open an elevated Command Prompt, type verifier, and press Enter to open Driver Verifier Manager.
Choose "Create standard settings," then "Select driver names from a list," and check every driver that isn't provided by Microsoft.
Reboot. If a targeted driver misbehaves, you'll get a bug check that names it directly instead of a generic MEMORY_MANAGEMENT.
Once you've identified the driver (or gone 24–48 hours without a crash), turn Driver Verifier back off: verifier /reset, then reboot.

I don't run this on anyone's daily-driver machine without warning them first — it will make things worse before it makes them better, and that's the point. If it can't get through a boot cycle, boot into Safe Mode and run verifier /reset from an elevated Command Prompt there.

What I would not do

Jump straight to a clean reinstall. If the cause is failing RAM or an overclocked kit, reinstalling Windows changes nothing — you'll be back here in a week having lost your app setup for no reason.
Trust a third-party "PC repair" tool to auto-fix a BSOD. These generally run generic cleanup tasks and registry edits with no idea what your actual bug check parameter was. At best they do nothing; at worst they touch things they shouldn't.
Disable your antivirus permanently as a "fix." Temporarily removing a suspect third-party security suite to test is fine; leaving your machine unprotected because it made a BSOD go away is not a real solution.
Run chkdsk /f on a drive you suspect is physically failing without backing up first. A repair pass on a dying drive can accelerate data loss instead of preventing it.
Max out the pass count on Windows Memory Diagnostic and walk away for a day "just to be thorough." One Extended pass tells you almost everything a dozen passes would; past that you're mostly burning time.

People sometimes ask if it's safe to just keep using the PC while they work through this list. Mostly yes, as long as you're saving work often — but if Reliability Monitor shows crashes multiple times a day, back up anything irreplaceable before you keep troubleshooting, because you don't yet know if the underlying cause could touch the disk itself.

When this goes past a manual fix

If Windows Memory Diagnostic is clean, drivers are current, DISM and SFC both report a healthy system, chkdsk finds nothing, and Driver Verifier runs 48 hours without a hit, you're in genuinely rare territory — possibly a motherboard memory controller issue, a marginal power supply under load, or hardware that only fails at a specific temperature or voltage the standard tests don't hit. At that point a proper WinDbg analysis of the actual minidump, or a hardware technician with a bench and a different set of known-good RAM, will get you further than another round of the same software checks.

My honest take: start with Windows Memory Diagnostic and a driver check, in that order, before anything else on this list. In my experience those two catch the large majority of MEMORY_MANAGEMENT crashes I've actually diagnosed, and they're both non-destructive. Everything past DISM/SFC is for the crashes that survive the easy stuff — don't skip ahead to Driver Verifier or a reinstall just because they feel more decisive.