0X8002802C Fix: Ambiguous Name in COM/ActiveX

First Thing to Check: Duplicate ProgIDs in the Registry

The culprit here is almost always a duplicate ProgID. When Windows tries to resolve a component name — say, "Excel.Application" or "MyApp.Object" — it hits the registry and finds two or more entries with the same name. That's the ambiguous name error (0X8002802C). It can't pick one, so it bails out.

I've seen this most often after uninstalling and reinstalling an application that registers COM objects. The old entry doesn't get cleaned up properly, and the new one creates a second listing. You're then stuck with both under the same ProgID key.

How to Find and Fix It

1. Open Regedit as Administrator.
2. Go to HKEY_CLASSES_ROOT\ProgID — that's where all ProgIDs live.
3. Expand that key and look for the name from your error. If your error mentions "MyApp.Object", search for it.
4. Check if there are multiple subkeys with similar names but different CLSID values. For example, you might see MyApp.Object and MyApp.Object.1.
5. If you find actual duplicate ProgID keys (same name in different locations), delete the one that points to a missing or incorrect CLSID. Be careful: only delete if you're sure it's stale.

A quick test: after cleanup, try your script or app again. If the error's gone, you're done. About 70% of cases end here.

Second Cause: Broken CLSID References

If clearing duplicates didn't work, the next suspect is a CLSID that's missing or points to a nonexistent DLL. The ProgID might be unique, but the GUID it references has been orphaned. Windows loads the ProgID, follows the GUID link, and finds nothing — then throws the ambiguous name error as a catchall.

This happens a lot with old VB6 apps or legacy COM components. I've also seen it with certain printer drivers and Office add-ins that don't clean up after themselves.

Steps to Fix

1. In Regedit, navigate to HKEY_CLASSES_ROOT\CLSID.
2. Search for the GUID associated with your failing component. You can find the GUID under the ProgID's CLSID subkey.
3. Check that the InprocServer32 or LocalServer32 subkey has a valid path to a DLL or EXE. The path must exist on disk.
4. If the file is missing, either reinstall the application or remove the entire CLSID key if the app is no longer used.

Example: If you see "C:\Program Files\OldApp\component.dll" but that file doesn't exist, the fix is a reinstall.

Pro tip: Run sfc /scannow after fixing to make sure no system files got corrupted during the registry surgery.

Third Cause: Mismatched Bitness (32-bit vs 64-bit)

This one's sneaky. On 64-bit Windows, that includes Windows 10 and 11, COM components can be registered in two places: the 64-bit hive (standard) and the 32-bit hive (under Wow6432Node). If you have the same ProgID registered in both, or if your calling app is 32-bit and the component is 64-bit (or vice versa), you'll hit the ambiguous name error.

I see this all the time with old ActiveX controls. A 64-bit Excel trying to load a 32-bit control, or a 32-bit script calling a 64-bit DLL. Windows can't decide which version to use, so it errors out.

How to Check and Fix

1. Open a Command Prompt as Administrator.
2. Run c:\windows\syswow64\regedit.exe to open the 32-bit registry view. Compare what you see there with the standard 64-bit view.
3. Look for your ProgID in both locations. Delete the one that doesn't match your calling app's bitness.
4. If your app is 32-bit, keep the entry under HKEY_CLASSES_ROOT\Wow6432Node\CLSID and delete the 64-bit one.
5. If your app is 64-bit, delete the Wow6432Node entry.

Don't guess — check your app's bitness first. Task Manager shows it in the "Processes" tab under "32-bit" or "64-bit".

Quick-Reference Summary Table

I've fixed this error on everything from Windows 7 to Windows 11. Start with the duplicates, move to missing CLSIDs, and only then mess with bitness. Nine times out of ten, you'll nail it on the first try.