| Previous | Next |
| DISP_E_BADCALLEE | DISP_E_DIVBYZERO |
DISP_E_NOTACOLLECTION
Automation object does not support collection semantics
DISP_E_NOTACOLLECTION is HRESULT 2147614737 (0x80020011) from winerror.h. AllStat describes it as “Does not support a collection.” The value must be interpreted at generic Automation code attempting enumeration or indexed default-property access, because the same high-level symptom can come from a different contract boundary and require different cleanup.
The decisive Interpretation is that the selected dispatch object has no collection contract for the requested operation. Keep the symbolic name beside the raw hexadecimal value so later analysis does not collapse the result into an unrelated COM family.
Where the result appears
- This result is returned while Automation binds or executes generic Automation code attempting enumeration or indexed default-property access.
- retain the member name and DISPID, invocation flags, LCID, cArgs, cNamedArgs, and the exact VARIANTARG sequence in reverse Automation order.
- The output contract for it includes puArgErr, EXCEPINFO, result VARIANT, by-reference values, and SAFEARRAY lock or ownership state; inspect them before cleanup.
Determine the object and lifecycle phase that owned this result; a UI symptom cannot establish whether the origin was the caller, proxy, runtime, server, or metadata producer.
Typical causes and interpretation boundary
Common cause categories for it are: the caller received a scalar object; the wrong property was selected; a version removed collection behavior; default-member assumptions are invalid. Evaluate these branches independently and require evidence from the owning API before promoting one branch to the root cause.
The check that separates this result from nearby HRESULTs is: the selected dispatch object has no collection contract for the requested operation. If the decisive fact for it is unknown, keep the result unresolved and collect the missing state instead of inferring it from wording.
Evidence and telemetry
- Record this result with the object CLSID or ProgID, interface identity, member DISPID, dispatch flags, and type-library version.
- capture object type and IID; requested _NewEnum or Item member; invocation flags; type-info attributes; caller assumption.
- Log VARIANT type tags, dimensions, bounds, lengths, and null/empty distinctions for it, but redact actual confidential argument values.
- Preserve the caller language/runtime, generated interop version, LCID, and whether the call crossed a process boundary when it occurs.
- After it, call VariantClear, SysFreeString, SafeArrayDestroy, or release interfaces only for values whose ownership was transferred by the documented contract.
Log identifiers, sizes, type tags, states, and hashes while excluding credentials, tokens, document payloads, and complete user arguments.
Correct handling and recovery
The appropriate recovery is to query documented collection interfaces or members, branch on capability, and avoid treating every IDispatch object as enumerable. The owner of retry for it must define idempotency, refreshed state, maximum attempts, backoff, and cancellation responsibility.
After it, apply the API-specific validity rules to outputs and release only resources whose ownership transferred during this attempt.
Practical scenario
A scripting adapter receives a single worksheet rather than a worksheets collection and stops requesting _NewEnum.
A regression test for it should force the decisive precondition, assert native outputs, fix only that condition, and confirm the expected neighboring result.
Difference from related HRESULTs
DISP_E_BADINDEX means a collection exists but the index is invalid; it means collection behavior is absent.
Represent this distinction for it directly in control flow and dashboards instead of grouping it under a single COM-failure label.
Developer and administrator guidance
Automation adapters should handle it at the dispatch boundary and expose the member, parameter, and type information needed to repair the call. A generic retry after <code>it</code> with unchanged DISPPARAMS usually repeats the same deterministic binding error.
Deployment owners should compare the registered type library and server binary as one versioned unit. After <code>it</code>, re-registering arbitrary DLLs or changing locale system-wide is inappropriate unless the captured metadata proves registration or LCID drift.
References
- Microsoft: IDispatch::Invoke
- Microsoft: IDispatch::GetIDsOfNames
- Microsoft: EXCEPINFO
- Microsoft: HRESULT values
Looking for a different code? Search another status or error code.