CO_E_INIT_CLASS_CACHE (0X80004009) Fix: Class Cache Stuck

1. Stuck COM+ Catalog — The Most Common Cause

What's actually happening here is that Windows's COM+ catalog service has a lock on the class cache file (usually %SystemRoot%\Registration\R00000000000*.clb). When this file gets stuck in a half-written state — often after a crash, a bad update, or a failed software install — any new COM class initialization request hits 0x80004009. I've seen this most often after installing Microsoft Office or Visual Studio redistributables, where the installer registers dozens of COM classes and then something interrupts it.

The quickest fix is to reset the COM+ catalog. Don't bother with a reboot first — try this directly.

1. Open an elevated Command Prompt (right-click Start, choose "Terminal (Admin)" or "Command Prompt (Admin)").
2. Run: net stop comsysapp
3. Then: net start comsysapp

If that stops or starts the service successfully, the class cache gets a fresh start. Now try your original operation again. If the error goes away, you're done. The reason this works is that comsysapp (the COM+ System Application service) is the one that opens and manages the cache file. Restarting it forces the service to release any locks and rebuild the cache from scratch.

If the service refuses to start or stop —or you get a "service hung" message—move to the next fix.

2. Corrupted Class Cache Binary Files

Sometimes the cache files themselves are corrupt. The COM+ catalog stores class registration data in binary .clb files under C:\Windows\Registration. These can get corrupted by disk errors, abrupt shutdowns, or third-party software that mucks with COM registrations (looking at you, some antivirus tools).

Here's the fix:

1. Stop the COM+ System Application service if it's running: net stop comsysapp
2. Open File Explorer and go to C:\Windows\Registration. You need admin rights—click Continue when prompted.
3. Delete all files matching R00000000000*.clb. Don't delete the folder itself or other files. There should be one or two of these, each about 1-5 MB.
4. Restart the service: net start comsysapp

When the service restarts, Windows recreates those .clb files automatically. That's the underlying mechanism: the cache is rebuilt from the registry entries in HKEY_CLASSES_ROOT\CLSID and HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID. It takes maybe 10 seconds, and your error should vanish.

One caveat: if you have a lot of COM classes registered (say, after installing a full Visual Studio suite), the rebuild might take a minute. Be patient. If it still fails after 60 seconds, check the System event log for disk errors—you may have a failing hard drive.

3. Permissions on the Registration Folder

Less common, but I've hit this on domain-joined machines where group policy restricts access to C:\Windows\Registration. The COM+ System Application runs as NETWORK SERVICE by default. If that account can't write to the folder, the cache won't initialize.

To check:

1. Right-click C:\Windows\Registration, go to Properties > Security.
2. Click Advanced, then under Permission entries, look for NETWORK SERVICE.
3. It should have Modify or Full Control. If it's missing, click Add, select NETWORK SERVICE, and give it Modify permissions.
4. Apply, restart the comsysapp service.

Also check that the COM+ System Application service itself is running under NETWORK SERVICE. Open services.msc, find it, double-click, go to Log On tab, and confirm it's set to "This account: NT AUTHORITY\NetworkService". If someone changed it to LocalSystem or a custom account, switch it back.

Quick Reference Table

If none of these work, the last resort is a system file check: sfc /scannow from an admin prompt. But honestly, 90% of the time it's fix one or two. The class cache is stupidly simple—when it breaks, it's almost always because something got halfway through writing to it and then stopped.