| Previous | Next |
| STATEREPOSITORY_E_LOCKED_RETRY | STATEREPOSITORY_E_TRANSACTION_REQUIRED |
STATEREPOSITORY_E_LOCKED_SHAREDCACHE_RETRY
Within Windows StateRepository, STATEREPOSITORY_E_LOCKED_SHAREDCACHE_RETRY reports that a shared-cache lock held by another connection blocked this request. 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 |
|---|---|
| Shared-cache group and connections for this HRESULT. | This separates caller input from environment and service state and helps test the Windows StateRepository boundary. |
| Table and schema locks for this HRESULT. | This provides a stable comparison across retries or another machine and helps test the Windows StateRepository boundary. |
| Active prepared statements for this HRESULT. | This identifies the exact object or resource generation involved and helps test the Windows StateRepository boundary. |
| Thread and transaction ownership for this HRESULT. | This places the failure on the lifecycle or transaction timeline 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.
Connections participating in a shared cache coordinate schema and table locks inside one process or cache group., the decisive evidence is cache-group membership and connection state, not only the database filename.
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: Avoid sharing one cache group without a clear concurrency design.
- Next: Finish statements before cross-connection writes.
- Then: Test with private caches as a control.
- Finally: Keep retries outside the lock-owning callback.
Avoid the tempting broad fix
During a this result investigation, LOCKED_RETRY may be table locking generally; LOCKED_SHAREDCACHE_RETRY identifies shared-cache coordination.
Do not assume process-local locks will appear as external file handles.
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 cache configuration supports the tested concurrency or is replaced with isolated connections that pass the same workload.
Technical references
The references below define the API family or storage/protocol behavior used to interpret it.
- Microsoft Win32 metadata: winerror.h
- SQLite: Result and extended result codes
- SQLite: Shared-cache locking model
- Microsoft: Windows service guidance for StateRepository
Looking for a different code? Search another status or error code.