| Previous | Next |
| TPM_E_DELEGATE_ADMIN | TPM_E_OWNER_CONTROL |
TPM_E_TRANSPORT_NOTEXCLUSIVE
Where the failure is raised
TPM_E_TRANSPORT_NOTEXCLUSIVE (0x8028004E) belongs to TPM 1.2 resources, delegation and contexts. The base What Is page already shows the short Windows message; the additional diagnostic value is that this result marks an exclusive TPM 1.2 transport session lost exclusivity because another command executed outside it.
The first producer to identify for this HRESULT is the TPM resource, context or delegation manager, sometimes mediated by TBS virtualization. TBS can virtualize finite TPM resources, but a saved TPM context and a TBS virtual handle are not durable application IDs. Their validity depends on resource type, owning client context, TPM lifecycle and the exact save/load history.
Evidence that changes the diagnosis
| Question | Evidence for this HRESULT |
|---|---|
| What exact state was rejected? | an exclusive TPM 1.2 transport session lost exclusivity because another command executed outside it |
| Which layer owns the result? | The TPM resource, context or delegation manager, sometimes mediated by TBS virtualization. |
| What must be correlated? | transport handle and attributes, complete command timeline across processes, TBS context and priority, nested commands, and session termination state |
| What is the controlled comparison? | run the transport sequence on an otherwise idle test system and trace every TPM command from start to finish |
Record the original command or API call before this result retry logic mutates its nonces, handles, buffers or state. Also retain the full HRESULT as 0x8028004E; signed decimal logging can hide the result TPM/TBS facility and make searches less precise.
A controlled verification
- Establish the result baseline with the same device, Windows build, account and TPM generation.
- Perform one narrow experiment: run the transport sequence on an otherwise idle test system and trace every TPM command from start to finish.
- Compare raw this result inputs and the first response, not only the final application dialog.
- Stop after the first changed the checkpoint; a later error means this boundary was passed even if the whole workflow still fails.
Related TPM and TBS results
| Result | Different diagnostic question |
|---|---|
TPM_E_OWNER_CONTROL | Attempt to context save a owner evict controlled key — a separate checkpoint when compared with this result. |
TPM_E_DELEGATE_ADMIN | Delegation table management not enabled — a separate checkpoint when compared with it. |
TPM_E_BAD_HANDLE | The handle is incorrect — a separate checkpoint when compared with it. |
The decisive distinction for this HRESULT is that TPM_E_NO_WRAP_TRANSPORT rejects wrapped transport capability before an exclusive session is established. The short platform wording — “There was a command executed outside of an exclusive transport session.” — does not supply that differential diagnosis by itself.
Correction and proof
The corrective direction is to serialize TPM access around the exclusive transport or replace the legacy transport design with a supported higher-level API. Do not persist volatile TPM or TBS handles as durable identifiers. A numeric handle can be valid only inside the creating context and lifecycle, even when its value looks unchanged after restart.
A verified it repair reproduces the original request with the same intended security policy and passes this checkpoint. Replacing it with a broader wrapper status, silently falling back to software keys, or suppressing verification is not proof of success.
Technical references
- Microsoft: Resource Virtualization in TBS — source for the checkpoint.
- Microsoft: Command Scheduling in TBS — source for the checkpoint.
- Microsoft: Using TPM Base Services — source for the checkpoint.
- TCG: TPM 1.2 Part 3 — Context commands — source for the checkpoint.
Looking for a different code? Search another status or error code.