The 30-Second Fix: Check the App Type in Component Services
This error pops up when you or some installer marks a COM+ application as a 'Server Application' but it's actually a Library Application or an Application Proxy. The COM+ runtime won't start library apps or proxies as standalone processes — they need a host process. I see this all the time after botched deployments or when someone copies an app from a dev box.
Open Component Services (run dcomcnfg from an admin command prompt). Go to Component Services > Computers > My Computer > COM+ Applications. Find the app throwing the error. Right-click it, pick Properties. Look at the Activation tab.
If Application type says 'Library Application' or 'Application Proxy' but someone tried to start it via COMAdminCatalog.StartApplication() or the MMC 'Start' button — that's your problem. You can't start those manually. They only activate when a client calls them.
If you actually need it to run as a standalone process, change the type to Server Application. Hit OK. Right-click the app and choose Start — it should fire up now. If it doesn't, read on.
The 5-Minute Fix: Re-Register the App and Check Dependencies
Still failing? The app might have a corrupted registration or missing dependencies. Here's what I do next.
First, export the app to a file so you don't lose the config. In Component Services, right-click the app, pick Export. Choose 'Application Proxy – Install on other machines' or 'Server Application – Export as a server application' depending on your needs. Save the .MSI somewhere safe.
Now delete the app. Right-click it, choose Delete. Then right-click COM+ Applications and pick New > Application. Select Install pre-built application and point to the exported MSI. This re-creates the registration cleanly.
While you're at it, check the Components folder inside the app. Any components with a red arrow icon? That means the DLL is missing. Expand each component — the path to the DLL shows in the right pane. Verify the file exists and is readable. Missing DLLs are a common cause after updates or when someone moves files around.
Also check the Identity tab in app properties. If it's set to a specific user account, make sure that account has 'Log on as a batch job' rights. Without it, the app won't launch. You can set this via Local Security Policy > Security Settings > Local Policies > User Rights Assignment.
The Advanced Fix (15+ Minutes): Dig into the Event Log and COM+ System App
If the first two steps didn't work, something deeper is wrong. Let's pull the logs and check the COM+ infrastructure.
Open Event Viewer. Go to Windows Logs > System. Filter by source 'COM+' or 'DCOM'. Look for events with ID 4099, 4100, or 4109. These often contain the exact error message and a hint about which DLL failed to load or which CLSID caused the issue.
You can get the CLSID from the error. Open Registry Editor. Navigate to HKEY_CLASSES_ROOT\CLSID\{the-guid}. Check if the InprocServer32 key points to the right DLL path. Common issue: path has a typo or references a 32-bit DLL in a 64-bit COM+ app. For 32-bit components on a 64-bit system, the path should be under SysWOW64, not System32.
Next, reset the COM+ system application. Run this from an admin command prompt:
net stop comsysapp
net start comsysappIf that service won't start, you've got bigger problems — corrupted COM+ catalog. You can rebuild it with:
regsvr32 /s %SystemRoot%\system32\comsvcs.dll
regsvr32 /s %SystemRoot%\system32\colbact.dll
dcomcnfg -forceresetReboot after the reset. Then re-import your exported app MSI.
Still broken? Check if any antivirus is blocking DLL host processes. dllhost.exe is a common target for aggressive security software. Add an exclusion for %SystemRoot%\system32\dllhost.exe and %SystemRoot%\SysWOW64\dllhost.exe.
One last thing: Application Proxies cannot start as server apps by design. They're just routing stubs. Don't try. If you're seeing this error on a client machine that's running an app proxy, that's normal — proxies only activate when a remote call comes in. Ignore the error if the app works otherwise.
I've seen this exact error on Windows Server 2012 R2 through 2022. The fix is almost always the app type mismatch. Start there, and you'll save yourself an hour of hunting.