| Previous | Next |
| STATEREPOSITORY_E_BLOCKED | STATEREPOSITORY_E_BUSY_RECOVERY_RETRY |
STATEREPOSITORY_E_BUSY_RETRY
The scope of STATEREPOSITORY_E_BUSY_RETRY is Windows StateRepository: the database file is busy and the request is expected to be retried. Preserve 0x80670007 beside the returning call before cleanup or retry creates a more generic secondary failure.
Wrong turns
When it is returned, LOCKED_RETRY is generally table or shared-cache contention; BUSY_RETRY is database-file contention.
Do not retry indefinitely or delete journal files while connections are active.
Object and state boundary
When it is returned, StateRepository is infrastructure for the Windows application model. During a this result investigation, 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.
During a this result investigation, database-wide contention can arise when another connection holds a lock needed for the next step. This retry-class HRESULT indicates a transient policy path, distinct from the corresponding timeout-exceeded result.
The first owner to inspect is the StateRepository request, database connection, prepared statement, transaction, schema generation, or service lifecycle that rejected the operation.
Capture before retry
| Capture | Diagnostic value |
|---|---|
| Database path and connection for this HRESULT. | This separates caller input from environment and service state and helps test the Windows StateRepository boundary. |
| Current transaction and lock holder for this HRESULT. | This provides a stable comparison across retries or another machine and helps test the Windows StateRepository boundary. |
| Retry count and delay for this HRESULT. | This identifies the exact object or resource generation involved and helps test the Windows StateRepository boundary. |
| Statement that requested the lock for this HRESULT. | This places the failure on the lifecycle or transaction timeline and helps test the Windows StateRepository boundary. |
Controlled comparisons
| 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 this result, 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. |
Step-by-step investigation
The investigation should change one variable at a time and keep the original failing sample.
- First: Keep transactions short.
- Next: Finalize or reset statements promptly.
- Then: Use bounded backoff supplied by the caller contract.
- Finally: Correlate lock ownership before changing service state.
Closure criteria
Closure for this HRESULT requires contention clears within the bounded policy and the operation commits exactly once; then repeat the next lifecycle operation to detect stale state.
Technical references
The references below define the API family or storage/protocol behavior used to interpret it.
- Microsoft Win32 metadata: winerror.h
- Microsoft: Windows service guidance for StateRepository
- SQLite: File locking and concurrency
- SQLite: Result and extended result codes
Looking for a different code? Search another status or error code.