| Previous | Next |
| CS_E_INTERNAL_ERROR | OLEOBJ_E_NOVERBS |
CACHE_E_NOCACHE_UPDATED
Cache not updated
The native value 0x80040170 is CACHE_E_NOCACHE_UPDATED, unsigned 2147746160 and signed -2147221136. According to AllStat, it means “Cache not updated”. Treat it as evidence that none of the requested OLE cache entries was successfully updated; the operation in progress is refreshing cached presentations from an IDataObject.
The high bit in 0x80040170 is set, so this is a failure rather than a success or informational result. Its facility field is 4 (FACILITY_ITF) and its low 16-bit code is 368 (0x0170). Those bit fields classify the value, but they do not identify the failing object by themselves; the native method, object identity, and first producer of this result remain essential.
Operational meaning
Understanding this result requires this subsystem context: An OLE cache can contain multiple independent presentation entries. The aggregate HRESULT is meaningful only together with per-entry outcomes and the status of the previously committed cache.
- Associate this result with one exact operation in IOleCache or IOleCache2 entries, FORMATETC matching, data-object availability, and update policy.
- Confirm that this result came from refreshing cached presentations from an IDataObject, rather than from cleanup or a wrapper that ran afterward.
- Preserve any IErrorInfo, underlying Win32 result, provider message, or callback failure that preceded it; the HRESULT alone should not erase a more specific cause.
Cause model
- It can result when the source cannot provide any cached FORMATETC requested by the container.
- It can result when every cache entry fails because the source object is disconnected or unavailable.
- It can result when update flags, aspects, or advisory modes select entries that cannot be refreshed in the current state.
Troubleshooting workflow
- Capture it at the first native return before a wrapper maps it to a generic exception.
- Identify the exact object, method, and lifecycle phase involved in refreshing cached presentations from an IDataObject.
- Capture per-entry HRESULTs rather than retaining only the aggregate result.
- Enumerate cache connection IDs and their FORMATETC values.
- Verify whether old cached presentations remain valid and whether the source can render live data.
- Reproduce it with one controlled input or state change, and verify that the correction changes the decisive evidence rather than merely hiding the result.
What to log
A useful incident records the cache connection ID, FORMATETC, advisory flags, source IDataObject, update flags, per-entry HRESULTs, presentation aspect, and whether stale data remains usable. Also retain the application and component build, architecture, process and thread IDs, COM apartment, operation correlation ID, elapsed time, and the first state-changing event before the failure. When logging it, redact content and credentials while preserving types, lengths, hashes, opaque identities, and lifecycle generations needed to reproduce its contract.
Correction strategy
Correction. for it, correct or remove unsupported entries, reconnect the source, or update the cache from explicitly supplied data. Retry boundary. Retry after source or format availability changes; preserve a known-good old cache until replacement data is committed. Before repeating the operation, retain the last committed presentation, release failed cache or advisory entries, and inspect per-entry results before deciding that the whole cache is unusable.
Practical scenario
An embedded object loses its link source, so all live cache updates fail; the container keeps the last committed presentation and marks it stale instead of deleting it. This isolates it within OLE presentation cache updates and provides a regression test for the stated correction.
Difference from related HRESULTs
CACHE_S_SOMECACHES_NOTUPDATED indicates partial success; it means the update produced no refreshed cache entry. Keep those outcomes separate in exception mappings, telemetry dimensions, user messages, and automated retry policy.
Developer and administrator guidance
Track each cache connection ID with its FORMATETC and update policy, distinguish stale from absent data, and surface partial update results. Regression coverage for it should include mixed-success cache entries, unavailable source data, changed FORMATETC support, stale presentations, advisory disconnects, and update after object replacement.
Operational repair for it must target the evidence-backed owner: verify the object server and source data first; deleting user caches or reinstalling handlers is appropriate only when the failing cache owner and corruption evidence are known. Retain before-and-after traces for it so the change can be attributed and reversed.
References
- Microsoft: generic COM error codes
- Microsoft: HRESULT values
- Microsoft: IOleCache
- Microsoft: IOleCache::Cache
Looking for a different code? Search another status or error code.
