| Previous | Next |
| TPM_E_KEY_NOTSUPPORTED | TPM_E_AREA_LOCKED |
TPM_E_AUTH_CONFLICT
Which layer owns this HRESULT
TPM_E_AUTH_CONFLICT (0x8028003B) belongs to TPM 1.2 nonvolatile-storage policy. The base What Is page already shows the short Windows message; the additional diagnostic value is that this result marks an NV key blob requires two authorization relationships that the submitted TPM 1.2 command did not consistently provide.
Diagnostic record
| Question | Evidence for this HRESULT |
|---|---|
| What exact state was rejected? | an NV key blob requires two authorization relationships that the submitted TPM 1.2 command did not consistently provide |
| Which layer owns the result? | The TPM 1.2 NV permission and lifecycle checks. |
| What must be correlated? | owner authorization, blob authorization, session handles, entity types, nonce/HMAC inputs, and the exact NV_LoadKey form |
| What is the controlled comparison? | create separate fresh authorization sessions for both required entities and verify their placement in the request |
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.
How to verify the distinction
Use the following verification sequence:
- Capture the unmodified failing input and
0x8028003B. - Create separate fresh authorization sessions for both required entities and verify their placement in the request.
- 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.
Common false equivalences
| Other code | Why a different remedy follows |
|---|---|
TPM_E_AREA_LOCKED | The NV area is locked and not writtable — a separate checkpoint when compared with this result. |
TPM_E_KEY_NOTSUPPORTED | Wrong operation to load an NV key — a separate checkpoint when compared with it. |
TPM_E_BAD_LOCALITY | The locality is incorrect for the attempted operation — a separate checkpoint when compared with it. |
TPM_E_INVALID_AUTHHANDLE means a session handle is invalid; it means the authorization requirements conflict or are incomplete. The result difference determines whether to change serialization, authorization, resource lifetime, firmware/PPI state, command policy or only retry timing.
What a real fix looks like
Correct the original boundary by choosing this direction: supply both required authorizations in the defined order and avoid collapsing them into one cached session. Do not undefine a production NV index until its public attributes and authorization policy have been recorded. NV policy is established at definition time, and destructive recreation can remove counters, certificates or provisioning state.
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 — NV structures and permissions — source for the checkpoint.
- TCG: TPM 1.2 Part 3 — NV commands — source for the checkpoint.
- Microsoft: Win32_Tpm class — source for the checkpoint.
Looking for a different code? Search another status or error code.