Fix TYPE_E_ELEMENTNOTFOUND 0x8002802B in COM

This error usually pops up when a COM call can't find a registered type library or interface. It's almost always a broken registry path or a missing DLL.

When this error shows up

You're writing a script or an application that calls a COM object — maybe an old ActiveX control, a custom DLL, or something from a third-party SDK. You get back 0x8002802B with the message "Element not found." This can happen during CoCreateInstance, QueryInterface, or when trying to load a type library via LoadTypeLib. I've seen this most often with legacy apps on Windows 10/11, especially after a Windows update or when moving a COM DLL between machines.

Root cause

The COM subsystem can't find the type library entry it needs. The registry key under HKEY_CLASSES_ROOT\TypeLib\{GUID} is missing, points to a file that doesn't exist, or the version number is wrong. Another possibility: the DLL itself wasn't properly registered, so the type library path was never written. This differs from REGDB_E_CLASSNOTREG — that's the class not existing at all. Here, the class exists, but the type library it references is AWOL.

Fix it: step by step

Step 1: Find the CLSID that's failing

Check the error logs or add debug output to see which CLSID (class ID) triggered the error. If you're using C++, wrap the call in a try/catch and print the CLSID. For PowerShell or VBScript, the error object usually contains the source. Once you have the CLSID, look it up in the registry:

reg query HKCR\CLSID\{your-clsid-here}

Step 2: Check the InprocServer32 or LocalServer32 path

Inside that CLSID key, there's usually a InprocServer32 subkey (for in-process DLLs) or LocalServer32 (for EXE servers). Verify the default value points to an existing file. If it's a DLL, try registering it again:

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

If regsvr32 fails, the DLL itself is corrupted or missing dependencies — fix that first.

Step 3: Look at the TypeLib registry key

The CLSID entry also has a TypeLib subkey with a GUID. That GUID points to the type library. Navigate to:

HKEY_CLASSES_ROOT\TypeLib\{typelib-guid}

Under that, you'll see version subkeys (e.g., 1.0, 1.1). Inside the version key, there's a 0 subkey (for neutral locale) or a locale-specific one (e.g., 0x0409 for English US). The default value there should be the full path to the .tlb file or the DLL that contains the type library. If that path is wrong or missing, that's your culprit.

Step 4: Repair the type library path

If the file exists but the path is wrong, update it. Use regedit to edit the default value under the locale subkey. For example, if the path says C:\OldPath\component.tlb but the file is now at D:\NewApp\component.tlb, change it. If the file doesn't exist anywhere, reinstall the component or restore it from backup.

Step 5: Rebuild the type library registration

Sometimes the entire TypeLib key is missing. In that case, you need to rebuild it. If you have the original .tlb file, you can register it with:

regtlibv12 "C:\path\to\your.tlb"

Note: regtlibv12 is old and not present on all systems. Alternatively, use PowerShell:

$tlb = [System.Runtime.InteropServices.Marshal]::LoadTypeLib("C:\path\to\your.tlb")
$tlb.GetTypeInfo(0).GetTypeLibAttr()

This doesn't write to the registry directly, but it confirms the .tlb is loadable. To register it properly, use the RegisterTypeLib API from a script or small C++ helper. Or just reinstall the software.

Still failing?

Check permissions: The user account running the app might not have read access to the registry keys or the DLL/tlb file. Run procmon (Process Monitor) and filter on the CLSID or file path to see access denied errors.
32-bit vs 64-bit mismatch: If you're on a 64-bit system and the COM object is 32-bit, your calling app must also be 32-bit. The registry paths are different: HKCR\CLSID for 64-bit, HKCR\Wow6432Node\CLSID for 32-bit. I've lost hours to this — double-check your bitness.
Corrupt type library file: The .tlb file might be from a different version of the DLL. Compare file versions or rebuild from the IDL source.
Use OleView: Download OleView from the Windows SDK. It can enumerate all registered COM objects and type libraries. If it shows your type library with errors, you'll see exactly what's broken.

This error is stubborn but not mysterious. It's always a registry path or missing file. Hunt down that GUID, fix the path, and you're done.