| Previous | Next |
| STG_E_READFAULT | STG_E_LOCKVIOLATION |
STG_E_SHAREVIOLATION
Share conflict, not necessarily corruption
STG_E_SHAREVIOLATION means that the requested access is incompatible with an existing open of the same storage or file. It is often seen when a document is open in another application, a background previewer or indexer holds it, a server process is still processing it, or two components in the same process open it with incompatible sharing modes.
Structured Storage has stricter rules than many callers expect. Microsoft documents that compound-file streams opened through IStorage::OpenStream must use STGM_SHARE_EXCLUSIVE. That means a workaround based on opening multiple independent handles can make the conflict worse rather than better.
How to resolve the actual conflict
- Identify the process and operation that already own the document; distinguish interactive editing from a short-lived scanner or background worker.
- Review the
STGM_*flags used by every component that opens the root storage and child streams. - Serialize writes through one owner; readers should use a documented copy/snapshot workflow where concurrent access is required.
- Retry only after the owner has released the file. A rapid blind retry loop can keep contention high.
References
- Microsoft: IStorage::OpenStream sharing rules
- Microsoft: IStorage::OpenStorage
- Apache POI: OLE 2 compound documents
Looking for a different code? Search another status or error code.