Fix COMADMIN_E_BADREGISTRYPROGID (0x80110412)

You're deploying a COM+ application, or maybe just trying to start one that's been sitting quietly for months, and Windows hits you with COMADMIN_E_BADREGISTRYPROGID (0x80110412). The message is terse: The component's programmatic ID is missing or corrupt. I know this one is infuriating because the error tells you what's wrong but not which component. Common triggers: you copied a COM+ application between servers using the export/import wizard and the registry entries didn't travel with it; or an installer ran with the wrong bitness (32-bit DLL registered into the 64-bit registry hive, or vice versa); or someone cleaned up "unused" CLSID keys with a registry cleaner and quietly deleted the ProgID subkey. Any of those gives you 0x80110412 on the next attempt to instantiate the component.

What's actually broken

Every COM+ component has two identities in the registry. The first is the ProgID — that human-readable string like MyCompany.MyApp.Component that lives under HKEY_CLASSES_ROOT\<ProgID> and points to a CLSID. The second is the CLSID itself, a GUID under HKEY_CLASSES_ROOT\CLSID\{...} that points back to the ProgID and to the DLL path.

COM+ depends on that circular mapping. When the catalog tries to activate a component, it walks from the catalog entry to the ProgID, then to the CLSID, then to the InprocServer32 path. Break any link in that chain and you get 0x80110412. The most common break is a missing or mismatched ProgID — often because the DLL was registered into the wrong registry view. On 64-bit Windows, a 32-bit COM DLL registered with the 64-bit regsvr32.exe (or with the wrong REGTLIB call) writes nothing useful to HKEY_CLASSES_ROOT\Wow6432Node, and COM+ looks in the wrong place for it.

Quick sanity check before you touch anything: is the DLL actually 32-bit or 64-bit? Run dumpbin /headers yourdll.dll | findstr machine. If it says x86 but your COM+ app runs as 64-bit, that alone explains the error.

The fix, step by step

Find the exact component that's failing. Open Event Viewer → Windows Logs → Application and filter for source COM+ or DCOM. You want the event that fired within a second or two of your repro. It names the CLSID. If nothing's there, enable COM+ tracing: in Component Services, right-click My Computer → Properties → Default Properties, tick Enable catalog error reporting. Reproduce, then check Event Viewer again.
Look up the ProgID for that CLSID. Open an elevated Command Prompt and run:
```
reg query "HKCR\CLSID\{YOUR-CLSID-HERE}\ProgID" /ve
```
If it returns ERROR: The system was unable to find the specified registry key or value, that's your problem. If it returns a ProgID string, verify that string exists:
```
reg query "HKCR\YOUR.PROGID.HERE\CLSID" /ve
```
Either the ProgID is missing, or both exist but don't reference each other. Both are fixable.
Check the 32-bit view. Most COM+ breakage on 64-bit Windows is a Wow6432Node mismatch. Query both hives explicitly:
```
reg query "HKLM\SOFTWARE\Classes\CLSID\{YOUR-CLSID-HERE}" /s
reg query "HKLM\SOFTWARE\Classes\Wow6432Node\CLSID\{YOUR-CLSID-HERE}" /s
```
You'll often find the CLSID registered in one and not the other. Whichever one has the working ProgID is the "good" copy — note the ProgID string.
Re-register the DLL with the correct bitness. This rebuilds both the CLSID and ProgID entries and usually clears the error instantly. Use the matching regsvr32:
```
REM 64-bit DLL
C:\Windows\System32\regsvr32.exe /s "C:\Path\To\YourComponent.dll"

REM 32-bit DLL on 64-bit Windows
C:\Windows\SysWOW64\regsvr32.exe /s "C:\Path\To\YourComponent.dll"
```
Don't skip the /s suppression — you want the silent register so you can then verify with reg query rather than trusting a dialog box.
Fix the COM+ catalog entry. Re-registering the DLL doesn't update the COM+ catalog. Open Component Services (comexp.msc). Drill to Component Services → Computers → My Computer → COM+ Applications → your app → Components. Find the component that matches your CLSID, right-click → Properties, and check the ProgID field on the General tab. If it's blank or wrong, click Advanced → Add Component won't help — instead delete the component and re-import it. Right-click the Components folder → New → Component → Import components already registered, and pick your (now correctly registered) DLL.
Restart the COM+ application. Right-click the app in Component Services and choose Shut down, then Start. If it's a library application (not a server app), it restarts on next activation.

If it still fails

Two things to check next. First, the COM+ catalog might itself be out of sync with the registry — rare, but it happens after a botched restore. The fix is to not rebuild the catalog (that's a last resort and blows away every application definition). Instead, export the app, delete it, and re-import the .msi. That rebinds ProgIDs from the fresh registry state.

Second, look at the LocalServer32 key if your component is out-of-proc. A missing /Automation switch or a path with unescaped spaces will trigger 0x80110412 even when the ProgID is fine, because the catalog can't validate the server binding. Query it with:

reg query "HKCR\CLSID\{YOUR-CLSID-HERE}\LocalServer32" /ve

And one thing I've seen bite people: a Group Policy object that strips the HKEY_CLASSES_ROOT write permissions from the service account running your COM+ app. The DLL registers fine as admin, then fails for the service account because it can't read the CLSID subkey. Check effective permissions with accesschk -k "HKCR\CLSID\{YOUR-CLSID-HERE}" under the service account context. Fix the ACL, and 0x80110412 goes away for good.