COMADMIN_E_CANTMAKEINPROCSERVICE (0X80110814) fix: Library apps can't be services

If you're seeing COMADMIN_E_CANTMAKEINPROCSERVICE (0X80110814), you're probably scratching your head wondering why COM+ won't let you run a library app as a service. It's a dumb error that trips up a lot of admins, but the fix is simple once you know the rule.

The fix: change the application type

COM+ library applications run inside the caller's process. They can't be standalone Windows services because services need their own process. The fix is to switch the app type from Library to Server Application.

Step-by-step

1. Open Component Services. Press Win + R, type dcomcnfg, and hit Enter. This opens the Component Services snap-in.
2. In the left tree, expand Component Services → Computers → My Computer → COM+ Applications.
3. Find the application that's giving you the error. It'll be listed there. Right-click it and choose Properties.
4. Go to the Activation tab. You'll see a radio button group under Activation type. It's probably set to Library application. Change it to Server application.
5. Click Apply and then OK. After you click Apply, the dialog should close without any errors.
6. Reboot the server. This isn't optional — COM+ caches activation types aggressively, and a reboot flushes that cache. Without a reboot, the service might still fail to start.

After the reboot, the service should start. You can verify by going to the Services console (services.msc) and looking for your COM+ app. It'll show as running under its configured identity (usually Network Service or a custom account).

Why this error happens

Library applications are designed to run inside the process of the client that calls them. Think of them as DLLs that get loaded into other programs. Windows services, by contrast, must run in their own process space — they can't piggyback on another process. COM+ enforces this rule with error 0X80110814. It's not a bug; it's by design. You can't make an in-process component into a service, period.

The error usually pops up when someone creates a COM+ application using the default Library type (which is the default in many older templates) and then tries to configure it as a service in the Advanced tab of the app's properties. The UI lets you check the Run as a Windows NT Service box, but it won't save it — the error fires as soon as you click Apply.

Less common variations of the same issue

Sometimes the problem isn't the application type itself, but something else blocking the change. Here are the gotchas I've seen:

• Component Services is in an inconsistent state. If the COM+ catalog is corrupted, you might get the error even after changing the type. Run regsvr32 comadmin.dll from an admin command prompt to re-register the COM+ admin library. Then retry the steps above.
• The application is already started. You can't change the activation type on a running application. Stop it first: right-click the app in Component Services and choose Shut Down. Then make the change.
• You're trying to run a 32-bit library app on a 64-bit OS. If the app is 32-bit and the service is configured to run as a 64-bit process, COM+ will reject it. Set the app's properties → Advanced tab → check Disable 32-bit on 64-bit (or uncheck it, depending on your needs). Then restart the service.
• Permissions on the COM+ partition. If you're using COM+ partitions (common in hosting environments), the partition's default application type might override your settings. Check the partition's properties in Component Services → COM+ Applications → Partitions.

Prevention

To avoid this error in the future, always set the activation type to Server application when you first create the COM+ application. Here's how:

1. In Component Services, right-click COM+ Applications and choose New → Application.
2. Click Next past the welcome screen. Then choose Create an empty application.
3. Give the app a name. On the Activation type page, pick Server application — not Library. If you're planning to run it as a service, this is non-negotiable.
4. Complete the wizard, then configure the service identity and service settings in the app's Properties → Advanced tab.

Also, document your COM+ apps. I keep a simple text file on each server listing the app name, its type (Library or Server), and the service account. Saves you from hunting later.

One more thing: if you're migrating an existing Library app to a Server app, test it in a non-production environment first. Changing the activation type can break client applications that expect the component to load in-process. That's a separate headache, but at least the error code won't be 0X80110814.