| Previous | Next |
| STATEREPOSITORY_E_BUSY_RETRY | STATEREPOSITORY_E_LOCKED_RETRY |
STATEREPOSITORY_E_BUSY_RECOVERY_RETRY
The scope of STATEREPOSITORY_E_BUSY_RECOVERY_RETRY is Windows StateRepository: the database is busy because another connection is performing recovery. Preserve 0x80670008 beside the returning call before cleanup or retry creates a more generic secondary failure.
Wrong turns
When it is returned, BUSY_RETRY is generic file contention; BUSY_RECOVERY_RETRY identifies recovery as the blocking phase.
Do not remove journal or WAL files from a live repository.
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, recovery requires stronger coordination than an ordinary writer. A retry during recovery should wait for the recovery owner to finish and should not launch competing repair attempts.
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 |
|---|---|
| Recovery owner and start time for this HRESULT. | This identifies the exact object or resource generation involved and helps test the Windows StateRepository boundary. |
| Journal or WAL state on a copy for this HRESULT. | This places the failure on the lifecycle or transaction timeline and helps test the Windows StateRepository boundary. |
| Request retry sequence for this HRESULT. | This separates caller input from environment and service state and helps test the Windows StateRepository boundary. |
| Previous unclean shutdown evidence for this HRESULT. | This provides a stable comparison across retries or another machine 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: Allow the single recovery process to complete.
- Next: Prevent service restarts from multiplying recovery attempts.
- Then: Check storage health if recovery repeats.
- Finally: Bound retries and preserve event-log correlation.
Closure criteria
Closure for this HRESULT requires one recovery completes, subsequent opens are clean, and the original request succeeds without another recovery loop; 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.