0x486—Process exhausted all Windows manager handles

What's actually happening

Windows gives each process a fixed pool for Windows manager objects — things like menus, cursors, icons, and window classes. When your process hits that limit, any call to create another one returns ERROR_NO_MORE_USER_HANDLES (0x00000486). The limit per process on modern Windows (10/11) is 10,000 handles by default. That sounds generous, but buggy apps — especially ones that repeatedly create and don't destroy menus or cursors — chew through them fast.

You'll see this most often in legacy business apps, Electron-based applications that go rogue with tray icons, or custom software that loads and unloads UI resources without cleanup. One developer I talked to hit it running an old VB6 app that created a new menu handle every time a user right-clicked and never called DestroyMenu().

The 30-second fix: restart the offending process

Before you go hunting for leaks, just kill the app showing the error and relaunch it. That frees every handle the process held, because the OS cleans up on process termination. If the error came from a background process — say, a system tray utility — look in Task Manager's Details tab for the process name, right-click, and choose End task.

If the error was from Explorer itself (unlikely but possible), restart Explorer: open Task Manager, find Windows Explorer, right-click, and choose Restart. Your taskbar and desktop will flicker and come back.

Why this works: When a process exits, Windows walks its handle table and closes every open handle, including USER handles. The next launch starts fresh with a clean slate. If the error returns within minutes, you've got a leak — move to the next step.

The 5-minute fix: identify the leak

You need to confirm which process is eating handles and how many. Process Explorer (from Microsoft Sysinternals, free) shows USER handle counts per process. Task Manager can show GDI handles but not USER handles directly, so skip it here.

1. Download and run Process Explorer.
2. Add the USER Handles column: View → Select Columns → Process Performance tab → check USER Handles.
3. Sort by USER Handles descending. Look for any process with >8,000 handles, or one that steadily climbs when you use the app.
4. Watch the leak live: in Process Explorer, right-click the process → Properties → Performance tab. The USER Handles graph should be flat or slowly rising. If it spikes every time you click a button, you've found the culprit.

Common offenders:

• explorer.exe — can leak if you have many shell extensions. Restart it.
• Your specific app — check for updates or contact the vendor. A handle leak is a bug.
• Third-party mouse or keyboard utilities — Logitech Options, Corsair iCUE, and similar tools are notorious for leaking icon and cursor handles.

If the leak is in a non-essential background app, uninstall or disable it. For a critical app, you're stuck with the advanced fix.

The 15-minute fix: adjust the desktop heap (advanced)

Windows divides its USER handle budget into desktop heaps. Each interactive desktop gets a heap, and all processes on that desktop share its pool. If you're hitting the limit because many processes each use thousands of handles, you can increase the heap size — but this is a system-wide registry change and can destabilize things.

Only do this if:

• You've confirmed no single process is leaking (all stay under 5,000 handles).
• You're running a server or terminal server where dozens of processes legitimately need many USER handles.
• You're comfortable rebooting and reverting the change if things go south.

Steps

1. Open Regedit as administrator.
2. Navigate to:
   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\SubSystems
3. Double-click the Windows string value. Its data looks like:
   

   %SystemRoot%\system32\csrss.exe ObjectDirectory=\Windows SharedSection=1024,3072,512 Windows=On SubSystemType=Windows ServerDll=basesrv,1 ServerDll=winsrv:UserServerDllInitialization,3 ServerDll=winsrv:ConServerDllInitialization,2 ProfileControl=Off MaxRequestThreads=16

4. The SharedSection values (comma-separated) are: CSRSS heap, desktop heap for non-interactive, desktop heap for interactive. The third value (interactive desktop) is what matters. Default is 512 on most systems.
5. Increase the third value by 256 at a time — so change 512 to 768. Never go above 2048, or you risk system instability.
6. Click OK, close Regedit, and reboot.

Why this works: Each desktop heap is a chunk of memory where USER handles live. A bigger heap means more handles can exist simultaneously. But Windows locks the heap size at boot — you can't change it without a restart. And increasing it reduces the number of available desktops (for terminal servers), so test carefully.

Revert by setting the third value back to 512 and rebooting.

When to give up

If none of this helps, the app is leaking handles in a way you can't patch. Look for an update, a hotfix, or a workaround (like running the app inside a vbs wrapper that restarts it when it hits the limit). The handle limit per process is baked into the Windows kernel — you can't bypass it without writing a driver, and that's not practical here.