Runtime Error 432: “Filename or class name not found during Automation operation,” explained and fixed

Error 432, “Filename or class name not found during Automation operation”, belongs to GetObject, which accepts either a file path (load the object from this file) or a class name (get or create an instance of this class). Error 432 says the named thing could not be found in the role it was offered: the file is not there (or is not a loadable object file), or the class name is not a registered class on this machine. The two forms fail identically, so the first step is knowing which form the call used.

For people who just run the program

  1. Check the file exists at the expected path. GetObject-by-file workflows (opening a document as an object) fail with 432 after the file is moved, renamed, or the drive letter changes.
  2. Check the companion program is installed. If the error names a class, the program providing that class may be absent, uninstalled, or present in a version that registers a different name.
  3. Note whether it follows a machine change or reinstall. Class registrations do not travel with documents; a macro moved to a new PC meets every unregistered class at once, starting with this error.
  4. Report the full message. For once, the long message is informative: it says the missing thing was a filename or a class name, and the maintainer will know which the code passed.

For people who write the code

  1. Determine which GetObject form failed. GetObject(path) with a path is the file form; GetObject(, "Prog.ID") or a class-only string is the class form. The fixes diverge completely, so read the call before repairing the environment.
    2. Set doc = GetObject("C:\Data\report.docx")      ' file form: 432 = not found
Set xl = GetObject(, "Excel.Application")          ' class form: 432 = not registered
' (note the empty first argument in the class form)
  2. Validate file paths the usual way. Dir$ the path first and raise a precise “file missing” error of your own; it saves every future reader from decoding 432.
  3. For class names, verify the ProgID. A versioned ProgID (Vendor.App.2) registered by one release and not the next is the standard trap. Prefer the version-independent ProgID where the vendor offers one.
GetObject's class form attaches to a running instance when one exists. Code that expects a fresh object may receive a busy or differently-configured running instance, and later failures get blamed on 432's call. Know which behavior the workflow needs; CreateObject is the explicit “new instance” tool.

If it still happens

If the file exists and the class is registered, check the context: under a different user account or an elevated process, both file visibility (mapped drives) and per-user class registrations change. The name is found in your session and not found in the session the code actually runs in.

Common questions

What is the difference between GetObject and CreateObject? CreateObject always makes a new instance of a class. GetObject can load an object from a file, or attach to an already-running instance of a class. Error 432 is specific to GetObject's lookup failing.

Can a typo cause error 432? Yes, in both forms: a misspelled path and a misspelled ProgID are equally “not found.” Comparing the string in the code against the file system or the registry is the first check.

Related errors

Runtime Error 429 · Runtime Error 430 · Runtime Error 440