Fix COMADMIN_E_OBJECTERRORS (0x80110401) on Windows Server

You clicked Start on a COM+ application, or you ran regsvr32 on a component, and Windows threw 0x80110401 back at you. Maybe it happened after a Windows Update. Maybe it happened after you changed a service account password last Friday and forgot about the COM+ apps running under it. Either way, the message is vague: "Errors occurred accessing one or more objects." The detail you actually need is in the ErrorInfo collection, and I'll show you how to read it.

Here's the thing about this error. It doesn't mean your components are broken. It means COM+ can't reach the catalog entry for one or more of them. The catalog is a database — literally an MSDE/SQL-backed store under %SystemRoot%\Registration — and if a single object inside it has bad permissions, a missing dependency, or a stale pointer, the whole operation fails with this code. Stop reinstalling things. Read the ErrorInfo, then work the flow below in order.

Before you do anything: pull the real error detail

If you're in dcomcnfg (Component Services), the dialog is useless without the detail. Right-click the app that failed and pick Properties, then look for the error tab. If you're scripting with cscript or PowerShell, capture the ErrorInfo like this:

$app = New-Object -ComObject COMAdmin.COMAdminCatalog
$apps = $app.GetCollection("Applications")
$apps.Populate()
foreach ($a in $apps) {
    if ($a.Name -eq "YourAppName") { $apps.StartApplication($a.Key) }
}

When it throws, expand the exception. The ErrorInfo collection usually names the exact CLSID or ProgID that's failing. Write that down. You'll need it in Step 2.

Step 1 — The 30-second fix: permissions on the Registration folder

Yes, it's usually this. COM+ reads the catalog from disk, and if the account running the COM+ app (or the identity the catalog reads under) can't touch the folder, you get 0x80110401 before anything else gets a chance to run.

1. Open File Explorer and go to C:\Windows\Registration.
2. Right-click the folder, then Properties, then the Security tab.
3. Click Advanced, then check the Owner at the top. It should be NT SERVICE\TrustedInstaller or SYSTEM. If it says something else, that's a sign someone played with ownership.
4. Click the Permissions tab. You should see SYSTEM with Full Control, and Administrators with Full Control. If your service account (the one in the COM+ app's Identity tab) isn't there, add it with Read & Execute, List folder contents, and Read.
5. Click Apply. If you get a prompt asking to replace permissions on child objects, click Yes.

After Apply finishes, you should see the permission entry appear in the list without an error. Now restart the COM+ application. If it starts, you're done. Stop reading.

Real scenario I've hit twice: an admin moved the COM+ app's identity from NetworkService to a domain service account. The catalog still had the old ACL cached. Resetting permissions on Registration fixed it in under a minute. No reboot needed.

Step 2 — The 5-minute fix: DCOM identity and the CLSID from ErrorInfo

If Step 1 didn't fix it, take that CLSID from the ErrorInfo collection and open regedit. Navigate to:

HKEY_CLASSES_ROOT\CLSID\{THE-CLSID-FROM-ERRORINFO}

You should see at least three subkeys: InprocServer32, LocalServer32, and ProgID. If InprocServer32 is missing or its (Default) value points to a DLL that doesn't exist, that's your culprit. Re-register the DLL with the right bitness — this trips up a lot of people on 64-bit Windows:

%SystemRoot%\SysWOW64\regsvr32.exe /i "C:\Path\To\Your.dll"
%SystemRoot%\System32\regsvr32.exe /i "C:\Path\To\Your.dll"

Run both. Yes, both. The 32-bit regsvr32 writes to the WOW6432Node hive; the 64-bit one writes to the native hive. If you registered a 32-bit DLL with the 64-bit regsvr32, COM+ will silently fail to find it and give you 0x80110401.

After registration succeeds, you should see a confirmation dialog from regsvr32 saying DllRegisterServer succeeded. Then go back to Component Services, right-click your COM+ app, and click Start. If it starts, you're done.

If it still fails, check the Identity tab on the COM+ application. For server applications, the Identity needs "Log on as" rights on the machine — a domain account usually needs SeBatchLogonRight. For library applications this doesn't apply, so don't waste time on it.

Step 3 — The 15-minute fix: rebuild the COM+ catalog

I'm not a fan of this one because it nukes every COM+ registration on the machine. But if the catalog itself is corrupt — and after a bad shutdown or a failed Windows Update that's exactly what happens — you don't have a cleaner option. Rebuilding from scratch is faster than trying to hunt down one damaged CLSID.

Before you start: export your COM+ apps. Right-click each application in Component Services, pick Export, and save the MSI to a network share. You'll reimport them after the rebuild. Also note the identity and any role assignments — those don't survive the export cleanly in every case.

Now stop the COM+ services. Open an elevated command prompt and run:

net stop msdtc
net stop COMSysApp
net stop EventSystem

You should see each service report it stopped successfully. If msdtc refuses to stop, wait — it can take up to 30 seconds. Then rename the catalog folder:

ren %SystemRoot%\Registration Registration.old

Reboot the machine. On startup, Windows recreates %SystemRoot%\Registration from scratch with the default Microsoft components. After you log in, open Component Services. You should see the standard COM+ applications (System Application, COM+ Utilities, and so on) but none of your custom ones. That's expected.

Reimport your MSIs one at a time. Right-click COM+ Applications, then New, then Application from MSI. Point at your exported file. Set the identity again. Start each app after importing to confirm it works before moving to the next one.

If the rebuild itself fails with 0x80110401, the problem isn't the catalog — it's the disk. Run chkdsk C: /f and check the SMART status on the drive. Catalog corruption that survives a rebuild almost always means failing hardware or a bad NTFS entry.

What doesn't help (so skip it)

• Reinstalling the COM+ feature in Server Manager. The catalog is user data, not a feature. This does nothing.
• Clearing the event log. Tempting when you're staring at 200 DCOM 10016 entries, but it hides the CLSID you need.
• Running sfc /scannow. It'll find nothing. This error isn't a system file problem.
• Disabling UAC. Doesn't touch COM+ identity resolution. Pure waste of time.

Quick reference

One last thing. If you're on Windows Server 2019 or 2022 and this started right after a cumulative update, check the CBS log at C:\Windows\Logs\CBS\CBS.log for the timestamp around when the error began. I've seen two updates in the last year corrupt COM+ registrations on machines that had third-party antivirus hooking the Registration folder. If that's your situation, exclude %SystemRoot%\Registration from real-time scanning, then do Step 3. Otherwise you'll rebuild the catalog and watch the AV corrupt it again within a week.