Fix 0x8002802D: Name already exists in the library

You're installing some legacy software, maybe an old VB6 app or a COM component. You run regsvr32 on a DLL, and it fails with error code 0x8002802D (TYPE_E_NAMECONFLICT). The message says "Name already exists in the library." This typically happens when you're trying to register a COM object whose CLSID, ProgID, or type library name is already taken by something else in the system. I see this most often with ActiveX controls, third-party add-ins, or custom DLLs that share a naming collision with an existing Microsoft component or another vendor's product. The Windows Registry can't have two entries with the same key under type libraries or classes.

What's actually happening

When regsvr32 runs, it calls DllRegisterServer in the DLL. That function tries to create registry entries under HKEY_CLASSES_ROOT\CLSID or HKEY_CLASSES_ROOT\TypeLib. If a key with that exact name already exists, Windows throws up its hands and gives you 0x8002802D. The registry is a flat namespace in that section — no duplicates allowed.

The culprit here is almost always a leftover entry from an old install, or a different version of the same component that registered under the same GUID or name. Sometimes it's a security software that locked the key. But 90% of the time, it's a stale registry entry.

How to fix it

Find the conflicting entry. Open Regedit (as Administrator). Go to HKEY_CLASSES_ROOT\TypeLib and browse for your component's LIBID. The LIBID is a GUID — look in the DLL's documentation or use OleView (available in Windows SDK) to see what it's trying to register. If you can't find the LIBID, search for the DLL name or ProgID under HKEY_CLASSES_ROOT.
Back up the key. Before deleting anything, right-click the suspect key and export it to a .reg file. You'll thank me later if you delete the wrong thing.
Delete the duplicate. Remove the conflicting key under HKEY_CLASSES_ROOT\CLSID or HKEY_CLASSES_ROOT\TypeLib. If there's more than one version listed (e.g., 1.0 and 2.0), only delete the one that matches the old or conflicting component. Leave any key that belongs to a known Microsoft or system component — you don't want to break Windows.
Re-register the DLL. Run regsvr32 yourfile.dll again from an elevated command prompt. If it succeeds, the fix is done.
If it still fails, check for permission issues. Sometimes a key is owned by TrustedInstaller and can't be deleted directly. Take ownership of the key first:
```
takeown /f "HKCR\CLSID\{YOUR-GUID}" /r /d y
icacls "HKCR\CLSID\{YOUR-GUID}" /grant Administrators:F /t
```
Then delete it.

Still stuck? Try these

Run sfc /scannow to check for system file corruption — rare but possible.
Use the OleView tool (from Windows SDK) to see all registered COM objects. Filter by the LIBID to spot conflicts visually.
Check if the DLL is 32-bit but you're running 64-bit regsvr32. Use the 32-bit regsvr32 from C:\Windows\SysWOW64 instead:
```
%systemroot%\SysWOW64\regsvr32 yourfile.dll
```
If you're on a locked-down corporate machine, you might need IT to grant write access to HKCR. No way around that.

I've seen this exact error dozens of times, and the fix is nearly always a stale registry entry. Don't waste time reinstalling the whole app — just hunt down the duplicate key and kill it. If you're still stuck after the steps above, post the exact GUID and the name of the DLL in the comments and I'll point you at the right key.