COMADMIN_E_PROGIDINUSEBYCLSID (0X80110815) Fix: COM+ Copy Error

Cause #1: Duplicate ProgID in the Registry

This error always means you're trying to copy a COM+ component whose ProgID (Programmatic Identifier) is already registered under a different CLSID. I've seen this most often on Windows Server 2012 R2 and 2016 after manually installing an updated DLL or when a third-party installer left behind stale entries. The Component Services console doesn't check for duplicates before a copy—it just throws 0X80110815.

Here's the fix:

1. Open regedit as Administrator.
2. Navigate to HKEY_CLASSES_ROOT\CLSID. This key contains every COM class registered on the system.
3. Press Ctrl+F and search for the exact ProgID that appears in the error dialog (for example, MyApp.MyComponent).
4. Keep pressing F3 to find all occurrences. You're looking for a ProgID string value under a CLSID subkey that doesn't match the one Component Services is trying to create.
5. When you find the duplicate, note the associated CLSID (the parent key's GUID). Now go back to Component Services and expand your COM+ application. Look for that GUID under Components—if it's orphaned (not in use by any working component), right-click and delete it.
6. If the duplicate's CLSID belongs to a component you still need, you can't just delete it. Instead, rename the ProgID value in the registry (add a suffix like _old) so it no longer conflicts. Then retry the copy operation in Component Services.

I know this feels like poking around in the dark, but nine times out of ten, this is the culprit. One quick tip: don't delete CLSID keys unless you're 100% sure they're unused—accidentally nuking a system component can break things like Windows Update or the Print Spooler. When in doubt, export the key first.

Cause #2: Orphaned CLSID Pointing to a Missing DLL

Another scenario that trips up admins: the DLL that originally registered the ProgID has been moved or uninstalled, but its registry entry still points to the old path. When Component Services tries to copy that component, it can't validate the ProgID and throws 0X80110815. I've run into this after uninstalling a legacy COM+ application without cleaning up its registry.

To check:

1. In regedit, drill into HKEY_CLASSES_ROOT\CLSID\{Your-GUID}\InprocServer32. Look at the (Default) value—it should point to a real DLL file on disk.
2. If the path doesn't exist, that's your problem. You have two options:
   • Reinstall the DLL from its original source (sometimes just copying the DLL back fixes it, but watch out for version mismatches).
   • Delete the orphaned CLSID key entirely from the registry. This is the cleanest fix if you no longer need the component.
3. After cleaning up, restart the COM+ System Application service or reboot the server. Then try the copy again.

This is especially common after migrating COM+ apps between servers. If you do a lot of these migrations, I recommend using PowerShell to export and re-register components instead of relying on the Component Services GUI—it's more reliable and gives better error messages.

Cause #3: Permissions on the COM+ Application

Less common, but I've seen it on Windows Server 2019 where the Everyone group was stripped from the COM+ application's security. Without proper access, Component Services can't read the ProgID mapping during a copy operation.

Here's how to check:

1. Open Component Services (dcomcnfg).
2. Expand Component Services > Computers > My Computer > COM+ Applications.
3. Right-click your application and choose Properties.
4. Go to the Security tab. Under Authorization, ensure the checkbox Enforce access checks for this application is not ticked unless you have specific security requirements. For a quick test, uncheck it and retry the copy.
5. If you need access checks, go to Roles under the application and make sure the user account you're logged in with is a member of a role that has Read and Write permissions.

A quick word: don't leave access checks disabled in production. But for isolating this error, it's a safe diagnostic step. Also, check that the application's Identity (on the Identity tab) is set to a user account with local admin rights—sometimes the default 'Interactive User' isn't enough.

Quick-Reference Summary Table

That's the lot. If none of these work, you might be dealing with a corrupted COM+ catalog—a rare but real possibility. In that case, export your components, delete and recreate the COM+ application, then re-import. I'd start with the registry check first, it's the fastest and hits the most cases.