| Previous | Next |
| SEC_E_INSUFFICIENT_MEMORY | SEC_E_UNSUPPORTED_FUNCTION |
SEC_E_INVALID_HANDLE
Meaning and context of SEC_E_INVALID_HANDLE
The AcceptSecurityContext (CredSSP) function is the server counterpart to the InitializeSecurityContext (CredSSP) function.
When the server receives a request from a client, it uses the fContextReq parameter to specify what it requires of the session. In this fashion, a server can require that clients be capable of using a confidential or integrity-checked session; it can reject clients that cannot meet that demand. Alternatively, a server can require nothing; whatever the client requires or can provide is returned in the pfContextAttr parameter.
The fContextReq and pfContextAttr parameters are bitmasks that represent various context attributes. For a description of the various attributes, see Context Requirements.
The caller is responsible for determining whether the final context attributes are sufficient. For example, if confidentiality (encryption) was requested but could not be established, some applications may choose to shut down the connection immediately. If the security context cannot be established, the server must free the partially created context by calling the DeleteSecurityContext function. For information about when to call the DeleteSecurityContext function, see DeleteSecurityContext.
After the security context has been established, the server application can use the QuerySecurityContextToken function to retrieve a handle to the user account to which the client certificate was mapped. Also, the server can use the ImpersonateSecurityContext function to impersonate the user.
The function returns SEC_E_INVALID_HANDLE (0x80100003L) if the handle passed to the function is not valid.
Diagnostic interpretation of SEC_E_INVALID_HANDLE
SEC_E_INVALID_HANDLE has the HRESULT value 0x80090301. AllStat records the condition as “The handle specified is invalid”. In practice, interpret that wording at the boundary owned by SSPI authentication or security-package negotiation, rather than treating the value as a generic Windows message.
Evidence to capture for SEC_E_INVALID_HANDLE
- Record the exact COM method or Windows API, its input object, the calling thread, and the full 0x80090301 value before a wrapper converts it to an exception or Boolean result.
- Capture any IErrorInfo text, activity identifier, event-log entry, and subsystem trace that mentions SEC_E_INVALID_HANDLE or the sec / handle operation.
- For SEC_E_INVALID_HANDLE, check the documented return contract of the specific API because the same HRESULT can require different recovery in different interfaces.
Retry and recovery for SEC_E_INVALID_HANDLE
Retry SEC_E_INVALID_HANDLE only when the owning API documents a transient state or after the condition described as “The handle specified is invalid” has changed. For SEC_E_INVALID_HANDLE, configuration, policy, format, and authorization failures normally require correction first; an immediate loop can hide the original call site and add secondary errors.
Official references for SEC_E_INVALID_HANDLE
Looking for a different code? Search another status or error code.