| Previous | Next |
| STATEREPOSITORY_E_TRANSACTION_REQUIRED | STATEREPOSITORY_E_BUSY_RECOVERY_TIMEOUT_EXCEEDED |
STATEREPOSITORY_E_BUSY_TIMEOUT_EXCEEDED
The scope of STATEREPOSITORY_E_BUSY_TIMEOUT_EXCEEDED is Windows StateRepository: database-file contention persisted beyond the repository’s retry threshold. Preserve 0x8067000C beside the returning call before cleanup or retry creates a more generic secondary failure.
Wrong turns
When it is returned, BUSY_RETRY is transient classification; BUSY_TIMEOUT_EXCEEDED means the configured wait policy has already failed.
Do not merely increase the timeout until hangs become less visible.
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, this is the terminal partner of BUSY_RETRY. The elapsed threshold is evidence that a holder, long transaction, stalled statement, or repeated recovery did not clear in time.
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 |
|---|---|
| Timeout duration and retry count for this HRESULT. | This separates caller input from environment and service state and helps test the Windows StateRepository boundary. |
| Lock holder and transaction age for this HRESULT. | This provides a stable comparison across retries or another machine and helps test the Windows StateRepository boundary. |
| Blocked statement for this HRESULT. | This identifies the exact object or resource generation involved and helps test the Windows StateRepository boundary. |
| Service and caller event correlation 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: Identify the oldest lock owner.
- Next: Shorten or fix the holding transaction.
- Then: Verify statements are reset on error paths.
- Finally: Reproduce with timing telemetry before changing timeouts.
Closure criteria
Closure for this HRESULT requires the lock owner completes promptly and the original workload stays below the documented threshold under stress; 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.