| Previous | Next |
| TAPI_E_INVALCARD | TAPI_E_INVALCOMPLETIONID |
OLE_E_NOSTORAGE
OLE object has not been given storage
OLE_E_NOSTORAGE is HRESULT 2147745810 (0x80040012) from winerror.h. The documented description is “Not able to perform the operation because object is not given storage yet” The result belongs to persistence or operation of an embedded object requiring IStorage. This HRESULT is most useful when tied to the method and lifecycle phase where the object has no assigned storage in which to load, save, or maintain its persistent state.
This result means that the object has no assigned storage in which to load, save, or maintain its persistent state. 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 compound-document containers, embedded or linked objects, OLE activation, advising, caching, conversion, and persistence.
- Map the failure to one concrete operation among IOleObject, IOleLink, IOleCache, IAdviseSink, IPersistStorage, IOleInPlaceObject, monikers, verbs, and client-site callbacks.
- Preserve CLSID, object and client-site identity, storage or moniker, advise cookie, verb, activation state, window generation, and presentation format 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 object has no assigned storage in which to load, save, or maintain its persistent state.
Typical causes and interpretation
The immediate contract boundary is specific: the object has no assigned storage in which to load, save, or maintain its persistent state. Common cause branches include the following:
- The container skipped IPersistStorage initialization.
- Storage creation failed and the object was retained.
- A handoff lost the storage association.
Confirm the cause branch that explains why the object has no assigned storage in which to load, save, or maintain its persistent state by using call arguments, object state, metadata, device information, or provider traces.
Correct handling and recovery
The primary recovery is to create or reopen the correct storage, initialize persistence in documented order, and abandon the object if storage cannot be established. The failure report should capture the relevant state during persistence or operation of an embedded object requiring IStorage so it is clear why the object has no assigned storage in which to load, save, or maintain its persistent state.
The owner of it must define idempotency, cancellation, attempt limits, and reconciliation for the failed persistence or operation of an embedded object requiring IStorage.
Practical scenario
A container calls Save on a newly created embedded object before InitNew provides a substorage; correcting the initialization order resolves the failure.
Difference from related HRESULTs
OLE_E_BLANK is general uninitialized state; it specifically identifies absence of the persistence storage.
Developer and administrator guidance
Broad permission or compatibility changes are inappropriate unless evidence for the object has no assigned storage in which to load, save, or maintain its persistent state points to that layer.
References
Looking for a different code? Search another status or error code.