| Previous | Next |
| TBS_E_TOO_MANY_TBS_CONTEXTS | TBS_E_SERVICE_START_PENDING |
TBS_E_TOO_MANY_RESOURCES
Interpret the boundary first
TBS_E_TOO_MANY_RESOURCES (0x8028400A) belongs to TBS resource virtualization. The base What Is page already shows the short Windows message; the additional diagnostic value is that this result marks the TBS virtualization layer cannot create another virtual TPM resource for the client workload.
The first producer to identify for it is the TBS context and virtual-resource manager that maps finite TPM slots for multiple clients. TBS resource virtualization maps client-visible virtual handles to finite physical TPM key, authorization and transport slots. Cleanup, eviction and context ownership determine whether a mapping can be restored.
Build the command transcript
| Question | Evidence for it |
|---|---|
| What exact state was rejected? | the TBS virtualization layer cannot create another virtual TPM resource for the client workload |
| Which layer owns the result? | The TBS context and virtual-resource manager that maps finite TPM slots for multiple clients. |
| What must be correlated? | resource type, open virtual handles, context ownership, load/create command history, flush behavior, and current concurrency |
| What is the controlled comparison? | flush one disposable virtual object and repeat the creation in the same context |
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.
Test one hypothesis
Use the following verification sequence:
- Capture the unmodified failing input and
0x8028400A. - Flush one disposable virtual object and repeat the creation in the same context.
- 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.
Do not merge these conditions
| Other code | Why a different remedy follows |
|---|---|
TBSIMP_E_INVALID_CONTEXT_HANDLE | The specified context handle is invalid — a separate checkpoint when compared with this result. |
TBS_E_TOO_MANY_TBS_CONTEXTS | A new context could not be created because there are too many open contexts — a separate checkpoint when compared with it. |
TBSIMP_E_INVALID_CONTEXT_PARAM | An invalid context parameter was specified — a separate checkpoint when compared with it. |
TBS_E_TOO_MANY_TBS_CONTEXTS concerns client contexts rather than keys or sessions inside them. The result difference determines whether to change serialization, authorization, resource lifetime, firmware/PPI state, command policy or only retry timing.
A safe recovery path
Correct the original boundary by choosing this direction: release unneeded TPM objects and sessions and avoid retaining virtual handles beyond the operation. Do not confuse a TBS virtual handle with a physical TPM handle or copy it to another process. Resource virtualization intentionally scopes mappings to a client context.
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
- Microsoft: Resource Virtualization in TBS — source for the checkpoint.
- Microsoft: Command Scheduling in TBS — source for the checkpoint.
- Microsoft: About TPM Base Services — source for the checkpoint.
- Microsoft: Power Management in TBS — source for the checkpoint.
Looking for a different code? Search another status or error code.