| Previous | Next |
| STATEREPOSITORY_ERROR_DICTIONARY_CORRUPTED | STATEREPOSITORY_E_BUSY_RETRY |
STATEREPOSITORY_E_BLOCKED
The scope of STATEREPOSITORY_E_BLOCKED is Windows StateRepository: StateRepository is deliberately blocking requests during an internal state transition. Preserve 0x80670006 beside the returning call before cleanup or retry creates a more generic secondary failure.
Wrong turns
When it is returned, BUSY_RETRY reports database-file contention; BLOCKED is an explicit repository-level gate.
Do not terminate the service solely because requests are temporarily blocked.
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, a blocked repository is not necessarily locked by another process. The service can gate callers during initialization, maintenance, schema work, or coordinated application-model operations.
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 |
|---|---|
| Service state and event log for this HRESULT. | This identifies the exact object or resource generation involved and helps test the Windows StateRepository boundary. |
| Blocking operation or maintenance phase for this HRESULT. | This places the failure on the lifecycle or transaction timeline and helps test the Windows StateRepository boundary. |
| Request type and caller for this HRESULT. | This separates caller input from environment and service state and helps test the Windows StateRepository boundary. |
| Duration and retry policy 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: Observe whether the block is transient and bounded.
- Next: Honor the service’s retry guidance.
- Then: Avoid starting parallel package operations.
- Finally: Capture the operation that entered blocking state.
Closure criteria
Closure for this HRESULT requires the blocking phase exits normally and queued work completes once, without overlapping maintenance operations; 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.