What does HRESULT 0xC004C764 (SL_E_CHPA_UNKNOWN_PRODUCT_KEY_TYPE) mean?

 
Previous Next
SL_E_CHPA_FAILED_TO_DELETE_PRODUCT_KEY_PROPERTY SL_E_CHPA_PRODUCT_KEY_BEING_USED

SL_E_CHPA_UNKNOWN_PRODUCT_KEY_TYPE

The exact failure boundary

HRESULT 0xC004C764 is exposed as SL_E_CHPA_UNKNOWN_PRODUCT_KEY_TYPE by the CHPA activation-server workflow. The code says more than the friendly message: the server does not recognize the product-key type named by the request or stored record.

The CHPA layer evaluates key type, binding, business-rule inputs and persistent key data. Its insert, update and delete failures need server correlation; repeating slmgr on the client cannot repair a failed server transaction. The code is not interchangeable with a recognized type that is unsupported for the selected activation operation.

AllStat records “The activation server reported that the product key type is unknown” for this HRESULT. That identifies the official outcome; the additional value is the producing object, evidence set, nearby conditions and safe verification path.

How the request reaches this stage

StageRole for this HRESULT
CHPA inputThe server receives a key-management or activation payload with business-rule inputs.
Schema and rule evaluationKey type, properties, bindings and program rules are validated before the operation can commit.
Persistent operationInsert, update, delete or lookup state is part of the producing boundary for this HRESULT.
Server responseThe client sees this result after CHPA rejects or cannot persist the requested change.

A later unlicensed, notification or grace-state message describes a consequence. Preserve the earliest event carrying this HRESULT for the same product object or service request.

What the constant itself tells you

  • The CHPA prefix places the result in server business-rule or product-key data processing.
  • product/key identity must remain tied to the exact SKU and Activation ID.
  • The suffix names the object or transition to inspect before any broad activation reset.
  • Its HRESULT severity is failure; later status messages can describe only the resulting state.

Inputs worth preserving

EvidenceQuestion answered
activation request ID and CHPA/server timestampFor this HRESULT: Which CHPA entity was being inserted, updated, deleted or queried?
product-key record identity and key typeFor this HRESULT: Did schema validation finish before persistence was attempted?
business-rule name or server operationFor this HRESULT: Is another transaction using the same product-key record?
caller identity and elevationFor this HRESULT: Can whether a clean reboot reproduces the result without modifying state be captured before changing state?
whether a clean reboot reproduces the result without modifying stateFor this HRESULT: Does the evidence support “identify the authoritative channel/type and align client and server schema versions” rather than a recognized type that is unsupported for the selected activation operation?

Redact full keys, activation blobs, account tokens, private certificate material and raw hardware identifiers. Partial keys, hashes, IDs and UTC timestamps retain correlation value without publishing secrets.

Triage without destroying evidence

  1. Capture caller identity and elevation specifically for this HRESULT.
  2. Prove the distinction between the named boundary and a recognized type that is unsupported for the selected activation operation before remediation.
  3. After one supported change, repeat the same operation and compare state, events and response correlation for this HRESULT.
  4. Bind this result to the exact Application ID, Activation ID, edition and partial key.
  5. Record 0xC004C764, UTC time, caller and the first method or server request that returned it.
REM Evidence context: SL_E_CHPA_UNKNOWN_PRODUCT_KEY_TYPE
cscript %windir%\system32\slmgr.vbs /dlv
cscript %windir%\system32\slmgr.vbs /ato

Use the status output as evidence. Run an activation retry only after the collected state supports the identified prerequisite; blind retries can add quota, throttle or cleanup noise.

Results that require different fixes

ResultDifferent condition
SL_E_CHPA_FAILED_TO_DELETE_PRODUCT_KEY_PROPERTYthe server cannot remove an existing property from the product-key record
SL_E_CHPA_FAILED_TO_UPDATE_PRODUCT_KEY_PROPERTYthe server cannot commit a change to an existing product-key property
SL_E_CHPA_FAILED_TO_INSERT_PRODUCT_KEY_PROPERTYthe server cannot add a new property to a product-key record

A focused reproduction for this exact result

ControlDesign
Failing fixtureA deployment labels a key with a custom or newer type unknown to CHPA.
Single variableChange only the narrow input or state named by the HRESULT while product identity remains fixed.
Positive controlA known-good value at that boundary succeeds and the failing fixture still reproduces the code.
Different resultIf the experiment instead proves “the server cannot remove an existing property from the product-key record”, follow that neighboring boundary rather than treating it as this result.

This controlled comparison is stronger than a broad reset because it changes one prerequisite and leaves product identity, evidence source and observation method stable.

Supported correction and proof

A supported correction is to identify the authoritative channel/type and align client and server schema versions. A representative incident is a deployment labels a key with a custom or newer type unknown to CHPA.

Changes that make this code harder to diagnose

  • avoid editing server XML or properties without preserving the rejected payload; it changes evidence without proving the named boundary.
  • avoid treating a failed database operation as a client connectivity problem; it changes evidence without proving the named boundary.
  • avoid launching parallel requests against the same key record; it changes evidence without proving the named boundary.

Technical references


Looking for a different code? Search another status or error code.