CO_E_SERVER_PAUSED (0X80004025): COM server activations paused

What's actually happening here

When you see CO_E_SERVER_PAUSED (0x80004025), Windows has put your COM+ server into a paused state. What's actually happening here is the Component Object Model (COM) runtime detected repeated failures in the server application — usually crashes, hangs, or timeouts — and automatically paused it to prevent further resource waste. Think of it like a circuit breaker tripping to protect the system.

This error pops up most often on Windows Server 2012 R2 through 2022, typically during automated tasks like backup software, database services, or custom COM+ components. I've seen it hit SQL Server's COM+ components, Symantec Backup Exec, and even some internal .NET services hosted in COM+.

Fix 1: Unpause the COM+ application (30 seconds)

This is the immediate fix. If you just need the server running now, do this:

1. Open Component Services — press Win + R, type dcomcnfg, hit Enter.
2. Navigate to Component Services > Computers > My Computer > COM+ Applications.
3. Find your application — it'll likely have a down-arrow icon (paused state).
4. Right-click it, select Start. The arrow should change to a green play icon.

That's it. The server will now accept activations again.

But — and this is where most people get burned — this is a band-aid. The system paused it for a reason. If you don't fix the underlying cause, it'll pause again, often within hours. So keep reading.

Fix 2: Stop the crash-pause cycle (5 minutes)

COM+ has a built-in crash detection. If your application crashes a certain number of times within a window, it pauses itself. The default setting is 5 crashes within 10 minutes. Here's how to adjust or disable it:

1. In Component Services, right-click your paused application, choose Properties.
2. Go to the Pooling & Recycling tab.
3. Look at the Crash Detection section. You'll see Interval (minutes) and Limit (/interval).
4. To stop pausing entirely, uncheck Enable crash detection. Or increase the limit to something like 20 crashes, or extend the interval to 60 minutes.
5. Click OK.

The real fix, though, is figuring out why the thing keeps crashing. A common culprit is the DCOM identity. If your COM+ application runs under a specific user account (especially a service account or local admin), check these:

• Password expiry — if the account password changed, COM+ won't be able to launch. Reset it in the Identity tab of the application properties.
• Logon as a service right — the account needs the Log on as a service user right. Check via secpol.msc > Local Policies > User Rights Assignment. Add the account if missing.
• DCOM permissions — go to My Computer properties > COM Security tab. Under Access Permissions and Launch and Activation Permissions, ensure the relevant user or group has Allow checked for Local and Remote access/launch.

Fix 3: Dig into the event logs and reset the COM+ catalog (15+ minutes)

If the above didn't stick, we need to find the root cause. This is the advanced route.

Step 1: Check the System and Application event logs

Open Event Viewer (eventvwr.msc). Look under Windows Logs > System and Application. Filter by source: COM+, DCOM, Service Control Manager. You'll see events like:

• Event ID 4201 — COM+ application crashed
• Event ID 1000 — Application error (generic crash)
• Event ID 7031 or 7034 — Service terminated unexpectedly (if it's a service)

These will tell you exactly what module faulted. For example, Faulting module path: C:\Windows\System32\mscoree.dll means a .NET component crashed. Faulting module name: ntdll.dll often points to memory corruption.

Step 2: Reset the COM+ application

Sometimes the catalog itself gets corrupted. This happens if you've had repeated crashes and the COM+ database (which lives in %SystemRoot%\Registration\) has stale entries. Here's how to reset without losing everything:

# Shut down the COM+ application via command line
net stop COMSysApp

# Delete the application - note the GUID from Component Services
# Or use the COM+ admin tool
cd C:\Windows\System32\Com
regsvr32 /u comsvcs.dll
regsvr32 /u comadmin.dll

# Re-register COM+ core DLLs
regsvr32 comsvcs.dll
regsvr32 comadmin.dll

# Restart the service
net start COMSysApp

Then recreate the application from scratch in Component Services. Make sure you note down the original identity, activation type (server vs library), and any component DLL paths before deleting.

Step 3: Check for memory or handle leaks

If the crashes are intermittent, run Performance Monitor (perfmon.msc) and add counters for the COM+ process: Process(YourAppName)\Private Bytes, Handle Count, and Thread Count. If you see a steady climb, the component has a leak. That's a code fix — no registry tweak will solve it.

Quick reference: registry key

If you need to automate pausing behavior, the crash detection settings live in the registry under:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\COM3\Applications\{YourAppGUID}\

Look for CrashDetectionInterval and CrashDetectionLimit. These are DWORD values. But honestly, editing via the Component Services UI is safer and less error-prone.

One more thing: activation paused vs server paused

There's a subtle difference. CO_E_SERVER_PAUSED means the COM+ server process itself is paused. But you might also see CO_E_ACTIVATION_PAUSED (0x80004024) — that means the activation call itself is paused, often because the server is shutting down. If you're getting 0x80004025, it's definitely the server process being paused due to crashes. The fix path is the same, but it helps to know which one you're actually hitting.