| Previous | Next |
| TPM_20_E_SENSITIVE | TPM_E_INVALID_HANDLE |
TPM_E_COMMAND_BLOCKED
Technical interpretation
TPM_E_COMMAND_BLOCKED (0x80280400) belongs to Windows command mediation around the TPM. The base What Is page already shows the short Windows message; the additional diagnostic value is that this result marks Windows TBS command policy blocked the outer TPM command before normal device execution.
The first producer to identify for it is TBS command blocking, virtual-handle translation, retry or anti-hammering logic. Windows TBS schedules and mediates commands from multiple clients. It can block commands, translate virtual handles, request retry, and preserve anti-hammering policy before or after the raw device command path.
Inputs and state to capture
| Question | Evidence for it |
|---|---|
| What exact state was rejected? | Windows TBS command policy blocked the outer TPM command before normal device execution |
| Which layer owns the result? | TBS command blocking, virtual-handle translation, retry or anti-hammering logic. |
| What must be correlated? | command ordinal or command code, caller token and app-container state, OS version, applicable blocked/allowed policy, and TBS event data |
| What is the controlled comparison? | submit a benign allowed capability command through the same TBS context to prove transport and context creation are working |
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 0x80280400; signed decimal logging can hide the result TPM/TBS facility and make searches less precise.
Validate without broad changes
- Establish the result baseline with the same device, Windows build, account and TPM generation.
- Perform one narrow experiment: submit a benign allowed capability command through the same TBS context to prove transport and context creation are working.
- 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.
Neighboring response codes
| Result | Different diagnostic question |
|---|---|
TPM_E_INVALID_HANDLE | The specified handle was not found — a separate checkpoint when compared with this result. |
TPM_E_DUPLICATE_VHANDLE | The TPM returned a duplicate handle and the command needs to be resubmitted — a separate checkpoint when compared with it. |
TPM_E_EMBEDDED_COMMAND_BLOCKED | The command within the transport was blocked — a separate checkpoint when compared with it. |
The decisive distinction for it is that TPM_E_EMBEDDED_COMMAND_BLOCKED applies to a command carried inside a legacy transport. The short platform wording — “The command was blocked.” — does not supply that differential diagnosis by itself.
Fix and verify
The corrective direction is to use a supported higher-level API or an allowed command; change command policy only through documented administrative controls and with security review. Do not disable command policy globally to make one test pass. First establish the caller, command code and supported higher-level alternative, because command blocking is a security boundary.
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: Command Blocking in TBS — source for the checkpoint.
- Microsoft: Using TPM Base Services — source for the checkpoint.
- Microsoft: Tbsip_Submit_Command — source for the checkpoint.
- TCG: TPM 1.2 Main Specification — source for the checkpoint.
Looking for a different code? Search another status or error code.