CO_E_SERVER_NOT_PAUSED (0x80004026) Fix in 3 Steps

What triggers CO_E_SERVER_NOT_PAUSED (0x80004026)

You see this error when a COM+ application activation fails because something thinks the server is paused — even though it's running. Real-world scenario: a .NET web app calling a COM+ component on Windows Server 2019. The app crashes with 0x80004026 after an IIS restart. Or a legacy VB6 component talking to SQL Server via COM+. The server isn't paused. The COM+ app is running. But the activation bombs out.

The key: this error says the server is not paused, which is the condition that should allow activations. But something in the COM+ chain thinks pausing is needed, or the activation path is broken. I've seen this on Windows Server 2012 R2, 2016, and 2019. Usually after updates or permission changes.

Cause 1: COM+ application identity account is wrong or locked

This is the most common cause. The COM+ application runs under a specific user account (the identity). If that account's password changed, was locked out, or doesn't have the right permissions, the COM+ runtime can't activate the component. It throws 0x80004026 as a generic failure.

Check and fix the identity

Open Component Services (run dcomcnfg as Administrator).
Expand Component Services → Computers → My Computer → COM+ Applications.
Find the COM+ application that's failing. Right-click it → Properties.
Go to the Identity tab.
You'll see either Network Service (built-in) or a specific user account.
If it's a specific user: verify the password is correct. Type it again if you're sure. Then click Apply. After clicking Apply, you should see no error.
If you get a logon failure, the password is wrong or the account is locked. Reset the password in Active Directory (or local SAM) and update it here.
Also check: is the account in the IIS_IUSRS group? Not always needed, but for IIS-hosted COM+ it helps. Add it if missing.

After fixing: Stop and restart the COM+ application. Right-click it → Shut down. Then start it again from the same menu. Wait 10 seconds. Try your app again.

My opinion: Skip the "test identity" button — it's misleading. It only tests logon, not COM+ activation. Trust the real test: does the app work?

Cause 2: DCOM permissions blocking the caller

The second most common cause: the user or service calling the COM+ component doesn't have Launch and Activation permissions in DCOM config. This happens when you move an app from one server to another, or after security hardening.

Fix DCOM permissions

Back in Component Services, right-click My Computer → Properties.
Go to the COM Security tab.
Under Launch and Activation Permissions, click Edit Limits.
You'll see a list of users/groups.
The calling account (e.g., NETWORK SERVICE, or the IIS app pool identity) needs Remote Launch and Remote Activation checked.
If it's not there, click Add. Type the account name, click OK. Then check both permissions.
Click OK on all dialogs.

Important nuance: If the COM+ app runs on the same machine, Local Launch and Local Activation also need to be allowed. But the error code 0x80004026 specifically appears in cross-machine or cross-process scenarios. So focus on Remote permissions if you're calling from another server, or from IIS.

After you apply these changes, you need to restart the COM+ application (shut down and start) and also do an iisreset if IIS is involved. After the IIS reset, your app pool restarts automatically.

Cause 3: COM+ application is corrupted or in a bad state

This is rarer but real. The COM+ application's catalog got corrupted. You'll see the error randomly, or after a crash. The COM+ app shows as "Running" but actually fails all activations.

Rebuild the COM+ application

Note down the COM+ application's settings (identity, components, roles). Screenshots help.
In Component Services, right-click the COM+ application → Export. Choose Application proxy (not server app). Save the .msi file.
Right-click the application → Delete.
Right-click COM+ Applications → New → Application.
Choose Create a new application.
Enter the same name as before. Select the identity type (server application, not library).
Set the identity account (same as before). Click Next → Finish.
Now add your components: right-click the new app → Components → New → Component.
Import the DLL or type library that contains your COM classes.
Re-apply any role settings if you had them.
Restart the application.

Real-world trigger: This happens after a Windows Update that patches ole32.dll or the RPC subsystem. I've seen it after KB5004442 (Windows DCOM hardening update) on Server 2016. The update doesn't break everything, but it corrupts the COM+ catalog for some apps.

Quick-reference summary table

Cause	What to check	Quick fix	Restart needed?
Identity account locked/wrong password	COM+ app Properties → Identity tab	Update password or unlock account	Stop then start COM+ app
Missing DCOM launch/activation permissions	My Computer Properties → COM Security	Add caller account with Remote Launch + Remote Activation	COM+ app restart + iisreset if IIS involved
Corrupted COM+ application catalog	Error persists after identity and permission fixes	Export, delete, recreate the COM+ app	Yes — full restart of app

"Always check the COM+ application's identity first. 9 times out of 10, that's the culprit. Don't waste time on DCOM permissions until you've ruled out a bad password or locked account." — Me, after fixing this error on 30+ servers.

If none of these work, check the Windows Event Viewer under Applications and Services Logs → Microsoft → Windows → COM+. The operational log sometimes has a more specific error than 0x80004026. Look for Event IDs 4097 or 4099 — they tell you which component or interface failed.