Runtime Error 440: “Automation error,” explained and fixed

Error 440, “Automation error”, is VBA's least informative message: a call into an external (COM/Automation) object failed, and the object did not map its failure onto a specific VBA error. The number is a wrapper, not a diagnosis; the real information is in the component that returned it, in Err.Description beyond the generic words when the component provides it, and in that component's own documentation and logs. Treating 440 as a single error is the mistake; it is a category of other programs' errors wearing one coat.

For people who just run the program

  1. Read the full dialog, not just the number. Automation error dialogs often carry a second sentence from the component itself; that sentence, not “440,” is what support needs.
  2. Note which program the tool was driving. The failing component is the other program (the database engine, the mail program, the design tool), and its health is the first thing to check: open it directly and confirm it works alone.
  3. Repair or update the driven program. A component that fails standalone will fail under automation; fixing the component fixes the macro.
  4. Report the exact moment. Which external action was under way (connecting, opening, saving, sending) narrows which of the component's operations returned the failure.

For people who write the code

  1. Capture everything Err offers at the failure. Err.Number says 440, but Err.Description frequently carries the component's own text after the generic phrase, and Err.Source names the component. Log all three, always.
    2. On Error GoTo Fail
Set res = engine.Run(jobSpec)
' ...
Fail:
    LogError Err.Number, Err.Source, Err.Description
    ' For 440, Source and the tail of Description ARE the error.
  2. Reproduce the call outside your code. Drive the same component from a five-line test procedure with the same arguments. If it fails there, your code is exonerated and the component's documentation for its returned HRESULT becomes the reference.
  3. Decode the HRESULT when provided. Many components return a raw COM error code; searching that code against the component vendor's documentation (not VBA's) is where 440s actually get solved.
Do not build handling that keys only on 440. It aggregates unrelated failures (a refused connection and a bad argument can both arrive as 440). Handle by operation and by Source, or present the component's text to the user, rather than pretending 440 names one condition.

If it still happens

If a call fails with 440 in production but works in testing, compare the component versions and the security context (user account, elevation, session) between the two. Automation components frequently refuse calls from contexts they were not installed or licensed for, and report the refusal as a bare 440.

Common questions

Why does error 440 have no useful message? Because the failure originated outside VBA, in a component that returned a generic failure code. VBA can only report that the Automation call failed; the detail belongs to the component, which is why Err.Source and the description text matter.

Is error 440 the same as error 429 or 430? No. 429: the object could not be created. 430: the object does not support Automation. 440: the object was created and called, and the call itself failed inside the component.

Related errors

Runtime Error 430 · Runtime Error 438 · Runtime Error 429