| Previous | Next |
| TBS_E_TOO_MANY_RESOURCES | TBS_E_PPI_NOT_SUPPORTED |
TBS_E_SERVICE_START_PENDING
Classify the layer correctly
TBS_E_SERVICE_START_PENDING (0x8028400B) belongs to the public and internal TPM Base Services path. The base What Is page already shows the short Windows message; the additional diagnostic value is that this result marks the TBS service startup has begun but is not yet ready to accept the requested operation.
The first producer to identify for it is the TBS client library, local RPC service and command scheduler before or around device execution. TBS centralizes TPM access through a local RPC service. A failure can therefore occur in the caller contract, RPC/service startup, scheduling, buffer handling or TPM submission, and each layer requires different evidence.
Read this result as its own boundary in a sequence, not as a verdict that every TPM feature is broken. The sequence reaches the TBS service startup has begun but is not yet ready to accept the requested operation, and the component returns 0x8028400B before the application can safely assume that later key, attestation, boot or licensing work occurred.
Incident worksheet
- Request identity: exact function or command, input lengths, flags, caller context and this result.
- State identity: service state and checkpoint, startup trigger, boot timing, caller retry policy, dependent driver state, and relevant service-control events.
- Platform identity for it: TPM generation, manufacturer/firmware revision, Windows build and relevant service events.
- Binary identity: preserve opaque structures byte-for-byte and log
0x8028400Bin hexadecimal.
A reproducible comparison
Wait for the service to reach running and retry the same non-destructive context creation once. Keep every other this result test condition unchanged. If the comparison reaches a later checkpoint, then the original the condition has been isolated even when a second defect remains.
| Observed outcome | Interpretation |
|---|---|
| The exact request succeeds | The changed condition belongs to the rejected the TBS service startup has begun but is not yet ready to accept the requested operation. |
| A more specific earlier code appears | Preserve the earlier result in the result trace; the previous trace probably lost the first producer. |
| The same code returns with identical bytes | Escalate the persistent it with firmware, service and command evidence rather than broad configuration changes. |
| The code disappears only after destructive reset | The result experiment is not diagnostic because original protected state and evidence were removed. |
Boundaries often confused with this one
| Nearby constant | Why it is different |
|---|---|
TBS_E_COMMAND_CANCELED | The command was canceled — a separate checkpoint when compared with it. |
TBS_E_INVALID_CONTEXT_PARAM | One or more context parameters is invalid — a separate checkpoint when compared with it. |
TBS_E_BUFFER_TOO_LARGE | The input or output buffer is too large — a separate checkpoint when compared with it. |
For this page, the useful contrast is: TBS_E_SERVICE_NOT_RUNNING means the service is unavailable rather than merely progressing through startup.
Restore service safely
Apply the narrow remedy: use bounded startup-aware retry rather than restarting the TPM service repeatedly during boot. Do not restart or disable TBS before capturing its service and event data. Most caller-contract errors are reproducible without touching TPM ownership, firmware state or stored keys.
Close the incident only when the same API or TPM command passes with the intended hardware-backed behavior and the expected output can be independently validated.
References
- Microsoft: About TPM Base Services — source for the checkpoint.
- Microsoft: TBS return codes — source for the checkpoint.
- Microsoft: Tbsi_Context_Create — source for the checkpoint.
- Microsoft: Tbsip_Submit_Command — source for the checkpoint.
Looking for a different code? Search another status or error code.