Runtime Error 430: “Class doesn't support Automation,” explained and fixed

Error 430, “Class doesn't support Automation”, means an object exists but cannot be talked to through the standard Automation (IDispatch) interface VBA uses. The usual reasons are version-shaped: the class registered on the machine is an older or newer build than the code expects and its interface differs, or the class was never designed for Automation at all. It commonly follows installing a different version of a component over an existing one, leaving registration pointing at a build that does not match the type library the code was compiled against.

For people who just run the program

  1. Expect it right after installing or upgrading related software. A component updated by one product breaks another product's macros with exactly this complaint.
  2. Repair the component's installation rather than the document. Reinstalling (or repairing) the program that provides the object re-registers the correct class; the document and macro are bystanders.
  3. Check whether two versions of the same software coexist. Side-by-side versions fight over which class registration wins, and the loser produces error 430 in the winner's macros.
  4. Report what was installed or upgraded last. For 430, the install history is the diagnosis.

For people who write the code

  1. Recompile against the installed library. If the component's version changed, set the reference to the version actually present and recompile; a project bound to a vanished type library raises 430 (or its cousin 429) at the first CreateObject.
  2. Distinguish 429 from 430. 429 means the object could not be created at all. 430 means creation produced something that does not expose the expected Automation interface. The line that fails, and whether any object came back, separates them.
    3. Set app = CreateObject("Vendor.App")  ' 429: cannot create; 430: created
' but not Automation-compatible with what the code expects
  3. Pin versions deliberately in shared environments. Where several tools share a component, document the required version and check it at start-up (the registry or the file version), failing with a clear message instead of a bare 430 deep in a run.
Registering DLLs by hand (regsvr32) at random creates more 430s than it cures. It can point registration at an arbitrary build on disk. The supported route is the vendor's installer or repair, which registers the intended version consistently.

If it still happens

If the version is right and registration is clean, the class may be an in-process object that only supports Automation from a matching bitness host: a 32-bit-only component cannot serve a 64-bit Office process. Confirm the component's supported hosts; the remedy is a matching host or an out-of-process surrogate.

Common questions

What is Automation in this context? The COM mechanism (IDispatch) by which VBA discovers and calls an object's methods and properties by name at run time. A class that does not implement it cannot be driven from VBA, which is what error 430 reports.

Can error 430 appear after a Windows update? Yes, when the update replaces or re-registers a shared component with a different build. The timing is the clue: code unchanged, component changed, error appears.

Related errors

Runtime Error 429 · Runtime Error 438 · Runtime Error 443