| Previous | Next |
| NAP_E_NO_CACHED_SOH | NAP_E_NOT_REGISTERED |
NAP_E_STILL_BOUND
The NAP entity is still bound during unregistration
NAP_E_STILL_BOUND is HRESULT 0x80270005 (signed decimal -2144927739, unsigned decimal 2150039557). AllStat, using winerror.h, describes it as “The entity is still bound to the NAP system.” The value has failure severity, facility 0x27, and code field 0x0005.
This is a legacy Network Access Protection result: Microsoft states that NAP is unavailable starting with Windows 10 and that current Windows Server releases do not include the former NAP, HRA, and HCAP roles; use the code for supported legacy systems, archived telemetry, compatibility components, or migrations rather than assuming a modern machine should expose the old platform.
Teardown has not reached the registration boundary
Microsoft lists this result for INapClientManagement::UnregisterEnforcementClient when the enforcement client remains attached to the NAP system. Registration and runtime binding are separate lifetimes: removing metadata while callbacks or connections still reference the component would leave the agent with an invalid target, so unregistration is rejected.
Bindings that commonly remain active
- The enforcement client did not call the matching uninitialize or unbind operation before its installer attempted unregister.
- One or more INapEnforcementClientConnection objects are still active or retained by a worker thread.
- Shutdown raced with a callback, leaving the component logically bound until the callback releases its reference.
- A service process from the previous version is still running while an upgrade executes the registration change.
- Cleanup handled the normal path but skipped unbinding after partial initialization or a failed connection.
Lifetime evidence
- Record process IDs, service state, binding instance IDs, active connection IDs, callback counts, and COM reference ownership.
- Trace the order of stop, connection close, uninitialize, object release, and unregister operations.
- Identify whether the binding belongs to the component being removed or to another process using the same registered entity.
- Capture installer phase and any pending restart marker; a replacement binary must not be registered over a live old process.
Safe teardown sequence
- Stop admitting new enforcement connections and mark the component as draining.
- Complete or cancel outstanding requests according to their contract, then release each connection object.
- Unbind from NapAgent and wait for callback quiescence before releasing the binding interface.
- Only after runtime ownership is gone should UnregisterEnforcementClient be retried.
Difference from nearby NAP results
NAP_E_CONFLICTING_ID occurs when creating a registration whose ID is already owned; this result occurs while removing an existing owner that is still in use. NAP_E_SERVICE_NOT_RUNNING concerns NapAgent availability and does not prove that all local references have been released.
Retry and recovery
A bounded retry after confirmed callback and connection drain is reasonable. Repeated unregister attempts while the process remains bound are deterministic and can obscure the object that owns the reference. If cleanup cannot complete in-process, stop the component cleanly or schedule registration removal after restart rather than editing the registration store by hand.
Practical scenario
An upgrade service tries to unregister an enforcement client before stopping its old Windows service. The client still owns two connection objects, so this result is returned. The installer stops the service, waits for connection teardown, unregisters the old entity, and then registers the replacement version.
References
- Microsoft: NAP error constants
- Microsoft: UnregisterEnforcementClient
- Microsoft: enforcement client connection
- Microsoft: NAP interfaces
Looking for a different code? Search another status or error code.