| Previous | Next |
| CRYPT_E_RECIPIENT_NOT_FOUND | CRYPT_E_ISSUER_SERIALNUMBER |
CRYPT_E_CONTROL_TYPE
The caller passed an unsupported or inappropriate control type to a cryptographic-message operation.
What to check for CRYPT_E_CONTROL_TYPE
- Log the selected CryptMsgControl command and the current message type.
- Confirm that the control is valid for the message state and that its control-parameter structure matches the command.
- Use the documented control only for the CMS message form it supports.
Microsoft: CryptMsgOpenToDecode
Diagnostic interpretation of CRYPT_E_CONTROL_TYPE
CRYPT_E_CONTROL_TYPE has the HRESULT value 0x8009100C. AllStat records the condition as “Invalid control type.”. For CRYPT_E_CONTROL_TYPE, in practice, interpret that wording at the boundary owned by cryptography, certificate, trust, or key-provider processing, rather than treating the value as a generic Windows message.
Evidence to capture for CRYPT_E_CONTROL_TYPE
- Record the exact COM method or Windows API, its input object, the calling thread, and the full 0x8009100C 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 CRYPT_E_CONTROL_TYPE or the crypt / control / type operation.
- For CRYPT_E_CONTROL_TYPE, check the documented return contract of the specific API because the same HRESULT can require different recovery in different interfaces.
Retry and recovery for CRYPT_E_CONTROL_TYPE
Retry CRYPT_E_CONTROL_TYPE only when the owning API documents a transient state or after the condition described as “Invalid control type.” has changed. For CRYPT_E_CONTROL_TYPE, configuration, policy, format, and authorization failures normally require correction first; an immediate loop can hide the original call site and add secondary errors.
Looking for a different code? Search another status or error code.