| Previous | Next |
| STG_E_INVALIDHANDLE | STG_E_INVALIDPOINTER |
STG_E_INSUFFICIENTMEMORY
Structured-storage operation lacks required memory
STG_E_INSUFFICIENTMEMORY is HRESULT 2147680264 (0x80030008) from winerror.h. The documented description is “There is insufficient memory available to complete operation.” The result belongs to allocation of storage objects, enumerators, buffers, or transaction state. This HRESULT is most useful when tied to the method and lifecycle phase where the storage implementation cannot allocate the memory needed to complete the requested operation.
This result means that the storage implementation cannot allocate the memory needed to complete the requested operation. Preserve the original HRESULT and the state that made this condition true; the severity bit alone does not determine how the caller should handle it.
Where the result appears
- This result can surface in a IStorage, IStream, ILockBytes, property storage, compound-file parsing, or persistence code.
- Map the failure to one concrete operation among StgOpenStorage, StgCreateStorageEx, IStorage, IStream, IPropertyStorage, STATSTG, and the selected STGM mode.
- Preserve storage path or identity, STGM mode, stream or storage name, transaction generation, file hash, and backing provider before releasing or replacing the object that returned this result.
An incident record must distinguish caller, runtime, provider, and backing resource while testing whether the storage implementation cannot allocate the memory needed to complete the requested operation.
Typical causes and interpretation
The immediate contract boundary is specific: the storage implementation cannot allocate the memory needed to complete the requested operation. Common cause branches include the following:
- Process address space or commit is exhausted.
- A malformed file requests an unreasonable allocation.
- Many unreleased storage or enumerator objects accumulate.
Confirm the cause branch that explains why the storage implementation cannot allocate the memory needed to complete the requested operation by using call arguments, object state, metadata, device information, or provider traces.
Correct handling and recovery
The primary recovery is to release leaked objects, bound allocation sizes, and retry only after memory pressure has measurably changed. The failure report should capture the relevant state during allocation of storage objects, enumerators, buffers, or transaction state so it is clear why the storage implementation cannot allocate the memory needed to complete the requested operation.
The owner of it must define idempotency, cancellation, attempt limits, and reconciliation for the failed allocation of storage objects, enumerators, buffers, or transaction state.
Practical scenario
Opening a damaged compound file yields a directory count large enough to exhaust the parser allocation; validation rejects the count before another attempt.
Difference from related HRESULTs
E_OUTOFMEMORY is the generic allocation result; it identifies the failure at a storage API boundary.
Developer and administrator guidance
Broad permission or compatibility changes are inappropriate unless evidence for the storage implementation cannot allocate the memory needed to complete the requested operation points to that layer.
References
Looking for a different code? Search another status or error code.