CO_S_NOTALLINTERFACES (0X00080012): The Real Fix That Works

The Most Common Cause: A Broken or Missing DLL Registration

When you see 0X00080012, it almost always means a COM component was partially registered. The class exists in the registry, but one or more of its interfaces didn't get registered. This happens all the time after a half-baked install or when someone manually copied a DLL without running regsvr32.

Here's the scenario: you install some third-party tool, it fails midway, but leaves registry entries behind. Now every app that tries to use that component throws 0X00080012. I've seen this with printer drivers, database clients, even graphics card utilities.

The fix is straightforward — re-register the component. But first you need to know which one is failing. Check the application's error logs or use ProcMon from Sysinternals to trace the registry lookups. Filter for RegOpenKey operations that return NAME NOT FOUND. That'll point you to the CLSID.

Once you have the CLSID, look it up in the registry at HKCR\CLSID\{your-CLSID} (or HKLM\SOFTWARE\Classes\CLSID). Check the InprocServer32 key — the default value should be the full path to the DLL. If that path is empty or points to a nonexistent file, you've found your problem.

Run this from an elevated command prompt:

regsvr32 /s "C:\path\to\your\component.dll"

Substitute the actual path. If you get a success message, try your application again. In most cases, this alone resolves 0X00080012. Don't bother rebooting unless the DLL is a shell extension — those sometimes need a fresh explorer.exe.

The Second Cause: 32-bit vs 64-bit DLL Mismatch

Here's the trap. You install a 32-bit application on a 64-bit Windows and something goes sideways. The app tries to load a 32-bit DLL that was registered in the 64-bit view of the registry, or vice versa.

Windows keeps two registry views. 64-bit processes see the full picture, but 32-bit processes get redirected to Wow6432Node. If your DLL was registered in the wrong view, the component loads but the interface marshaling fails. Classic 0X00080012.

To fix this, register the DLL in the correct view. If your application is 32-bit, use the 32-bit version of regsvr32 located at:

C:\Windows\SysWOW64\regsvr32.exe

For a 64-bit DLL, use the one in C:\Windows\System32\regsvr32.exe. Yes, I know it's confusing — SysWOW64 holds 32-bit tools, System32 holds 64-bit ones. That's Windows for you.

Also check the registry path. For a 32-bit component on 64-bit Windows, the CLSID should be under HKLM\SOFTWARE\Wow6432Node\Classes\CLSID. If it's missing there, the application won't find it. You can manually copy the key from the 64-bit view, but that's a last resort. Re-registering correctly is safer.

When you're not sure which bitness your DLL is, open a command prompt and run dumpbin /headers your.dll (from Visual Studio tools) or just look at the file's properties — Windows Explorer shows "64-bit" in the description sometimes. Or use PowerShell:

Get-PEHeader your.dll

If you don't have that cmdlet, install the NtObjectManager module. Or just try both regsvr32 versions — the wrong one will fail with an error about the module being incompatible.

The Third Cause: Registry Permissions or Orphaned Entries

Less common but still shows up. Sometimes the registry keys for the interface are locked down — a bad uninstall left restrictive ACLs, or a previous admin set permissions that block the current user. When COM can't read the interface registration, it returns 0X00080012.

Check permissions on the CLSID key. Right-click the key in regedit, select Permissions, and make sure Everyone or Administrators at least has Read. If you see a bunch of unknown SIDs, that's your clue something got mucked up.

Also look for orphaned keys. If the DLL was replaced but the registry still points to an old proxy/stub DLL for the interface, you'll get this error. Use a registry cleaner or manually search for the CLSID in HKCR\Interface. The interface IDs are GUIDs that map to proxy DLLs. If a proxy DLL is missing, re-register the component or reinstall it.

In a pinch, you can delete the entire CLSID key and re-register. The component will create fresh entries with default permissions. But back up the registry first — I've seen sysadmins nuke the wrong key and break half the system.

That's the whole thing. Nine times out of ten it's the first cause. Don't overthink it. Re-register, test, move on.