| Previous | Next |
| DISP_E_UNKNOWNLCID | DISP_E_BADPARAMCOUNT |
DISP_E_ARRAYISLOCKED
Automation SAFEARRAY is locked
DISP_E_ARRAYISLOCKED is HRESULT 2147614733 (0x8002000D) from winerror.h. AllStat describes it as “Memory is locked.” The value must be interpreted at SAFEARRAY mutation, redimensioning, destruction, or transfer during an Automation call, because the same high-level symptom can come from a different contract boundary and require different cleanup.
The decisive Interpretation is that the requested operation requires an unlocked SAFEARRAY but one or more locks are still active. When this result crosses a language or process boundary, preserve its original numeric form before projections replace it with a broad exception class.
Where the result appears
- This result is returned while Automation binds or executes SAFEARRAY mutation, redimensioning, destruction, or transfer during an Automation call.
- 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.
Triage of this result starts by locating the exact owner of the failing state, including object identity, apartment, package, and deployment generation.
Typical causes and interpretation boundary
Common cause categories for it are: SafeArrayUnaccessData was skipped; nested code holds a lock; an exception bypassed cleanup; another component retains direct access. Do not treat the cause list for it as a checklist of simultaneous failures; use traces and postconditions to select the matching branch.
The check that separates this result from nearby HRESULTs is: the requested operation requires an unlocked SAFEARRAY but one or more locks are still active. A recovery decision for it should wait until the decisive condition is observed in call data, component state, or metadata.
Evidence and telemetry
- Record it with the object CLSID or ProgID, interface identity, member DISPID, dispatch flags, and type-library version.
- capture SAFEARRAY pointer; lock count; SafeArrayAccessData calls; exception path; owning thread; by-reference use.
- 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.
When recording it, retain structural metadata and redact content-bearing arguments, authentication material, and personal data.
Correct handling and recovery
The appropriate recovery is to pair every access with guaranteed unlock, use scoped cleanup, and perform redimension or destruction only after the lock count reaches zero. A retry policy for it needs a bounded attempt count, a state refresh step, and a rule for reconciling work that may already have completed.
Cleanup following it must be generation-aware: do not destroy shared state or outputs owned by an earlier successful operation.
Practical scenario
A conversion routine throws after SafeArrayAccessData; a finally block is added to call SafeArrayUnaccessData before cleanup.
Coverage for it should include the exact failure, a corrected success case, and the closest related HRESULT so classification remains stable.
Difference from related HRESULTs
DISP_E_BADVARTYPE concerns the array’s VARIANT tag; it concerns its current synchronization and access state.
Tests and telemetry should encode the boundary around it so future wrappers do not flatten it into an ambiguous generic exception.
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
Looking for a different code? Search another status or error code.