| Previous | Next |
| SCARD_E_UNKNOWN_CARD | SCARD_E_PROTO_MISMATCH |
SCARD_E_CANT_DISPOSE
SCARD_E_CANT_DISPOSE should be read at the card disposition after disconnect or transaction end boundary. The resource manager could not perform the requested leave, reset, unpower, or eject action when releasing the card connection. Record the requested card disposition and the reader/card state at disconnect or transaction end; reset, unpower, eject, and leave-card transitions have different requirements.
Start with the returning API
The connection is being released with a requested card disposition such as leave, reset, unpower, or eject. The failure concerns that transition, which is separate from whether earlier APDU commands succeeded. Record transaction ownership, sharing, reader capabilities, and the exact disposition in a card disposition after disconnect or transaction end investigation.
Diagnostic evidence matrix
| Record | Why it matters for this code |
|---|---|
| Disconnect or transaction-ending API and requested disposition | Separates resource-manager state from reader, middleware, and card behavior. |
| Outstanding transaction or sharing state and other processes using the card | Preserves the exact SCard call and lower card response where available. |
| Reader eject/reset capability, reader state, and card presence at release time | Changes one hardware or lifecycle variable at a time. |
Code-specific checks:
- Record the disposition value and whether another process still shares the card.
- Check reader capabilities; many readers cannot physically eject a card.
- Retry cleanup with an appropriate disposition only after resolving transactions and shared handles.
Build a timeline before changing state
Smart-card incidents cross host and card boundaries in this condition investigation. Align context creation, reader enumeration, card insertion, connection, protocol negotiation, transaction start, APDU activity, disposition, and disconnect. Include reader and card identities at every stage because a reconnect can select a different physical path while the application reports the same friendly reader name.
- SCard call sequence with share mode, protocol, disposition, reader name, ATR, and handle lifecycle.
- resource-manager and driver events plus vendor APDU/status-word trace when available.
- Results from changing only card, reader, host, or middleware—never several layers in one comparison.
Minimal test sequence
Disconnect first with leave-card disposition, then test reset, unpower, or eject individually on a controlled reader that supports them in this condition investigation. This reveals an unsupported or blocked disposition without changing the preceding card work.
- Use one known-good control that changes only the suspected part of this path.
- Record where behavior first diverges in this path instead of judging only by the final application message.
Scope of this HRESULT
The connection may already be ending even though the requested post-disconnect card action failed. Treating release failure as proof that the card operation failed can cause duplicate writes or repeated transactions. Record operation completion separately from disposal in this condition investigation.
Keep host PC/SC status separate from the card’s own status words because the two layers can report different failures in one operation.
Closure criteria
The application must close transactions and handles in order and request a disposition supported by the reader and current sharing state.
Technical references
These sources define the HRESULT and the relevant interface, protocol, or data format.
Looking for a different code? Search another status or error code.