| Previous | Next |
| ERROR_DLL_NOT_FOUND | ERROR_MESSAGE_SYNC_ONLY |
ERROR_NO_MORE_USER_HANDLES
The process exhausted its USER-object allowance.
ERROR_NO_MORE_USER_HANDLES is error 1158 (0x486). It reports exhaustion of handles for Window Manager, or USER, objects in the current process. It is not a generic statement that every Windows handle table is full, and it should not be confused with GDI-object exhaustion or ordinary virtual-memory pressure.
Objects and symptoms to investigate
- windows and child controls created repeatedly without destruction
- menus, cursors, icons, accelerator tables, hooks, or other USER resources whose lifetime is unbounded
- dialogs reopened many times while hidden instances remain alive
- UI automation or plug-ins that create objects on worker desktops and never release them
- a long-running desktop process whose USER-object count rises after each task
Once the quota is reached, unrelated GUI calls can begin failing: window creation, dialog display, menu construction, or message-related setup may all be affected. The visible failure can therefore occur far from the original leak.
Measure the correct resource
Use GetGuiResources with GR_USEROBJECTS to sample the process count, and record both current and peak values when available. Compare that series with GR_GDIOBJECTS rather than assuming the two resource classes move together. Process Explorer or Task Manager can provide supporting observations, but application telemetry is more useful for correlating growth with a specific workflow.
Evidence for a leak investigation
- process ID, session ID, uptime, USER-object count, and GDI-object count
- the operation count or UI action performed between samples
- thread and plug-in responsible for creating the affected object type
- counts before and after closing documents, dialogs, and child windows
- a dump captured before emergency restart, while object ownership still exists
Recovery versus repair
Restarting the process releases its USER objects and may restore service temporarily, but it does not correct the lifetime defect. Raising USERProcessHandleQuota can postpone the failure and increase pressure on the shared session; it should not be the first response to a steadily increasing per-process count.
The proper fix pairs every creation path with destruction on success, failure, cancellation, and exception exits. UI caches need explicit limits, and plug-in interfaces should define which side owns returned handles. Automated tests can loop the suspected workflow and assert that the count returns near its baseline.
Operational handling
If restart is unavoidable, capture resource counts and a dump first, then restart only the leaking process rather than the entire machine. On Remote Desktop Session Host systems, also identify the affected session because USER resources are session-scoped and multiple GUI processes may contribute to overall pressure.
Distinguishing related failures
ERROR_NOT_ENOUGH_MEMORY is broader and does not identify USER objects. A failure involving pens, brushes, bitmaps, or device contexts points toward GDI resources instead. Error 1158 specifically identifies the process allowance for Window Manager objects.
Example
A monitoring console creates a hidden notification window whenever a device reconnects and never destroys the previous one. Memory remains almost flat, but GR_USEROBJECTS climbs by one per reconnect until new dialogs fail with 1158. Adding deterministic window destruction and a stress test that repeats reconnects fixes the cause; increasing the quota only delays it.
References
- Microsoft: System Error Codes (1000–1299)
- Microsoft: User Objects
- Microsoft: GetGuiResources function
Looking for a different code? Search another status or error code.