| Previous | Next |
| STATEREPOSITORY_E_BUSY_RECOVERY_RETRY | STATEREPOSITORY_E_LOCKED_SHAREDCACHE_RETRY |
STATEREPOSITORY_E_LOCKED_RETRY
Within Windows StateRepository, STATEREPOSITORY_E_LOCKED_RETRY reports that a table-level lock prevented the request and the caller may retry. Diagnosis of this result should follow the original owner and generation rather than treating the visible symptom as the cause.
Facts that change the diagnosis
| Capture | Diagnostic value |
|---|---|
| Locked table or operation for this HRESULT. | This identifies the exact object or resource generation involved and helps test the Windows StateRepository boundary. |
| Connection and active statement for this HRESULT. | This places the failure on the lifecycle or transaction timeline and helps test the Windows StateRepository boundary. |
| Transaction mode for this HRESULT. | This separates caller input from environment and service state and helps test the Windows StateRepository boundary. |
| Retry owner and ordering for this HRESULT. | This provides a stable comparison across retries or another machine and helps test the Windows StateRepository boundary. |
Subsystem meaning
During a this result investigation, StateRepository is infrastructure for the Windows application model. The HRESULTs expose distinctions familiar from transactional stores: optimistic concurrency, an unfinished prepared statement, database-versus-table locking, shared-cache contention, recovery, schema compatibility, corruption, and service shutdown., these are not interchangeable reasons to delete the repository.
A connection can reach table contention even when the database file itself is accessible., capture the table and unfinished statement because retrying on another thread may reproduce the same lock ownership.
The first owner to inspect is the StateRepository request, database connection, prepared statement, transaction, schema generation, or service lifecycle that rejected the operation.
Isolation workflow
When it is returned, use a disposable control object, repository copy, file, or device association where the subsystem permits it.
- First: Complete or reset the statement holding the table.
- Next: Serialize writers touching the same table.
- Then: Retry only after the owning transaction advances.
- Finally: Use a controlled two-connection reproduction.
Avoid the tempting broad fix
During a this result investigation, BUSY_RETRY is database-level contention; LOCKED_RETRY is a narrower table or connection-sharing conflict.
Do not open unbounded extra connections to escape the lock.
Expected branches
| Control | Interpretation | Hold constant |
|---|---|---|
| Same database copy, isolated connections | A change points to connection/statement/transaction ownership rather than stored content. | While diagnosing this result, use a copy and preserve schema plus repository generation. |
| Same object, reduced operation | If the result follows one specific transition, statement, file, or ceremony step, the failure is localized. | While diagnosing it, remove only unrelated work and keep the first failing boundary visible. |
| Same operation, controlled environment | If the result follows one machine, account, volume, network, or device, environment matters. | While diagnosing it, keep versions and identity explicit rather than comparing only the final message. |
Regression proof
Verify it with the original scenario, one boundary case, and one deliberate failure; success means the two-connection test follows the intended ordering and no statement remains active across unrelated work.
Technical references
The references below define the API family or storage/protocol behavior used to interpret it.
- Microsoft Win32 metadata: winerror.h
- SQLite: File locking and concurrency
- SQLite: Result and extended result codes
- SQLite: Shared-cache locking model
Looking for a different code? Search another status or error code.