| Previous | Next |
| SL_E_INVALID_PRODUCT_KEY_TYPE | SL_E_CIDIID_NOT_BOUND |
SL_E_CIDIID_MISMATCHED_PKEY
The licensing boundary behind the code
SL_E_CIDIID_MISMATCHED_PKEY belongs to offline IID/CID activation. The producing mechanism is the offline activation exchange in which an Installation ID is generated for one activation context and a Confirmation ID is returned for that same context. The important the boundary is: the offline IID/CID exchange belongs to a product key different from the key currently selected for activation.
Record both this result and 0xC004F07E. Licensing wrappers often preserve only a friendly message, but the facility value is what separates key, KMS, certificate, offline, OEM, Store, and state-machine failures.
This result should be read against these rules: for this HRESULT: The Installation ID must be obtained before the Confirmation ID is deposited; the returned CID is tied to the activation context represented by that IID. for this HRESULT: Formatting errors, unsupported versions, mismatched IDs, and a failure to save a valid CID occur at different points and should not be merged into one “telephone activation failed” message.
Evidence to preserve before changing anything
The decisive record is to capture partial product key, Product ID, Activation ID, key-change history, IID generation timestamp, and CID request record. Before changing the system for this HRESULT, add the following context:
- Product identity for this HRESULT: exact slmgr or API operation and Software Protection event.
- Activation context for this HRESULT: Activation ID selected for /dti and /atp.
- State at failure for this HRESULT: IID and CID length/version without publishing the complete identifiers.
- Correlation evidence for this HRESULT: partial product key and edition/channel.
- Change history for this HRESULT: hardware or environment change between IID generation and CID deposit.
When investigating this result, protect secrets while collecting evidence. Full product keys, complete IID/CID values, private keys, PINs, challenge blobs, account credentials, and unredacted certificate material for this HRESULT do not belong in public tickets. Partial keys, hashes, thumbprints, IDs, timestamps, and state transitions are normally enough to correlate the failure.
Related outcomes and why they are not equivalent
| Result | Different boundary |
|---|---|
SL_E_CIDIID_NOT_BOUND | Relative to this result: the offline identifiers do not bind to the machine environment currently presenting them. |
SL_E_CIDIID_INVALID_CHECK_DIGITS | Relative to it: the local Software Protection Platform detects invalid integrity digits in the supplied IID/CID value. |
SL_E_CIDIID_MISMATCHED | Relative to it: the Confirmation ID was issued for a different Installation ID than the one represented by the current request. |
When it appears with related results, order them by timestamp and Activation ID. The earliest code at the producing boundary usually carries more diagnostic value than a later summary state.
Work from state to cause
- Preserve it,
0xC004F07E, timestamp, caller, and the exact licensing method. - read the current product state before making changes, including key channel, LicenseStatusReason, and relevant time or binding data.
- test the producing boundary directly: capture partial product key, Product ID, Activation ID, key-change history, IID generation timestamp, and CID request record.
- do not continue until the evidence supports this distinction: the IID/CID pair can match each other yet still target the wrong installed key.
- perform the targeted action, then repeat the same query/activation path and compare state, events, and expiry/renewal information.
Do not infer the cause of it from the activation UI alone. The IID/CID pair can match each other yet still target the wrong installed key. Preserve the boundary when converting the HRESULT into user-facing diagnostics.
Actions that usually make this harder to diagnose
- While diagnosing it, avoid reusing a CID produced for another IID, product key, or machine state. That action changes evidence for this HRESULT without correcting the established boundary.
- avoid posting complete installation or confirmation identifiers in public logs. The result already narrows the problem more precisely.
- do not delete licensing stores, edit signed license files, alter firmware markers, bypass certificate checks, or use unofficial activation tools. During investigation, those actions can create a second integrity problem and destroy the evidence needed to repair the legitimate license.
The narrow remediation path
Recovery should preserve entitlement and state rather than erase symptoms. In this case, install/select the intended key first, generate a new IID, and obtain a CID for that key context; then query the same product instance and retain the post-fix it HRESULT and status.
Representative failure: A product key is changed after /dti, but the previously obtained CID is then deposited.
Verification after the change
Build a regression case that intentionally creates “the offline IID/CID exchange belongs to a product key different from the key currently selected for activation” and asserts it. The corrected the case should change only the decisive input, then verify the same Activation ID, final LicenseStatus/Reason, and any relevant grace, renewal, certificate, binding, or expiry data.
Technical references
- Slmgr.vbs activation options — platform behavior relevant to it.
- Microsoft activation error-code troubleshooting — diagnostic and operational context for this HRESULT.
- ActivateOffline WMI method — supported tools and state fields used to verify it.
- SoftwareLicensingProduct WMI class — Microsoft guidance for the activation mechanism represented by it.
Looking for a different code? Search another status or error code.