CO_E_IIDSTRING (0x800401F4) — COM interface string is garbage

Quick answer

Reregister the component with regsvr32 and reinstall the software that owns the interface. If that doesn't work, check the CLSID and IID registry entries under HKEY_CLASSES_ROOT\Interface.

What's actually happening here

When you see 0x800401F4 with the friendly name CO_E_IIDSTRING, COM is telling you it can't find the interface you're trying to use. The error name is a bit misleading — it's not that the interface string is invalid in the sense of being malformed; it's that COM can't match the IID (interface GUID) you provided against anything registered in the system. The string looks fine on your end, but COM says "I don't recognize this."

This happens more often than you'd think during development testing, legacy app migrations, or after installing an update that tramples a COM registration. I've seen it most with old Visual Basic 6 components, Office automation interfaces, and custom COM servers that don't use side-by-side assemblies. The root cause is almost always one of three things:

1. The interface's typelib wasn't registered (or got unregistered by an installer).
2. The registry keys under HKEY_CLASSES_ROOT\Interface are missing or point to a nonexistent typelib.
3. A DLL or OCX that hosts the interface is missing or corrupted.

Don't waste time chasing memory corruption or system file damage — it's almost never that. Focus on registration.

Fix steps

Step 1: Identify the component

You need to know which component owns the interface. If you catch this in a debugger or log, look for the CLSID or ProgID. If you're using a script or app that fires the error, check its documentation or source code. Without this, you're guessing.

For example, if you're automating Excel and get this error, the interface is likely _Application (IID {00024500-0000-0000-C000-000000000046}). If it's a third-party OCX, the vendor's support site usually lists the interface GUIDs.

Step 2: Reregister the component

Open Command Prompt as Administrator. Run:

regsvr32 "C:\Path\To\Component.dll"

Replace the path with the actual DLL or OCX. If the component has a typelib registration, this will also re-register the interface. You'll see a success message if the typelib is embedded. If you get 0x8002801C or 0x80029C4A during regsvr32, the DLL itself is corrupted or missing dependencies — fix those first.

The reason this works: regsvr32 calls the DllRegisterServer function, which typically writes the interface and typelib registry entries. If the DLL is intact, this rewrites the missing or corrupted keys.

Step 3: Check the Interface registry key

If regsvr32 succeeded but the error persists, the issue is that the interface is registered but points to a typelib that doesn't exist. Open regedit and go to:

HKEY_CLASSES_ROOT\Interface\{YOUR-IID-HERE}

Look at the ProxyStubClsid and TypeLib subkeys. The TypeLib key should have a default value that matches a valid typelib GUID (one that exists under HKEY_CLASSES_ROOT\TypeLib). If it's missing or points to a typelib that isn't installed, the interface can't be marshaled — and COM raises this error.

To fix, you need to install the correct typelib version. Reinstalling the component usually does this. If you're desperate and know the typelib GUID, you can manually copy the keys from a working machine, but I'd only recommend that as a last resort — it's fragile.

Step 4: Reinstall the owning application

This is the nuclear option, but it's often the cleanest. Uninstall the component or application that owns the interface, reboot, and reinstall. Many installers use Windows Installer, which repairs COM registrations on reinstall even without a full uninstall. You can try msiexec /fa {product-code} if you know the product code from HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall.

Alternative fixes if the main one fails

• Use OleView — Microsoft's OleView tool (comes with Windows SDK) lets you browse registered interfaces and typelibs. If the interface shows as "Not registered" or its typelib entry is broken, you can see the exact registry state without guessing.
• Check the ProxyStub — Some interfaces use a custom proxy stub DLL, not the default PSFactoryBuffer. The ProxyStubClsid subkey tells COM which DLL to load. If that CLSID points to a missing DLL, register that DLL instead.
• Use Dependency Walker — If the DLL fails to register, run depends.exe to see missing dependencies. A missing MSVCRT or ATL DLL will cause this.
• Repair Visual C++ Redistributables — Many COM components depend on VC runtime DLLs for marshaling. If you see proxy-stub failures, repair all Visual C++ redistributable packages from Control Panel > Programs > Change.

Prevention tip

Lock down COM registration during deployment. If you're the developer, use a WiX installer or merge module that explicitly registers interfaces, not just the DLL. If you're a sysadmin, use ProcMon to capture which registry keys the installer failed to write, then script those keys into a .reg file. Also, never copy COM DLLs between machines without running regsvr32 — that's the fastest way to break interface registration.

One more thing: if you're still on Windows 7 or Server 2008 R2, upgrade. The COM infrastructure on those systems is fine, but modern apps expect side-by-side assemblies and manifest-based registration, which reduces these errors significantly. On Windows 10 and 11, use regsvr32 /s in silent mode for scripting — just be sure to check the exit code.

That's it. The error is annoying but mechanical. Find the component, re-register it, verify the typelib path, and it'll stop wasting your time.