Fix TYPE_E_WRONGTYPEKIND (0x8002802A) – Registry Type Mismatch

I know this error makes you want to throw your keyboard across the room. You're coding, registering a COM component, or running an old VB6 app, and suddenly 0x8002802A slaps you in the face. Let's fix it so you can get back to work.

The Fast Fix: Re-Register the Problematic DLL

Nine times out of ten, this error means a DLL or OCX you registered is pointing to the wrong type library. Start here:

1. Open Command Prompt as Administrator (search for cmd, right-click, choose Run as administrator).
2. Find the component that's failing. If you don't know which one, look at the error message – it usually mentions a specific file or CLSID.
3. Run this command, replacing your.dll with the actual file name:

regsvr32 /u your.dll
regsvr32 your.dll

This unregisters and re-registers the DLL. I've seen this fix the mismatch instantly. Works on Windows 10, 11, and even Server 2019.

Still Broken? Check the Registry

If re-registration didn't cut it, the registry likely has a stale or wrong type library entry. Open regedit (again as Administrator) and navigate to:

HKEY_CLASSES_ROOT\TypeLib\{YOUR-GUID}

Look for the GUID associated with your DLL. You can find it by searching for the DLL name. Once there, expand the version folder (e.g., 1.0). Under that, you'll see subkeys like 0, 1, 2, etc. – these represent different language/locale IDs. The error means the type kind (like TKIND_COCLASS vs TKIND_INTERFACE) doesn't match what the caller expects.

What to do: Delete the entire GUID branch and re-register the DLL from scratch. I'm serious – nuke it. Back up the key first (right-click > Export). Then run the two regsvr32 commands again. This forces the system to rebuild the type library entry correctly.

Why This Happens

Under the hood, Windows uses type libraries to tell COM clients what interfaces, classes, and enums a component exposes. Each type entry in the registry has a TKIND – kind of like a label saying "I'm a coclass" or "I'm an interface." When a client asks for a specific type and finds a mismatched TKIND, it throws TYPE_E_WRONGTYPEKIND.

Common triggers:

• You installed a new version of a component over an old one without uninstalling first.
• A third-party installer left behind corrupted registry entries.
• You manually copied a DLL from another machine – bad idea, don't do that.

Less Common Variations

Sometimes the error sneaks in during VB6 development. If you're using CreateObject or GetObject and hitting this, the real fix isn't registry hacking – it's your code. Check that the ProgID you're referencing matches the actual type library. For example, if you wrote:

Dim obj As Object
Set obj = CreateObject("MyApp.SomeClass")

And MyApp.SomeClass is actually an interface, not a coclass, you'll get this error. The solution: use the correct ProgID for a creatable class, or if you must use the interface, get a reference through another object.

Another edge case: running 64-bit Windows and trying to register a 32-bit DLL. The type library paths differ between SysWOW64 and System32. Use the right regsvr32 version – %SystemRoot%\SysWOW64\regsvr32.exe for 32-bit DLLs.

Prevention: Keep Your Registry Clean

Stop the error before it starts. Here's what works:

• Always uninstall old versions before installing new ones. Use the component's installer, not brute force.
• Use regsvr32 with the /u flag to cleanly remove a DLL before replacing it.
• Don't mix bitness – keep 32-bit and 64-bit COM components in their own silos.
• Run a registry cleaner like CCleaner (yes, I'm recommending it) after major software changes. It won't fix everything, but it catches orphaned type library entries.

One last thing: if you're dealing with a legacy VB6 app, consider wrapping the COM calls in error handling. A simple On Error Resume Next won't fix the root cause, but it'll give your users a cleaner crash message instead of this cryptic hex code.

That's it. Go re-register, nuke the registry key if needed, and get that old app running again. You've got this.