Fix CO_E_OBJISREG (0x800401FC): Object Already Registered
This error usually pops up when a COM object registration clashes. You'll see it in development tools or installers. Here's the fix.
When You See This Error
You're building a COM component in Visual Studio 2019, or running an InstallShield installer, and it slams you with CO_E_OBJISREG (0x800401FC). The exact translation: "Object is already registered." This happens most often during development when you repeatedly register and unregister a DLL or ActiveX control without cleaning up the registry properly. I've seen it in C++ projects using ATL, and in older VB6 apps too.
Why It Happens
Windows keeps a master list of every COM object in the registry under HKEY_CLASSES_ROOT\CLSID. Each object gets a GUID. When you try to register a second copy with the same GUID—maybe you rebuilt the DLL but didn't unregister the old one, or the installer is running twice—the system says, "Hey, that ID is already taken." It's like trying to park two cars in the same spot.
There's a subtler cause: the registration writes entries for threading model, in-process handler, and the path to the DLL. If the old entry points to a different path, the new path won't overwrite it automatically. The API returns 0x800401FC instead of updating the record. Microsoft designed it this way to prevent accidental corruption, but it's a pain when you're iterating.
Fix Step by Step
Step 1: Unregister the Existing Object
Before registering the new object, unregister the old one. For a DLL, open Command Prompt as Administrator (right-click, Run as administrator) and run:
regsvr32 /u C:\Path\To\Your.dll
Replace the path with your actual DLL location. If you don't know where it is, skip to Step 2.
Step 2: Check for Orphaned Entries
If unregistering doesn't work—maybe the DLL is missing—you'll need to clean the registry manually. Open Regedit (regedit from Run). Navigate to:
HKEY_CLASSES_ROOT\CLSID\{Your-GUID-Here}
Find your GUID from the error code or the project settings. Right-click the key and select Export to back it up, then delete the key. Don't delete anything outside your CLSID unless you're certain.
Step 3: Register the New Object Cleanly
Now register the new DLL or OCX:
regsvr32 C:\Path\To\YourNew.dll
You should see "DllRegisterServer succeeded." If you still get 0x800401FC, something is still pointing to the old registration. Use Process Monitor (procmon) to filter on RegCreateKey and your CLSID—it'll show you exactly where the conflict is.
Still Broken? Check These
- Are you running 32-bit vs 64-bit? If you're on a 64-bit system but the DLL is 32-bit, the 32-bit COM registration lives in
HKEY_CLASSES_ROOT\Wow6432Node\CLSID. Check both. - Is the DLL signed or has a different manifest? Sometimes side-by-side assemblies cause conflicts. Unregister the SxS version via
regsvr32 /n /i:user. - Did you change the GUID? If you're developing, just generate a new GUID in Visual Studio (Tools > Create GUID) and rebuild. It's the nuclear option, but it works every time.
I've had this error pop up in automated build pipelines too. If you're scripting it, always call regsvr32 /u before regsvr32 on the same step. That prevents the race condition where two builds try to register the same object simultaneously.
Was this solution helpful?