HRESULT 0x80670001: meaning and diagnosis

Status / error code:

Category:

Constant name:

Source:

Facility:

Operating System:

Description:

Optimistic locking failure. Data cannot be updated if it has changed since it was read.

Previous	Next
E_HDAUDIO_NULL_LINKED_LIST_ENTRY	STATEREPOSITORY_E_STATEMENT_INPROGRESS

STATEREPOSITORY_E_CONCURRENCY_LOCKING_FAILURE

STATEREPOSITORY_E_CONCURRENCY_LOCKING_FAILURE belongs to Windows StateRepository. It marks an optimistic update lost because the stored row changed after it was read. The useful starting point is the exact API, object and state transition that returned 0x80670001, because a shell or application message can hide that boundary.

First rejecting layer

For STATEREPOSITORY_E_CONCURRENCY_LOCKING_FAILURE, StateRepository is infrastructure for the Windows application model. When STATEREPOSITORY_E_CONCURRENCY_LOCKING_FAILURE is returned, 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. During a STATEREPOSITORY_E_CONCURRENCY_LOCKING_FAILURE investigation, these are not interchangeable reasons to delete the repository.

When STATEREPOSITORY_E_CONCURRENCY_LOCKING_FAILURE is returned, optimistic concurrency compares the caller’s read version with current repository state. During a STATEREPOSITORY_E_CONCURRENCY_LOCKING_FAILURE investigation, the failure protects a newer write from being overwritten and should lead to reread-and-reconcile logic, not a database lock reset.

For STATEREPOSITORY_E_CONCURRENCY_LOCKING_FAILURE, the first owner to inspect is the StateRepository request, database connection, prepared statement, transaction, schema generation, or service lifecycle that rejected the operation.

Smallest faithful test

During a STATEREPOSITORY_E_CONCURRENCY_LOCKING_FAILURE investigation, reduce the case while preserving the condition described by the HRESULT.

First: Reread the entity in a new transaction.
Next: Reapply only changes that remain valid.
Then: Detect and surface true field conflicts.
Finally: Retry with a bounded conflict policy.

Diagnostic matrix

Entity key and original version token. For STATEREPOSITORY_E_CONCURRENCY_LOCKING_FAILURE, this places the event on the lifecycle or transaction timeline within the Windows StateRepository boundary.
Current stored version. For STATEREPOSITORY_E_CONCURRENCY_LOCKING_FAILURE, this separates caller input from environment and service state within the Windows StateRepository boundary.
Competing writer and transaction. For STATEREPOSITORY_E_CONCURRENCY_LOCKING_FAILURE, this creates a stable comparison across retries or another machine within the Windows StateRepository boundary.
Fields changed by each writer. For STATEREPOSITORY_E_CONCURRENCY_LOCKING_FAILURE, this pins the event to an object or resource generation within the Windows StateRepository boundary.

What each result would imply

Isolated connection against a repository copy: For STATEREPOSITORY_E_CONCURRENCY_LOCKING_FAILURE, a changed result separates retained object, connection, path, host, or device state from the original input. Hold constant: For STATEREPOSITORY_E_CONCURRENCY_LOCKING_FAILURE, preserve schema, data generation, and transaction sequence.
Reduced failing operation: If STATEREPOSITORY_E_CONCURRENCY_LOCKING_FAILURE follows the reduced step, the rejecting transition is localized. Hold constant: For STATEREPOSITORY_E_CONCURRENCY_LOCKING_FAILURE, retain entity key and original version token and remove only unrelated work.
Targeted corrective control: Use this as a diagnostic branch rather than a blanket workaround: reread the entity in a new transaction. Hold constant: For STATEREPOSITORY_E_CONCURRENCY_LOCKING_FAILURE, keep the original STATEREPOSITORY_E_CONCURRENCY_LOCKING_FAILURE sample available for the final regression test.

Limits of the HRESULT

For STATEREPOSITORY_E_CONCURRENCY_LOCKING_FAILURE, BUSY and LOCKED codes concern inability to acquire database resources; optimistic failure occurs after a logical version comparison.

For STATEREPOSITORY_E_CONCURRENCY_LOCKING_FAILURE, do not overwrite the newer row or delete repository files to make the retry succeed.

Prove the repair

Treat STATEREPOSITORY_E_CONCURRENCY_LOCKING_FAILURE as corrected only when concurrent writers preserve both intended changes or report a deterministic conflict without lost updates; retain the original negative case so fallback cannot be mistaken for repair.

Technical references

The references below define the API family or storage/protocol behavior used to interpret STATEREPOSITORY_E_CONCURRENCY_LOCKING_FAILURE.

For STATEREPOSITORY_E_CONCURRENCY_LOCKING_FAILURE: Microsoft Win32 metadata: winerror.h
SQLite: File locking and concurrency
SQLite: Result and extended result codes
SQLite: Transaction control

Looking for a different code? Search another status or error code.