| Previous | Next |
| DISP_E_OVERFLOW | DISP_E_UNKNOWNLCID |
DISP_E_BADINDEX
Automation index is outside the valid collection range
DISP_E_BADINDEX is HRESULT 2147614731 (0x8002000B) from winerror.h. AllStat describes it as “Invalid index.” The value must be interpreted at IDispatch collection access, property indexing, or a dispatch helper that validates an index, because the same high-level symptom can come from a different contract boundary and require different cleanup.
The decisive Interpretation is that the requested numeric or named index does not identify an existing element in the current collection state. 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 IDispatch collection access, property indexing, or a dispatch helper that validates an index.
- 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 assumes zero-based indexing; the collection changed; a stale index is reused; the key belongs to another collection. 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 requested numeric or named index does not identify an existing element in the current collection state. 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 collection count and version; requested index; zero- or one-based convention; deletion events; enumerator position.
- 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 current bounds, prefer stable keys where supported, handle concurrent mutation, and avoid retrying the same stale index. 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 COM collection is one-based, but a C++ loop starts at zero; adjusting the bounds removes the first failing access.
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_MEMBERNOTFOUND concerns an unknown dispatch member; it concerns an invalid element position supplied to a known member.
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.