| 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
COM activation is a sequence rather than a single operation: registration lookup, SCM or surrogate selection, process startup, class-factory publication, marshaling, and finally the requested interface call. The useful evidence is the evidence from the first stage that fails; a later RPC or cleanup message can otherwise hide the original activation problem.
Do not collapse this result into a nearby status. Low free RAM alone does not prove E_OUTOFMEMORY; commit limits, fragmentation, quotas, or a non-memory resource may be the actual boundary. Compare lifecycle, identity, caller, and first API.
Facts to collect first
| Incident evidence | Question it answers |
|---|---|
| Process commit, private bytes, job limits, address-space layout, and system commit at first failure | Tests whether the first boundary moves. |
| Allocation size and whether the request is one large block or many retained objects | Pins evidence to one attempt. |
| Heap diagnostics, allocation stacks, and the owner of the largest retained regions | Separates contract failure from environment. |
| Adjacent resource counters such as GDI, USER, section handles, or GPU allocations when the API abstracts them as memory | Creates a stable before/after control. |
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; use a disposable or backed-up environment when the comparison changes boot, security, device, queue, or encryption state.
- Run a 64-bit build or reduce one large allocation without changing input semantics; retain one negative control so that a broad workaround is not mistaken for a root-cause correction.
- Capture a heap snapshot before growth and at the first failed allocation; keep every other input fixed and record the first event that differs from the failing run.
A retry becomes evidence only when one controlled variable changes. In this case, if the same operation later succeeds unchanged, preserve that fact but continue checking timing, object generation, service restart, cache replacement, or policy refresh; transient success does not explain the earlier boundary.
What the result does not prove
Use the outcomes to narrow the failing layer rather than to accumulate unrelated fixes:
| Observed result | Interpretation |
|---|---|
| The minimal or known-good comparison succeeds | The control works; inspect production-specific state. |
| The control fails at the same first operation | The control also fails; inspect host/provider evidence. |
| A new HRESULT marks another boundary | this boundary moved; diagnose the new status separately rather than treating it as confirmation that the entire operation is fixed. |
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. Preserve the pre-change configuration or trace.
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. Repeat under the original identity and state. A different environment is comparison, not proof.
Technical references
These references define the HRESULT family and subsystem contract used above:
- Microsoft Open Specifications: HRESULT values.
- Microsoft: COM clients and servers.
- Microsoft: CoGetClassObject.
- Microsoft: COM elevation moniker.
Looking for a different code? Search another status or error code.