CO_E_DBERROR 0x8004E02B Fix for COM+ and MSDTC

Quick answer

Unregister and re-register the COM+ catalog (RegDB) or reinitialize MSDTC with a fresh log file — msdtc -resetlog handles the latter in about five seconds.

Why you're seeing this error

CO_E_DBERROR (0x8004E02B) is COM and COM+ telling you, in the worst possible way, that it tried to open or write to its own internal database and the database engine said no. That internal database isn't SQL Server. It's the COM+ catalog, stored in %SystemRoot%\Registration (the RegDB files), or the MSDTC log in %SystemRoot%\System32\MsDtc\MsDtc.log.

Typical triggers I've run into:

A Windows Update or in-place upgrade left the RegDB files with wrong ACLs.
Antivirus quarantined a RegDB file mid-write.
Someone copied a COM+ application from another server using the COM+ Export wizard and the .msi landed on a machine where the catalog was already half-broken.
Disk full during a COM+ app install. The catalog write failed halfway and left the RegDB in a state COM+ can't parse.
MSDTC service can't open its log because the account that runs it lost access to MsDtc\.

Last month a client running a 2016 R2 terminal server called me because their ERP middleware (a 32-bit COM+ app) stopped launching after a Tuesday patch. Event Viewer was full of DistributedCOM and COM+ 4097/4609 events, and dcomcnfg threw 0x8004E02B the second they expanded Component Services. The RegDB's ACLs had been reset by the update. We fixed it in about twenty minutes.

Fix steps

Confirm which DB is failing. Open Event Viewer → Windows Logs → Application and look for source COM+, DCOM, or MSDTC. If you see MSDTC events, it's the transaction log. If you see COM+ 4609 or 4691, it's the RegDB. If dcomcnfg won't even open, assume RegDB.
Stop everything that touches COM+. In an elevated command prompt:
```
net stop msdtc
net stop COMSysApp
net stop EventSystem
net stop SENS
```
Don't skip this. I've watched people try to rebuild RegDB while COM+ was running and it made things worse — half the catalog ends up re-registered, half doesn't.
Check free space on C:. Sounds dumb. It's not. You need at least a few hundred MB free for the RegDB rebuild to write its temp files. dir c:\ takes two seconds.
If it's MSDTC, reset the log. From an elevated prompt:
```
msdtc -resetlog
```
Then net start msdtc. That's it. The service recreates MsDtc.log from scratch. Any in-flight transactions are gone — that's the point — but the service comes back clean.
If it's the RegDB, rebuild the COM+ catalog. There's no supported 'rebuild' switch, but you can unregister and reinstall the catalog. From an elevated prompt:
```
cd /d %windir%\system32
regsvr32 /s /u comsvcs.dll
regsvr32 /s comsvcs.dll
cd /d %windir%\system32\Com
regsvr32 /s /u clbcatq.dll
regsvr32 /s clbcatq.dll
```
Reboot. When Windows comes back, the COM+ catalog is recreated with default contents. Your custom COM+ applications (the ones you or your vendor installed) will need to be re-imported from their .msi packages. Yes, this is annoying. No, there isn't a shortcut.
Fix the permissions if the rebuild fails. The RegDB folder needs SYSTEM, Administrators, and the COM+ service account to have full control. Right-click C:\Windows\Registration → Properties → Security → Advanced. If the ACLs look weird (missing SYSTEM, or Everyone full control), reset them:
```
icacls "%windir%\Registration" /reset /T /C
icacls "%windir%\Registration" /grant "NT AUTHORITY\SYSTEM:(OI)(CI)F" /T
icacls "%windir%\Registration" /grant "BUILTIN\Administrators:(OI)(CI)F" /T
icacls "%windir%\Registration" /grant "NT AUTHORITY\NETWORK SERVICE:(OI)(CI)R" /T
```

Restart services in the reverse order you stopped them.

net start SENS
net start EventSystem
net start COMSysApp
net start msdtc

Test with a known COM+ app. Open dcomcnfg, expand Component Services → Computers → My Computer → COM+ Applications. If the tree loads without error, you're done.

If the main fix doesn't work

Run sfc /scannow. If a system DLL that COM+ depends on is corrupt, the catalog rebuild won't help. sfc /scannow from an elevated prompt takes 10-15 minutes.
Run DISM /Online /Cleanup-Image /RestoreHealth. Do this before sfc if you've had cumulative updates fail recently. DISM repairs the component store so sfc has something to work with.
Check DTC network settings. If your app uses transactions across machines, the wrong DTC security settings will surface as 0x8004E02B on the client. Open dcomcnfg → Component Services → Computers → My Computer → Distributed Transaction Coordinator → Local DTC → Properties → Security. Everything except 'Network DTC Access' should generally be off on a single-server setup.
Reinstall the MSDTC service. Last resort for a stubborn MSDTC log:

msdtc -uninstall
msdtc -install
net start msdtc

Then re-open dcomcnfg and reconfigure your DTC security tab from scratch. I've only needed this twice in fifteen years, but I've needed it.

Prevention tip

Don't let antivirus real-time scan C:\Windows\Registration or C:\Windows\System32\MsDtc. Add both paths to the exclusion list on any server running COM+ apps or distributed transactions. I've seen Symantec and a couple of the cheaper EDR agents lock RegDB files mid-write and cause exactly this error. Also: before installing a Windows cumulative update on a machine that hosts critical COM+ apps, export the COM+ applications first (dcomcnfg → right-click app → Export). That way, if the update breaks the catalog, you re-import in five minutes instead of rebuilding from documentation that's probably out of date anyway.