Fixing “Automation Error: Library Not Registered” in Mixed 32/64-Bit Environments

The error “Run-time error ‘-2147319779 (8002801d)’: Automation error: Library not registered” occurs when an Excel VBA macro tries to call a COM component, Dynamic Link Library (DLL), or Type Library (.tlb / .olb) whose registry entry points to an incompatible bitness or a missing path.

This break frequently happens in mixed environments—such as when an organization transitions from 32-bit to 64-bit Microsoft 365, or when 32-bit third-party COM add-ins and ActiveX controls are executed inside 64-bit Excel.

Quick Answer

This error means 64-bit Excel is trying to use a 32-bit library (or vice versa), or an Office update left behind an orphaned registry key pointing to a removed bitness. To fix it immediately for native Windows components, open an elevated Command Prompt and re-register the library using the correct bitness path:

For 32-bit controls on 64-bit Windows: C:\Windows\SysWOW64\regsvr32.exe <library_name>.ocx

For 64-bit controls: C:\Windows\System32\regsvr32.exe <library_name>.ocx

If the library is an outdated third-party 32-bit control (like older Common Dialog or DatePicker controls), it cannot run in 64-bit Excel; you must rewrite the call to use a 64-bit compatible component or migrate the code.

---

Why Mixed Bitness Breaks Automation

A 64-bit process cannot execute 32-bit binaries directly within its memory address space. When you run 64-bit Excel, every compiled DLL, OCX control, and Automation server called by VBA must also be 64-bit.

When Office is upgraded or side-by-side versions exist, two primary issues create the “Library not registered” condition:

1. The Registry Bit-Bridge Fails: Windows stores 64-bit registration keys in HKEY_CLASSES_ROOT\TypeLib and maps 32-bit keys under HKEY_CLASSES_ROOT\WOW6432Node\TypeLib. If an uninstaller or update removes a 32-bit file but leaves the 32-bit TypeLib GUID pointing to a dead file, 64-bit Excel may read the obsolete branch and fail to locate the 64-bit interface.
2. Incompatible ActiveX Controls: Legacy forms using controls such as MSComCtl.ocx (ListView, TreeView, MonthView) are strictly 32-bit binaries. When loaded into 64-bit Excel, the VBA engine attempts to bind to the control, finds no compatible 64-bit registration entry, and halts with error 2147319779.

---

Diagnostic Workflow

Follow these steps in order to pinpoint where the registration path is broken.

Automation Error: Library Not Registered
 │
 ├── Step 1: Identify Excel Architecture
 │    └── File > Account > About Excel (32-bit vs. 64-bit)
 │
 ├── Step 2: Check VBA Project References
 │    └── Developer > Visual Basic > Tools > References
 │    └── Look for "MISSING:" prefixes
 │
 ├── Step 3: Re-register the Failing File
 │    ├── 32-bit file -> Register via SysWOW64\regsvr32.exe
 │    └── 64-bit file -> Register via System32\regsvr32.exe
 │
 └── Step 4: Clean Orphaned TypeLib Registry Keys
      └── Remove dead version GUIDs under HKCR\TypeLib

Step 1: Verify Office and Add-In Bitness

First, confirm the architecture of the host application:

1. Open Excel and click File > Account.
2. Click About Excel.
3. Note the bitness displayed at the top of the dialog box (e.g., Microsoft® Excel® for Microsoft 365 MSO (Version ...) 64-bit).

If you are running 64-bit Excel and your macro relies on legacy 32-bit APIs, review 32-bit vs. 64-bit: Fixing “The code in this project must be updated for use on 64-bit systems”. If your code requires Windows API declarations, you must add the PtrSafe attribute and use LongPtr variables as detailed in Using PtrSafe and LongPtr for Windows API declarations.

Step 2: Identify Missing or Conflicting References

1. Press Alt + F11 to open the Visual Basic Editor (VBE).
2. Click Tools > References.
3. Scroll through the selected libraries at the top of the list.
4. Look for any item marked with the prefix MISSING:.

If you see a MISSING: library:

• Uncheck it.
• If the control is no longer needed, click OK, save the file, and test the macro.
• If the control is required, note the file path displayed at the bottom of the dialog. If the path references C:\Program Files (x86)\... while running 64-bit Excel, the project is pointing to a 32-bit registration key.

Step 3: Re-registering the Dynamic Link Libraries

To fix libraries that are present on the disk but have lost their system registry hooks:

1. Close Excel completely.
2. Press the Windows Start button, type cmd, right-click Command Prompt, and select Run as Administrator.
3. Run the registration tool corresponding to the component’s architecture:

For a 32-bit DLL or OCX component:

cd C:\Windows\SysWOW64
regsvr32.exe /u ComponentName.ocx
regsvr32.exe ComponentName.ocx

For a 64-bit DLL or OCX component:

cd C:\Windows\System32
regsvr32.exe /u ComponentName.dll
regsvr32.exe ComponentName.dll

A popup should confirm: DllRegisterServer in ComponentName succeeded. If it returns an error 0x8002801c, the command prompt was not launched with elevated administrator permissions.

Step 4: Purge Orphaned TypeLib Keys in the Registry

If re-registering does not resolve the error, an earlier Office installation (such as a 32-bit Office 2016 install replaced by 64-bit Microsoft 365) likely left an orphaned registration branch behind.

1. Press Win + R, type regedit, and press Enter.
2. Press Ctrl + F and search for the specific library name (for example, Excel.Sheet or the name of the missing control).
3. Alternatively, check the standard Excel TypeLib container:
   HKEY_CLASSES_ROOT\TypeLib\{00020813-0000-0000-C000-000000000046}
4. Review the version subkeys (such as 1.8 for Office 2013, 1.9 for Office 2016/365).
5. If you see a version key pointing to a folder path that does not exist on your computer (such as a Program Files (x86) path on a machine that now runs 64-bit Office in Program Files), export a backup of that key, then delete the outdated subkey.
6. Restart the computer.

---

When a Control Cannot Be Migrated

If your macro relies on proprietary 32-bit third-party OCX controls (such as custom measurement devices, industrial barcoders, or legacy ERP add-in controls) that were never compiled into 64-bit binaries:

1. Option A (Code Modernization): Replace the control with native modern Excel forms. For example, replace the 32-bit MSComCtl2.DTPicker (DatePicker) with an API-free VBA userform calendar.
2. Option B (Architecture Downgrade): If enterprise software dictates using legacy 32-bit DLLs that cannot be upgraded, uninstall 64-bit Office and install the 32-bit version of Microsoft 365. 32-bit Office runs smoothly on 64-bit Windows via the WoW64 subsystem and supports older automation libraries without registration errors.