Quick answer: Fix the DCOM/COM+ permissions, repair the COM+ catalog, then re-register the DLL with regsvr32. If that fails, clean the registry and restart the COM+ service.
This error pops up when you're trying to register a COM+ component or install software that uses COM+ (like certain VPN clients, backup tools, or old accounting apps). I've seen it most often on Windows Server 2016 and Windows 10 Pro machines after a botched Windows Update or when a user doesn't have local admin rights. The component registrar is basically the middleman that tells Windows "hey, this DLL needs to live in the COM+ catalog." When it can't write to the catalog or the registry, you get 0X80110423.
Here's the thing: most of the time it's not the DLL itself. It's the permissions on the COM+ catalog or a messed-up registry entry left over from a previous uninstall. I've fixed this exact error on a client's server that was running a legacy inventory app. The fix took 15 minutes, and the app worked again.
Step-by-Step Fix (Do These in Order)
-
Run the Component Services as Administrator
Press Win, type
dcomcnfg, right-click and select "Run as administrator." Then expand Component Services > Computers > My Computer > COM+ Applications. If you see any applications listed with a red arrow, right-click them and select "Stop," then "Start" again. This resets the registration state. -
Check DCOM Permissions
Right-click My Computer in Component Services, go to Properties, then the COM Security tab. Click "Edit Default" under Launch and Activation Permissions. Make sure
AdministratorsandSYSTEMhave Local Launch and Local Activation checked. Apply and restart the service. -
Re-register the DLL or OCX That's Failing
If you know the specific component (the error dialog usually shows a file name), open an elevated Command Prompt and run:
regsvr32 /u "C:\path\to\file.dll" regsvr32 "C:\path\to\file.dll"This unregisters then re-registers. If you don't know the file, skip to step 4.
-
Repair the COM+ Catalog
Stop the COM+ system service, rename the catalog, then restart. In an elevated PowerShell run:
Stop-Service -Name comsys Rename-Item -Path "$env:windir\registration\*" -NewName "{0}.bak" -Force -ErrorAction SilentlyContinue Restart-Service -Name comsysThis rebuilds the registration database. Note: this wipes any custom COM+ apps, so back them up first via Component Services > Export.
If That Still Fails: Alternative Fixes
Fix Registry Permissions
Sometimes the COM+ registrar needs to write to HKLM\Software\Classes\CLSID, and the user running the install doesn't have full rights. Grant the Administrators group full control on that key temporarily, run the install, then revert.
Reinstall the Windows Component (for Server)
On Windows Server, add and remove the "Application Server" feature in Server Manager. This re-registers the COM+ subcomponents. I've seen this fix stubborn cases where the catalog was corrupted by a bad update.
Check for Conflicting Software
If you recently installed a security tool or an older VB6 app, it might have replaced a system DLL like ole32.dll. Run sfc /scannow to verify system files. That's caught the problem twice for me.
Prevention Tip
Keep an eye on who's running installs. The error almost always happens because the user isn't a local admin or the installer is trying to write to COM+ without elevation. Always run installs from an elevated prompt. Also, if you're uninstalling an app that uses COM+, reboot before installing the next one. Skipping the reboot leaves stale entries that trip up the registrar.
That's the practical fix. If you hit this error, don't go down the rabbit hole of renaming the whole COM+ directory or blowing away the registry. Start with permissions, work through the list, and you'll get there.