DISP_E_UNKNOWNNAME (0X80020006) Fix: COM Name Mismatch

What DISP_E_UNKNOWNNAME Actually Means

You get 0x80020006 when your code tries to call a property or method on a COM object that the object's type library doesn't recognize. The component exists, but the member name you're using isn't in its interface. The two most common real-world triggers:

1. You're automating Excel from VBScript or PowerShell and calling .Range but the COM object is a version mismatch.
2. A legacy VB6 app tries to bind to a COM control whose CLSID has drifted due to a Windows update or reinstall.

Cause #1: Registry CLSID Doesn't Match the Typelib

The most common cause — by a mile — is that the COM class's registry entry points to a typelib (TLB) file that doesn't exist, or the CLSID's InprocServer32 path points to a different DLL version. When COM loads the object, it tries to resolve member names from the typelib. If the typelib is missing or mismatched, you get DISP_E_UNKNOWNNAME.

How to Diagnose

1. Open Registry Editor (regedit).
2. Navigate to HKEY_CLASSES_ROOT\CLSID\{the-clsid-from-your-error}. You can find the CLSID by searching the error's HRESULT (0x80020006) in the Event Viewer under Windows Logs > Application — look for the clsid field.
3. Under that CLSID, check InprocServer32 — the default value should point to a real DLL file. Right-click and open that path in File Explorer.
4. If the DLL is missing or wrong, that's your cause.

The Fix

Re-register the component. Run this from an admin command prompt:

regsvr32 "C:\path\to\your.dll"

If you don't know the DLL name, search the CLSID in HKEY_CLASSES_ROOT\CLSID — the InprocServer32 key has the path. Re-registration rewrites the typelib bindings. What's happening is regsvr32 calls the DLL's DllRegisterServer export, which recreates the registry entries and forces a refresh of the type library cache.

Cause #2: Stale Type Library Cache

Sometimes the registry is fine, but Windows cached an old version of the typelib. This happens when you update a COM DLL without rebooting, or when side-by-side assemblies get confused (common on Windows 10 1809+). The cache lives in %USERPROFILE%\AppData\Local\Microsoft\Windows\INetCache or in the system's type library cache (HKEY_CLASSES_ROOT\TypeLib).

How to Diagnose

Check if a different version of the same component is installed. For example, if you're getting DISP_E_UNKNOWNNAME in Excel VBA with a custom COM add-in, verify the add-in's version in Add-In Manager. If the version doesn't match what the VBA project references, you've got stale cache.

The Fix

Clear the type library cache and force a rebuild:

1. Close all apps that use the COM component (Excel, Word, etc.).
2. Open an admin command prompt.
3. Run: reg delete HKEY_CLASSES_ROOT\TypeLib /f — this wipes the entire type library cache. Note: This is safe because Windows rebuilds it on demand, but it'll cause a brief performance hit the next time any COM component loads.
4. Reboot.

If you don't want to nuke all typelibs, narrow it down. Search HKEY_CLASSES_ROOT\TypeLib for the GUID of your component (you can find this in the DLL's embedded manifest or in the original installation logs). Delete only that subtree.

Cause #3: Late Binding with Wrong Interface Name

This one's on you — the code. If you're using late binding (e.g., CreateObject("SomeApp.Application") and then calling a method that doesn't exist in that version's interface), you'll hit 0x80020006. The difference from cause #1 is that the COM object loads fine, but it doesn't know about the member you called.

How to Diagnose

Open the VBA editor or PowerShell ISE. Check your object's type. For example, if you Set obj = CreateObject("Excel.Application") and later call obj.SomeMethod, verify SomeMethod exists in the Excel Object Library for your version. In VBA, press F2 to open the Object Browser and search for the method. If it's not listed, that's the problem.

The Fix

Switch to early binding by adding a reference to the correct type library. In Excel VBA, go to Tools > References and check "Microsoft Excel XX.0 Object Library" (pick the one matching your installed version). Then declare your object as Dim obj As Excel.Application instead of As Object. Early binding gives you compile-time checking — no more DISP_E_UNKNOWNNAME at runtime.

If you must use late binding (e.g., for version independence), call TypeName(obj) to confirm the correct interface. Then use CallByName or wrap the call in error handling to check if the method exists before calling it.

Quick-Reference Summary

Start with cause #1. That's the one that bites people after reinstalls or Windows updates. If the DLL is there and registered, move to cause #2. Only debug your code (cause #3) after ruling out the system.