| Previous | Next |
| SL_REMAPPING_SP_PUB_CRYPTO_KEY_NOT_AVAILABLE | SL_REMAPPING_SP_PUB_CRYPTO_NOT_BLOCK_ALIGNED |
SL_REMAPPING_SP_PUB_CRYPTO_KEY_NOT_FOUND
Where the failure occurs in Software Protection Platform
0xC004D20B maps to SL_REMAPPING_SP_PUB_CRYPTO_KEY_NOT_FOUND. This result belongs to cryptographic processing inside the security processor and narrows the operation to the provider, algorithm, key, hash, signature and block-processing stage used to authenticate protected licensing data. In concrete terms, the selected provider has no key object for the requested identifier.
This distinction matters because the key is absent, rather than present but unavailable due to state. A later “not licensed” state should not replace the first exact HRESULT in logs.
Where it sits in the licensing pipeline
Algorithm selection, key lookup, block formatting and signature verification are independent boundaries; a failure in one does not prove corruption at the others. To verify this, record provider/key IDs, expected provisioning source, creation/import events and namespace.
Cryptographic material should be logged by identifier, length, hash or thumbprint rather than by exporting secret keys or plaintext protected data.
Inputs that distinguish this condition
- cipher mode, block size and padding mode
- hash state and digest length
- signature format, length and verification key
- provider and algorithm identifiers
- key type and key-material length
Why the symbolic code matters
| Result | Different condition |
|---|---|
SL_REMAPPING_SP_PUB_CRYPTO_KEY_NOT_AVAILABLE | Compared with this result, the key identifier is known but the key cannot be used in the current protected state. |
SL_REMAPPING_SP_PUB_CRYPTO_NOT_BLOCK_ALIGNED | Compared with this result, input length is not a whole multiple of the cipher block size for a mode that requires aligned data. |
SL_REMAPPING_SP_PUB_CRYPTO_HASH_FINALIZED | Compared with it, additional data was supplied after the hash object had already been finalized. |
A reproducible troubleshooting path
- Identify the caller and operation instance that produced
0xC004D20B. - Collect the code-specific evidence: record provider/key IDs, expected provisioning source, creation/import events and namespace.
Safe recovery direction
Provision or import the authorized key and verify persistence before repeating the operation.
Representative case: A restored store references a key that was never restored with it.
Actions that usually destroy useful evidence
- Do not publish keys, decrypted license blobs or complete protected payloads in a support ticket.
- Do not disable signature or padding validation to make the operation continue.
Technical references
- CNG cryptographic primitive functions — supported state, API or recovery information relevant to this HRESULT.
- BCryptHashData — reference for evidence collection and post-repair verification.
- BCryptVerifySignature — technical contract for the subsystem producing it.
- Signing data with CNG — official platform context used to interpret it.
Looking for a different code? Search another status or error code.