What does HRESULT 0x80280800 (TPM_E_RETRY) mean?

 
Previous Next
TPM_E_EMBEDDED_COMMAND_UNSUPPORTED TPM_E_NEEDS_SELFTEST

TPM_E_RETRY

Where the failure is raised

TPM_E_RETRY (0x80280800) 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 the TPM is temporarily busy and explicitly permits the same command to be resubmitted later.

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.

The result value 0x80280800 should remain attached to the symbolic name. Some this result logs store the value as a negative signed integer; others expose only a generic CNG, WMI, BitLocker or enrollment message. Neither substitution identifies the TPM is temporarily busy and explicitly permits the same command to be resubmitted later as precisely as it.

Evidence that changes the diagnosis

  • Producer for it: TBS command blocking, virtual-handle translation, retry or anti-hammering logic.
  • Rejected invariant: the TPM is temporarily busy and explicitly permits the same command to be resubmitted later.
  • Decisive capture: complete command bytes, retry count and delay, device load, preceding long command, TBS priority, and whether input state changes between attempts.
  • Safe comparison: resubmit the identical idempotent command with bounded backoff and confirm that no object or nonce input is regenerated between retries.

A controlled verification

Build the result minimal case around the original command contract. Use a disposable object when the request can write NV data, advance a counter, change authorization state or consume a lock transition. The comparison is valid only when the caller, TPM generation and security policy remain the same.

QuestionEvidence for it
What exact state was rejected?the TPM is temporarily busy and explicitly permits the same command to be resubmitted later
Which layer owns the result?TBS command blocking, virtual-handle translation, retry or anti-hammering logic.
What must be correlated?complete command bytes, retry count and delay, device load, preceding long command, TBS priority, and whether input state changes between attempts
What is the controlled comparison?resubmit the identical idempotent command with bounded backoff and confirm that no object or nonce input is regenerated between retries

Related TPM and TBS results

ConstantCheckpoint represented by its standard message
TPM_E_DEFEND_LOCK_RUNNINGThe TPM is defending against dictionary attacks and is in a time-out period — a separate checkpoint when compared with this result.
TPM_E_EMBEDDED_COMMAND_UNSUPPORTEDThe command within the transport is not supported — a separate checkpoint when compared with this result.
TPM_E_EMBEDDED_COMMAND_BLOCKEDThe command within the transport was blocked — a separate checkpoint when compared with it.

The codes above may appear in the same workflow, but they are not aliases. TPM_E_DEFEND_LOCK_RUNNING is a timed dictionary-attack defense state, not general command busy.

Correction and proof

Implement bounded retry according to the command’s side-effect rules and surface persistent busy behavior with firmware and timing evidence. 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.

Proof for it consists of a successful replay plus validation of the intended key, PCR, NV, context, event-log, provider or service result. A software fallback or a newly provisioned blank TPM answers a different question than it.

Source material


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