0X800401FC

Fix CO_E_OBJISREG (0x800401FC): Object Already Registered

Windows Errors Intermediate 👁 7 views 📅 May 26, 2026

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?