Fix COMADMIN_E_APP_NOT_RUNNING (0X8011080A) in 3 Steps

What's Actually Happening Here

COMADMIN_E_APP_NOT_RUNNING (0X8011080A) shows up when a client tries to call a COM+ application that's stopped or never started. The COM+ runtime expects the app to be up and listening, but it isn't. This typically bites you in two scenarios: a scheduled task or service that calls an old VB6/ASP component, or a line-of-business app that relies on a COM+ package installed on a server (Windows Server 2016/2019/2022 or even Windows 10/11 Pro).

The error string is misleading — "not currently running" doesn't always mean the app crashed. Often it's a configuration mismatch, like the app's identity account losing a password, or the application pool being disabled after a reboot. Let's walk through fixes from least invasive to most, and you can stop the moment one works.

Fix 1: Restart the COM+ Application (30 seconds)

Half the time, the app is stopped for a mundane reason—maybe a crash, maybe a reboot, maybe someone manually stopped it and forgot. The simplest move is to start it again through Component Services.

1. Press Win + R, type dcomcnfg, hit Enter.
2. Expand Component Services → Computers → My Computer → COM+ Applications.
3. Find the application throwing the error (it's usually named after your app or its DLL).
4. Right-click it and select Start.

If the option is greyed out or shows "Stopped" and doesn't respond, skip to Fix 2—it won't start for a reason.

Why does this work? The COM+ runtime checks the application's process (dllhost.exe) exists and is healthy. Starting it from the console forces a fresh instance, and any transient state that was blocking it clears. If the app starts and your client works, you're done. But if it stops again after a few minutes, you've got a deeper problem.

Fix 2: Check the Application Identity and Dependencies (5 minutes)

When the app won't start, or starts then dies, look at what account it runs under. COM+ apps run as a specific identity—either "Interactive User" or a dedicated service account. If that password changed or the account got locked out, the app silently fails to start.

1. In the same COM+ Applications list, right-click your app and select Properties.
2. Go to the Identity tab.
3. Note the account. If it's "Interactive User," switch to a specific user account (or vice versa) and enter valid credentials.
4. Click OK, then restart the app as in Fix 1.

Also check Activation tab—if it's set to "Server application," the app runs in its own dllhost.exe. If it's "Library application," it runs inside the client process, and the error might come from a client-side DLL issue. Try switching to Server if it's Library, and vice versa, just to see if the error changes.

Another culprit: the COM+ app depends on a service that isn't running. Open Services (services.msc) and look for things like Distributed Transaction Coordinator (MSDTC) or Remote Procedure Call (RPC). If MSDTC is stopped, many COM+ apps fail with this exact error. Set MSDTC to Automatic and start it.

If the app still won't start, check the Windows Event Log under Windows Logs → Application for errors from source COM+ or DCOM. The event details often tell you why the app failed—missing DLL, access denied, or a corrupted component. That gives you a direct lead.

Fix 3: Re-register and Recreate the COM+ Application (15+ minutes)

If you've made it here, the app is either badly configured, its registration in the COM+ catalog is corrupt, or the underlying DLL/COM component is missing or broken. The nuclear option is to remove and re-add the application.

You'll need the original .DLL or .tlb file that the app uses. Find it in the app's install folder or from the client machine that works (if any). Then:

1. Close Component Services.
2. Open an elevated Command Prompt and unregister the component: regsvr32 /u path\to\component.dll
3. Re-register it: regsvr32 path\to\component.dll
4. Reopen Component Services, right-click COM+ Applications → New → Application.
5. Choose Create an empty application, give it the same name as before.
6. Go through the wizard, set activation type to Server, and assign the same identity as before.
7. After the app appears, right-click it → Properties → Components tab → Install and point to the component DLL.
8. Restart the app and test.

This wipes the old catalog entry and rebuilds it from scratch. The reason this works: the COM+ catalog stores component IDs and thread pool settings; a corrupted entry can make the runtime think the app is running when it isn't, or fail to start it silently. Recreating forces a clean state.

If you can't find the DLL, you can also export the existing application to an .MSI file from a working server (if you have one), then import it on the broken machine. Right-click the app → Export → choose "Application proxy" or "Full application." Import via right-click → New → Application → Install pre-built application, then browse to the .MSI.

When to Call It Quits

If after re-registering the app still won't start, and the Event Log points to a missing dependency like a specific system DLL, you might be looking at a corrupted Windows component store. Run sfc /scannow and DISM /Online /Cleanup-Image /RestoreHealth from an elevated prompt. That's a last resort, but it does fix catalog corruption that manifests as weird COM+ errors.

Pro tip: Always test from a different client machine after each fix. If one client works and another doesn't, the problem isn't the COM+ app—it's the client's DCOM configuration, specifically the Remote Server Name and authentication settings under dcomcnfg → Component Services → Computers → My Computer → DCOM Config.

Most times, Fix 1 solves it. Fix 2 catches the identity problem. Fix 3 is for the stubborn cases where the catalog is toast. Start with the quick restart, and only go deeper if you must.