STATUS_WORKING_SET_LIMIT_RANGE 0X40000002: Fix It for Good

If you've landed on this page, you've probably seen a wall of blue with STATUS_WORKING_SET_LIMIT_RANGE and the hex code 0x40000002 staring back at you. I've seen this on everything from old XP boxes to brand-new Windows 11 laptops. The error means a process asked Windows for more memory than its working set quota allows. The kernel throws its hands up, and the process either dies or takes the whole system with it.

Common triggers I've seen in the field: someone copies a leftover /3GB switch into boot.ini after a RAM upgrade, a WSL2 instance with a low memory cap gets hammered by npm install, or a Hyper-V VM gets a static memory assignment that's too small for what's running inside it. Right, let's fix it.

Cause 1: A bad memory switch in boot.ini or BCD (most common)

This is the one I see most. On older Windows (XP, Server 2003) people added /3GB or /USERVA=xxxx to boot.ini to give 32-bit apps more address space. On modern Windows, someone copied the same habit into the boot configuration database using bcdedit. When the system boots with a truncatememory or increaseuserva value that doesn't match the actual hardware, working set limits get calculated wrongly and processes blow up with 0x40000002.

I've seen this on a Dell OptiPlex 790 running Windows 7 where a tech added truncatememory 0x80000000 to "test" something and forgot to remove it. Every Chrome tab crashed for a week.

Here's how to check and clear it:

1. Open an elevated Command Prompt. Right-click Start, pick Windows Terminal (Admin) or Command Prompt (Admin). You should see "Administrator:" in the title bar. If you don't, the commands below won't work.
2. Type bcdedit /enum {current} and press Enter. You'll get a list of boot settings for the current entry. Look for any of these lines: truncatememory, removememory, increaseuserva, maxmem. If you see them, that's your culprit.
3. Remove each one at a time. For example, if you saw truncatememory 0x80000000, run:

   bcdedit /deletevalue {current} truncatememory

4. If increaseuserva is set, clear it too:

   bcdedit /deletevalue {current} increaseuserva

5. Repeat for removememory and maxmem if they appear.
6. Reboot. You should see the normal Windows logo and no repeat of the error.

On very old XP systems, the file is C:\boot.ini. Open it in Notepad, find the line under [operating systems], and remove anything after /fastdetect that looks like /3GB or /USERVA=. Save, reboot.

Cause 2: The pagefile is too small or being managed badly

Windows uses the pagefile to back up working sets. When the pagefile is tiny — or when someone set a fixed size that's way too low — the kernel can't map in the memory a process wants, and you get 0x40000002. I've seen this most on VMs where the admin set the pagefile to 512 MB to "save disk space." Then SQL Server or a Java app starts, and boom.

The real fix is simple: let Windows manage it, or set a sane custom size. Here's the drill on Windows 10 or 11:

1. Press Windows + R, type sysdm.cpl, hit Enter. The System Properties window opens.
2. Click the Advanced tab. Under Performance, click Settings.
3. In Performance Options, click the Advanced tab again. Under Virtual memory, click Change.
4. Uncheck Automatically manage paging file size for all drives if it's checked. That sounds backwards, but I want you to see the current numbers first.
5. Select your system drive (usually C:). Look at the "Currently allocated" value. If it's under 2 GB on a system with 8 GB or more of RAM, that's your problem.
6. Pick System managed size, click Set, then OK. You'll be told to reboot. Do it.

If you're on a system where you must control the pagefile (some Citrix or VDI setups), a safe custom size is 1.5x your RAM for the initial size and 4x for the maximum. So on a 16 GB box: initial 24576 MB, max 65536 MB. Yes, that's a lot of disk. Buy more disk.

Cause 3: A Job Object or container is enforcing a tiny working set quota

This is the sneaky one. Windows lets programs create Job Objects that cap how much memory a whole group of processes can use. Docker Desktop, WSL2, IIS application pools, and various sandboxing tools all use them. If the quota is set too low, the moment a process inside wants a bigger working set, the Job Object says no, and you get 0x40000002.

A classic real-world case: a developer runs npm install inside a WSL2 distro that was capped at 2 GB in .wslconfig. Node's dependency tree spikes past that, and the whole distro dies with the error in the event log.

For WSL2, edit %UserProfile%\.wslconfig (create it if it doesn't exist) and raise the memory limit:

[wsl2]
memory=8GB
processors=4
swap=2GB

Save the file, then in an admin PowerShell run wsl --shutdown. Start your distro again. You should be able to run the same command without a crash.

For IIS, check the application pool's Private Memory Limit under Advanced Settings in IIS Manager. If it's set to something like 500000 KB (about 500 MB) on an app that needs more, raise it or set it to 0 (unlimited) and monitor. For Docker Desktop on Windows, open Settings → Resources and bump the memory slider. The default of 2 GB is fine for toy containers and useless for anything real.

If you're not sure what's enforcing the limit, open Task Manager, go to the Details tab, right-click the column header, and add the "Job object" column. Processes inside a job will show a non-empty value. That tells you where to look.

Quick reference

Work through these in order. Nine times out of ten the boot configuration is the culprit. The other one time, it's a quota someone set and forgot about. And once you've fixed it, resist the urge to "tune" memory settings later. Windows is pretty good at this on its own.