| Previous | Next |
| ERROR_DOMAIN_TRUST_INCONSISTENT | ERROR_RESOURCE_DATA_NOT_FOUND |
ERROR_SERVER_HAS_OPEN_HANDLES
The server remains in use by active handles.
ERROR_SERVER_HAS_OPEN_HANDLES is Win32 error 1811 (0x713). It is a lifecycle guard: an operation is trying to unload, detach, delete, or reconfigure a server-side resource while one or more clients still reference objects provided through that server. “Server” here is contextual and can refer to a service or server component rather than a physical computer.
Why handles remain active
- a client process still has a file, pipe, printer, RPC, or management handle open
- a background worker or service retained a reference after the visible task completed
- a disconnected network session has not yet been cleaned up by the owning service
- shutdown ordering asks the provider to unload before dependent objects are released
- a failed operation leaked a handle or skipped its normal close path
Usage state to log
Record the exact unload or removal API, server or provider identity, caller process, outstanding session and open-file counts when available, handle type, owner process or client, creation time, and shutdown phase. Use operating-system handle and service diagnostics instead of dumping opaque pointer values alone. Paths and client names can be sensitive and should follow the product’s diagnostic redaction policy.
How to locate the owner
First stop accepting new work and reproduce the failure while monitoring the component’s reference count, sessions, and open objects. Enumerate supported server sessions or open resources where the subsystem exposes that information. For a local service, trace handle creation and closure and inspect which process owns the remaining kernel handles.
Distinguish a legitimate long-running client from a leak. If the count falls after a normal client exits, coordinate a drain. If it never falls, follow error and cancellation paths in the owner. Do not terminate unrelated processes based solely on a matching filename or connection.
Safe unload procedure
Quiesce new requests, notify or disconnect clients according to the service contract, wait for active operations to complete, close dependent objects, and retry the unload. Force closure only when data-loss and application-impact risks are understood. A reboot can clear handles but should not substitute for identifying a repeatable leak.
Developers should make shutdown ordering explicit, expose useful active-reference metrics, cancel operations before destroying their provider, and guarantee handle closure on every failure path. Administrators should schedule disruptive unloading outside active use.
Difference from access denied
Access denied means the caller lacks permission. Error 1811 means the requested lifecycle transition is unsafe because the component is still referenced; granting more privilege does not close those references.
Example
An administrator tries to remove a server transport while a monitoring agent still owns a management handle. The operation returns 1811. After the agent is stopped and its session disappears, the transport can be removed cleanly. Repeated elevated retries while the handle remained open would have produced the same result.
References
Looking for a different code? Search another status or error code.