| Previous | Next |
| E_HANDLE | E_INVALIDARG |
E_OUTOFMEMORY
This code places the first failure in allocation failure and resource accounting. Operationally, the component could not obtain memory or a related bounded resource at the point it tried to create or grow an object.
Where the failure sits
Low free RAM alone does not prove E_OUTOFMEMORY; commit limits, fragmentation, quotas, or a non-memory resource may be the actual boundary.
Facts to collect first
- Process commit, private bytes, job limits, address-space layout, and system commit at first failure
- Allocation size and whether the request is one large block or many retained objects
- Heap diagnostics, allocation stacks, and the owner of the largest retained regions
- Adjacent resource counters such as GDI, USER, section handles, or GPU allocations when the API abstracts them as memory
Collect the smallest evidence set that identifies the attempt and object. Redact secrets and message contents; preserve hashes, IDs, policy values, versions, and state transitions instead.
Change one variable at a time
- Reproduce with a bounded workload while graphing commit and object counts.
- Run a 64-bit build or reduce one large allocation without changing input semantics.
- Capture a heap snapshot before growth and at the first failed allocation.
Verification after correction
Apply the smallest change that addresses the first rejected condition: Remove the leak or unbounded retention, validate sizes before multiplication, and make large allocations incremental where the API permits it.
Close the incident only when the same peak workload completes without monotonic resource growth and a deliberately imposed small limit still fails predictably at the documented boundary.
Technical references
These references define the HRESULT family and subsystem contract used above:
Looking for a different code? Search another status or error code.