ERROR_UNEXPECTED_MM_EXTEND_ERR (0X0000022E) — Fix It Fast

Your machine just blue-screened with a bugcheck code most people have never seen: ERROR_UNEXPECTED_MM_EXTEND_ERR with a parameter of 0X0000022E. That string comes from MmExtendSection in the kernel memory manager, which is Windows' internal routine for growing a section object — usually a mapped file or shared memory region. Something asked to extend a section and the memory manager couldn't do it cleanly.

In practice, this almost always traces back to one of three things: a driver passing a bad size into the memory manager, bad RAM corrupting the extend request mid-flight, or a page file that's too small for the section being grown. You don't need to guess which. Work the list below in order and stop when the crash stops.

Step 1 — The 30-second fix: rule out a one-off

Before you touch anything, check whether this happened once or is repeating. Open Event Viewer and look at Windows Logs → System. If you see exactly one BugCheck event with code 0x1a (that's MEMORY_MANAGEMENT, which is what 0x22E is actually reported under) and nothing else, it might genuinely be a one-time glitch during a heavy operation — a large file copy, a VM snapshot, a database checkpoint.

Reboot. If it doesn't come back in a day of normal use, you're done. Don't chase ghosts. The reason this step matters is that MmExtendSection can fail once under extreme memory pressure and never fail again — the kernel handles it, logs it, and moves on. Two or more bugchecks in 48 hours means it's a pattern, so continue.

Step 2 — The 5-minute fix: test your RAM

Bad RAM is the single most common cause of ERROR_UNEXPECTED_MM_EXTEND_ERR in my experience. The memory manager relies on reading back what it just wrote when it extends a section. If a bit flips, the extend request looks corrupted and the kernel bugchecks rather than risk writing bad data to disk.

Run the Windows Memory Diagnostic with the extended pass, which is the one that actually catches intermittent errors:

mdsched.exe

Pick "Restart now and check for problems." When the blue diagnostic screen appears, press F1 and select Extended. That runs multiple passes including the MATS+ pattern, which is the one that catches the kind of marginal failure that triggers 0x22E. If you see any errors at all, pull the RAM sticks and test each one individually. One bad stick can cause this for months while everything else looks fine.

If you have XMP or DOCP enabled in BIOS, disable it temporarily and re-test. Memory that passes at JEDEC speeds but fails at rated XMP speeds will throw MmExtendSection errors specifically under load, because section extensions happen most when apps are allocating large buffers.

Step 3 — The 15-minute fix: page file and driver verifier

If RAM is clean, the next suspect is the page file. MmExtendSection needs backing store to grow a section. If the page file is fixed-size and too small, or if it's on a nearly-full drive, the extend fails and the kernel bugchecks.

Set the page file to system-managed on the drive where Windows lives. The old advice about fixed page files for performance is mostly wrong on modern SSDs, and it's actively harmful for this bugcheck:

1. Press Win+R, type sysdm.cpl, hit Enter.
2. Advanced tab → Performance Settings → Advanced tab.
3. Virtual memory → Change.
4. Uncheck "Automatically manage" if it's checked, then tick System managed size for your C: drive and remove any custom page file on other drives.
5. Reboot.

The reason this works is that system-managed means Windows can grow the page file as needed instead of hitting a ceiling mid-operation. If you were running a fixed 4 GB page file on a machine with 32 GB of RAM and a workload that maps large files (SQL Server, Visual Studio with big solutions, Docker Desktop on WSL2), you were paying for that.

If the crash persists after the page file change, run Driver Verifier on your non-Microsoft drivers. This forces every driver to validate its memory operations, which turns silent corruption into a clean, attributable crash:

verifier /standard /all
verifier /querysettings

Reboot and use the machine normally. When it bugchecks again, look at the minidump — Driver Verifier will name the offending driver directly in the bugcheck parameters rather than giving you the generic MmExtendSection address. To turn it off when you're done:

verifier /reset

Do not leave Driver Verifier running permanently. It slows the machine noticeably and a bad driver under verifier will bugcheck the box on every boot until you reset it. If you can't boot, you'll need to disable it from Safe Mode.

What's actually happening inside the kernel

When you see ERROR_UNEXPECTED_MM_EXTEND_ERR, the kernel was inside MiExtendSection, tried to allocate or map additional pages for a section object, and got a result it couldn't reconcile with its internal state. The four bugcheck parameters (which is what 0X0000022E actually is — the fourth one) will point at the section object and the requested size. If you're comfortable in WinDbg, load the minidump and run:

!analyze -v
!vm
!pool <section_address>

The !vm output is the giveaway: if "System Commit" is at or near the limit, you have a commit-charge problem, and the page file fix is your answer. If the pool tag on the section comes back as something like MmSt or a third-party driver tag, that driver is your culprit.

Quick reference

Resist the temptation to immediately run DISM and SFC. They're great tools, but for this specific bugcheck they almost never help — MmExtendSection is a runtime memory operation, not a corrupted system file. Save those for when the dump actually points at a system binary.