Fix ERROR_NOT_ENOUGH_QUOTA (0x718) on Windows Server

You're remoted into a Windows Server box—maybe 2016 or 2019—and suddenly apps start failing. Outlook won't open, or you get a popup that says "Not enough quota is available to process this command" with error code 0x00000718. Sometimes it happens right after you log in, sometimes it's after a few hours of heavy use. The server isn't out of RAM or disk. It's a desktop heap problem, and I've seen it bring down entire RDS farms because nobody knew where to look.

What's actually going on

Every interactive session on Windows gets a small slice of memory called a desktop heap. It's used for UI elements—windows, menus, buttons—and it's separate from the regular memory pool. When that heap fills up, Windows throws ERROR_NOT_ENOUGH_QUOTA. The number of sessions you can run is limited by a kernel parameter that, by default, is set way too conservative for modern servers.

I had a client last month running a Terminal Server with 50 users. Everything worked fine until lunchtime, then people started getting that error and couldn't open new windows. Rebooting fixed it temporarily, but it came back every day. The real fix is bumping up the desktop heap allocation in the registry.

The fix: increase the SharedSection value

You need to edit the SharedSection value under Windows NT\CurrentVersion\Windows. This is a known Microsoft-supported tweak, but they don't make it obvious. Here's what to do:

Press Win + R, type regedit, and hit Enter. Accept the UAC prompt.

Go to:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows

Find the SharedSection string value (REG_SZ). It looks something like:
```
SharedSection=1024,20480,768
```
The second number (20480) is the one we care about—that's the heap size in kilobytes for each interactive session.
Double-click it and change the second number to 40960 (that's 40 MB). If you only see two numbers, add the third as 1024 if it's missing (rare, but happens). So you'd have:
```
SharedSection=1024,40960,768
```
Click OK, close regedit, and reboot the server. This change doesn't apply until a restart.

I usually go straight to 40960 for servers with more than 20 active sessions. For smaller setups, 30720 might be enough, but since you're already in there, just do the bigger number. It's not going to hurt anything—Windows will only use it if needed.

Why this works

Each desktop heap is allocated from a shared kernel pool. The default of 20 MB per session sounds like a lot, but with modern apps that create dozens of windows (browsers, Office, custom business software), it gets exhausted fast. By doubling that value, you're giving each session more room before hitting the wall. It's a crude fix, but it's the one Microsoft has supported since the Windows 2000 days, and it still applies to Windows Server 2022.

What if it still happens?

If you've made the change and the error persists, check a couple of things:

Are you actually at the session limit? If you're running RDS, the number of sessions might be limited by licensing. The error can be misleading. Check Event Viewer for Terminal Services events.
Is it only one specific app? Some apps are greedy with windows. If it's always the same program (like a legacy database client), the problem might be there, not the desktop heap. Try that app on a fresh session to confirm.
Did you reboot? This is the one I forget myself. The registry change takes effect only after a full restart, not just a logoff.

If you still see 0x718 after all that, you might be hitting a different quota entirely—like GDI object limits. But in my experience, the SharedSection tweak solves 9 out of 10 cases. I've fixed entire server rooms with this one registry edit.