| Previous | Next |
| STG_E_SHAREVIOLATION | STG_E_FILEALREADYEXISTS |
STG_E_LOCKVIOLATION
How it differs from a sharing violation
STG_E_LOCKVIOLATION indicates a locking conflict during an operation that needs a region, stream, or storage state protected from concurrent changes. A sharing violation usually prevents an incompatible open; a lock violation can occur after objects are already open when another participant owns the needed lock. In document workflows this can involve a second writer, a preview/conversion service, or a stale process that did not release its storage object cleanly.
Compound files contain several internal structures that must remain consistent while data and allocation tables change. Applications should therefore treat concurrent writers as a deliberate coordination problem, not as two independent file updates that happen to use the same extension.
What to check
- Find the lock owner and whether it is a real active operation, a hung worker, or an unexpected component such as a synchronization client.
- Review lifetime rules for
IStreamandIStorage; abandoned references can keep locks alive. - Use a single-writer queue or an application-level lease when a document can be edited by multiple workers.
- Do not confuse a lock retry with conflict resolution: after a retry succeeds, validate that the document version is still the one intended for update.
References
- Microsoft: IStream::LockRegion
- Microsoft: HRESULT storage error values
- libolecf format documentation
Looking for a different code? Search another status or error code.