| Previous | Next |
| TPM_E_INVALID_KEYUSAGE | TPM_E_INVALID_POSTINIT |
TPM_E_WRONG_ENTITYTYPE
Interpret the boundary first
TPM_E_WRONG_ENTITYTYPE (0x80280025) belongs to TPM 1.2 command processing. The base What Is page already shows the short Windows message; the additional diagnostic value is that this result marks the authorization or delegation request names an entity class that the selected TPM 1.2 command does not accept.
The first producer to identify for this HRESULT is the TPM 1.2 command decoder and state machine. TPM 1.2 is a command/response device with strict binary structures and stateful resources. Windows may present the device response as an HRESULT, but the diagnostic meaning still belongs to the command field, key, session, PCR, NV index or lifecycle check named by the TPM specification.
Build the command transcript
| Question | Evidence for this HRESULT |
|---|---|
| What exact state was rejected? | the authorization or delegation request names an entity class that the selected TPM 1.2 command does not accept |
| Which layer owns the result? | The TPM 1.2 command decoder and state machine. |
| What must be correlated? | entityType, entityValue, command ordinal, session creation command, key/NV/counter identity, and the library structure used to serialize them |
| What is the controlled comparison? | construct the same authorization flow with the entity type documented for that command and keep the authorization secret unchanged |
Separate caller data from platform state. The result caller data includes the command, structures, lengths, handles and flags; platform state includes TPM generation, provisioning, locality, lockout, resource inventory, firmware and the TBS service lifecycle. This result is actionable only after the rejected side is identified.
Test one hypothesis
Use the following verification sequence:
- Capture the unmodified failing input and
0x80280025. - Construct the same authorization flow with the entity type documented for that command and keep the authorization secret unchanged.
- Compare the first result divergent field or state transition.
- Repeat this result only after restoring the same baseline, with a bounded retry policy where the specification permits retry.
Do not merge these conditions
| Other code | Why a different remedy follows |
|---|---|
TPM_E_INVALID_POSTINIT | The command was received in the wrong sequence relative to TPM_Init and a subsequent TPM_Startup — a separate checkpoint when compared with this result. |
TPM_E_INVALID_KEYUSAGE | The usage of a key is not allowed — a separate checkpoint when compared with it. |
TPM_E_INAPPROPRIATE_SIG | Signed data cannot include additional DER information — a separate checkpoint when compared with it. |
TPM_E_INVALID_AUTHHANDLE concerns the session handle; it concerns the type of object being authorized. The result difference determines whether to change serialization, authorization, resource lifetime, firmware/PPI state, command policy or only retry timing.
A safe recovery path
Correct the original boundary by choosing this direction: correct the entity selector and rebuild the session or delegation blob rather than retrying an incompatible entity class. Do not clear ownership, delete keys or reset PCR-related state merely to see whether the message disappears; those actions can destroy the evidence and protected material while leaving serialization or command-order defects unchanged.
A successful it outcome preserves the intended hardware trust boundary, passes the original request, and produces verifiable output. Masking it, swallowing this HRESULT or switching silently to a software provider is not remediation.
References used for this checkpoint
- TCG: TPM 1.2 Main Specification — source for the checkpoint.
- TCG: TPM 1.2 Part 2 — Structures — source for the checkpoint.
- TCG: TPM 1.2 Part 3 — Commands — source for the checkpoint.
- Microsoft: TPM Base Services portal — source for the checkpoint.
Looking for a different code? Search another status or error code.