Fix ERROR_UNEXPECTED_MM_MAP_ERROR (0X0000022D) in Dev Tools

Yeah, that 0X0000022D error is a pain. It usually pops up when you're running Visual Studio, Node.js with large buffers, Docker Desktop, or even a VirtualBox VM. The system just says "no" to your request to map memory. Let's fix it.

The Quick Fix: Increase Your Pagefile Size

In 9 out of 10 cases, the culprit is a pagefile that's too small. Windows uses the pagefile as backup RAM. When a dev tool asks for a big chunk of memory (like a 4 GB buffer), Windows might try to map it to the pagefile. If the pagefile can't grow, you get 0X0000022D.

1. Press Win + R, type sysdm.cpl, and hit Enter.
2. Go to the Advanced tab. Under Performance, click Settings.
3. In the Performance Options window, go to the Advanced tab again. Under Virtual memory, click Change.
4. Uncheck Automatically manage paging file size for all drives.
5. Select your C: drive (or the drive where your project files live).
6. Choose Custom size. Set Initial size (MB) to 4096 and Maximum size (MB) to 8192. If you have 16 GB or more RAM, go higher — 8192 initial and 12288 max is safer for heavy dev work.
7. Click Set, then OK. After clicking Apply you should see the new values listed under the drive.
8. Restart your computer. Yes, you need to restart. The new pagefile only takes effect after a reboot.

After the restart, try running your dev tool again. If the error's gone, you're done. If not, move to the next step.

Why This Works

When a program like Node.js or Visual Studio calls VirtualAlloc with the MEM_RESERVE flag, Windows reserves a region of virtual memory backed by the pagefile. If the pagefile can't expand to cover that reservation — because it already hit its max — Windows returns the ERROR_UNEXPECTED_MM_MAP_ERROR. It's a roundabout way of saying "I can't find a spot to put this memory."

Setting the pagefile to a fixed, larger size removes that bottleneck. Windows can then honor the memory mapping request. It's not about RAM being full; it's about the pagefile being too constrained.

Less Common Variations

1. Memory Integrity (Core Isolation) Gets in the Way

Memory Integrity is a Windows security feature that runs the kernel in a virtualized environment. It can block certain memory mapping calls from dev tools. If increasing the pagefile didn't help, try this:

1. Open Windows Security.
2. Go to Device Security > Core isolation details.
3. Turn Memory integrity off.
4. Restart.

This is a trade-off: better security vs. getting your work done. I usually keep it off on my dev machine and only turn it on when I'm not coding.

2. VirtualBox or Docker with Large Memory Allocations

If you're running a VM with huge memory (like 8 GB reserved), Windows might struggle to map that. The fix is the same – increase the pagefile – but also check your VM's settings. Reduce the RAM allocation to 4 GB or less if you can.

3. Visual Studio Specific: Clear the VS Cache and Disable ReSharper

Visual Studio can sometimes trigger this error when its cache gets bloated. Try this:

1. Close Visual Studio.
2. Delete the folder %USERPROFILE%\AppData\Local\Microsoft\VisualStudio (but back up your settings first if you care about them).
3. Restart VS. It will rebuild the cache.

Also, if you have ReSharper installed, try disabling it temporarily. It's a known memory hog and can push VS over the edge.

Prevention Going Forward

To keep 0X0000022D from coming back:

• Set a permanent, large pagefile. Don't let Windows manage it. A fixed size of 8192 MB initial and 12288 MB max is a solid baseline for 16 GB RAM machines. For 32 GB, bump it to 16384 MB max.
• Monitor your memory usage. Use Task Manager to see how much virtual memory each dev tool eats. If Node.js is consistently over 4 GB, consider splitting your app into smaller processes.
• Keep Windows updated. Microsoft has patched some memory mapping bugs in Win 10 22H2 and Win 11 23H2. Make sure you're on the latest cumulative update.
• Use 64-bit dev tools. 32-bit programs are limited to 2 GB of virtual memory and choke faster. All modern versions of Visual Studio, Node.js, and Python are 64-bit, but double-check you're not running an old 32-bit build.

One last thing: if you're using WSL2, the error can also show up when the WSL2 VM runs out of swap space. In that case, edit %USERPROFILE%\.wslconfig and add swap=8GB (or however much you need). Then restart WSL with wsl --shutdown.

That's it. Go increase that pagefile, reboot, and get back to coding. You've got better things to do than fight memory errors.