| Previous | Next |
| MQ_ERROR_CANNOT_GET_DN | MQ_ERROR_CANNOT_SIGN_DATA_EX |
MQ_ERROR_CANNOT_HASH_DATA_EX
Operational meaning
MQ_ERROR_CANNOT_HASH_DATA_EX means authenticated message data cannot be hashed. Capture algorithm, provider, input lengths, and underlying cryptographic error before the message is signed.
Encryption capability and message authentication are related but distinct. When diagnosing this result, preserve provider, algorithm, certificate, key-container, and queue authentication/privacy settings rather than collapsing them into one “SSL” diagnosis.
MSMQ security material can live in the current user profile and be registered in directory services. Services running under another account or without a loaded profile can observe a different certificate-store state.
Where the condition occurs
| Subsystem | MSMQ message authentication, certificate registration, signing, hashing, and encryption |
|---|---|
| Relevant condition | certificate identity, key availability, provider capability, and message policy are independent checks |
| Code-specific focus | authenticated message data cannot be hashed |
Queue ACLs, certificate trust, private-key access, provider support, and destination authentication policy are independent. Test the layer named by the evidence. The code-specific boundary is authenticated message data cannot be hashed.
Evidence to preserve
- Whether the failure occurred while preparing, sending, storing, or validating the message.
- Certificate store location and security identity used by the process.
- Provider name/type, hash algorithm, and privacy/authentication properties.
Handling and recovery
Do not regenerate certificates until hash creation and data access are tested.
Nearby failures
Authentication failure is not synonymous with queue access denial. Certificate stores, private keys, providers, signatures, and queue policy must be tested separately. Code-specific condition: authenticated message data cannot be hashed.
Worked example
A secure connector encounters it. It tests store and private-key access under the production identity before changing queue security.
Hash-stage evidence
Separate acquisition of a cryptographic provider from creation of a hash object and from feeding message bytes into that object. Record the provider type, hash algorithm property, byte counts for authenticated message fields, and the native CryptoAPI error immediately following the MSMQ call. A certificate can be present and its private key can be readable while the selected provider still refuses the requested hash algorithm or input operation.
- Confirm that the message property arrays remain valid for the entire native call and that lengths are expressed in the units required by each property.
- Compare a minimal authenticated message with the production message to isolate a particular extension, connector field, or serialized body segment.
- Do not publish or log the message body merely to diagnose hashing; a cryptographic digest and lengths normally provide safer correlation.
References
Looking for a different code? Search another status or error code.