COMADMIN_E_REGDB_ALREADYRUNNING 0x80110475: Fix the COM+ Registry Lock

You try to register a COM+ application, restart MSDTC, or kick off a Component Services operation, and the operation bounces with COMADMIN_E_REGDB_ALREADYRUNNING (0x80110475). The message says the COM+ registry database is already running. You check Task Manager. Nothing looks like it's holding a database. That's because the lock isn't a file lock you can see in Explorer. It's a named mutex plus a shared section object that the COM+ catalog (RegDB) opens for the duration of any write transaction.

What's actually happening here is that a process opened the catalog, acquired the Global\{...} named mutex, and then died without releasing it — or is still running but hung. Windows keeps the mutex alive as long as any handle to it exists. An orphaned handle from a crashed process is enough to trigger 0x80110475 on every subsequent catalog open attempt.

Cause 1: An orphaned COM+ or MSDTC process from a previous crash

This is the number one reason you see 0x80110475. A COM+ application, the Distributed Transaction Coordinator, or a service that hosts COM+ components (IIS app pools, a WCF service, a custom Windows service) crashed hard. The process object is gone but the kernel mutex handle is still referenced because a parent process kept a copy alive, or because a debugger attached and never fully detached.

A very common real-world trigger: someone kills msdtc.exe from Task Manager instead of stopping the Distributed Transaction Coordinator service. Task Manager termination doesn't invoke the service control handler, so the COM+ catalog mutex is never released.

The fix is to find and kill whatever still holds the handle. You can't do that with Task Manager. Use handle.exe from Sysinternals, or the built-in openfiles command if the global flag was enabled at boot.

handle.exe "Global\\" | findstr /i "regdb catalog com+"
openfiles /query /fo table | findstr /i "regdb"

If nothing shows up, the holder is gone and the mutex is orphaned in the kernel. Reboot is the blunt fix, but you can often avoid it. Stop the COM+ System Application service and the Distributed Transaction Coordinator service, then start them again. The SCM will reinitialize the catalog namespace.

net stop "COM+ System Application" /y
net stop MSDTC /y
net start MSDTC
net start "COM+ System Application"

Note the order. MSDTC depends on the COM+ catalog for its resource manager registration. If you start COM+ first and MSDTC second, MSDTC will re-open the catalog and hold the lock through a clean startup. Starting MSDTC first can fail with the same 0x80110475 if COM+ initialization is still running.

Cause 2: A stuck COM+ application or IIS application pool holding the catalog

COM+ applications that host in-proc components hold a reference to the catalog for as long as the application is running. An IIS application pool configured with Enable 32-bit Applications and a COM+ Serviced Component will keep the catalog open even when the site is idle. Same for any process that calls CoCreateInstance on a component registered under Component Services → Computers → My Computer → COM+ Applications.

The symptom here is usually specific: regsvr32 of a COM+ component fails, or regasm /regfile won't write, or Component Services snap-in hangs on the first catalog read. You'll also see it if you try to import an MSI application proxy while an existing instance is still serving calls.

Find the offender by walking loaded DLLs for comsvcs.dll and clbcatq.dll:

tasklist /m comsvcs.dll
tasklist /m clbcatq.dll

Anything in that output that you don't expect is your holder. Recycle the IIS app pool with %windir%\system32\inetsrv\appcmd.exe recycle apppool /apppool.name:"YourPool", or stop the custom service. Don't kill it — let the service manager shut it down cleanly so the COM+ catalog handle gets released through CoUninitialize.

If you must kill it, kill the process tree, not just the leaf. A child process that inherited the COM+ catalog handle will keep the mutex alive even after the parent dies.

Cause 3: A failed MSDTC installation or a leftover catalog lock after a Windows update

Windows cumulative updates that touch transaction support sometimes leave the COM+ catalog in a half-initialized state. After a reboot, MSDTC starts, opens the catalog, hits an error writing to %windir%\Registration, and the catalog is left in a state where the mutex is held but the catalog itself isn't fully open. The next caller — often a .NET app using System.Transactions — gets 0x80110475 instead of the underlying write error.

The tell is Event Viewer. Look in Application logs for Microsoft-Windows-Complus source around the same second as your error. You'll see a secondary HRESULT, typically 0x80070005 (Access Denied) or 0x80070020 (Sharing Violation) on a RegDB file. The real fix is to repair the catalog permissions and reinitialize the transaction database:

msdtc -resetlog
msdtc -uninstall
msdtc -install
net start MSDTC

Before that, check ACLs on %windir%\Registration and %windir%\System32\Com\+* files. The SYSTEM account and the NT SERVICE\MSDTC service SID both need Full Control. A hardened security baseline or a third-party hardening tool sometimes strips these and you get 0x80110475 on the first transaction attempt after boot.

One more scenario worth knowing: if you're on Windows Server 2016 or 2019 and you've enabled the MSDTC cluster role without running msdtc -install on every node first, the cluster resource tries to open a catalog that's already open by the local SCM. The error surfaces as 0x80110475 in the cluster log even though MSDTC service reports Running.

Quick-reference summary

One thing that trips people up: 0x80110475 and 0x8004E00F (CO_E_MSI_ERROR) look similar in some logs. If Component Services imports fail with a catalog error but MSI proxy installs succeed, you're looking at a catalog state issue, not a permissions issue. Check the Complus event log before you touch anything.