Fix 0x8011044F: COM+ library app proxy error

The 30-second fix — check the activation type

This error shows up when you try to register a COM+ application as a library app and an application proxy is already on the same machine. Or vice versa. The system won't let you do it. The culprit is almost always a bad config during deployment.

Open Component Services:

1. Run dcomcnfg from the Start menu or command line.
2. Expand Component Services > Computers > My Computer > COM+ Applications.
3. Find the app with the error — it'll show a yellow triangle or just refuse to start.
4. Right-click it, choose Properties, go to the Activation tab.
5. See what's selected under Activation type.

If it says Library application, and you also see a separate proxy component (usually named something like "MyApp Proxy"), that's your problem. You can't have both.

The quick fix: Change the activation type to Server application. Click Apply, then OK. Restart the COM+ app (right-click > Shut down, then right-click > Start). This takes 30 seconds and fixes 80% of cases.

Heads up: Server apps run as their own process (dllhost.exe). Library apps run inside the caller's process. Your security requirements might force one or the other. If you must keep it as a library app, skip to the next section.

The 5-minute fix — remove the proxy

If changing to Server app isn't an option (maybe company policy says library only), you need to delete the proxy component. Library apps don't need a proxy because they load directly into the client process. The proxy is for remote access, which library apps don't support.

1. In Component Services, expand COM+ Applications.
2. Look for an entry named XXXX Proxy — where XXXX is the name of your app. It's usually right next to the library app.
3. Right-click the proxy entry and choose Delete.
4. Confirm the delete.
5. Now restart your library app: right-click it, choose Shut down, then Start.

If the proxy won't delete (gives you access denied), you might need to run Component Services with admin rights. Right-click the Component Services icon in the MMC console, choose Run as administrator. Then try again.

Why this works: The error code 0x8011044F (COMADMIN_E_LIB_APP_PROXY_INCOMPATIBLE) literally means the library app and its proxy are fighting. Removing the proxy lets the library app run clean. I've seen this on Windows Server 2016, 2019, and Windows 10 builds. No difference.

The 15-minute fix — clean up with script or regedit

Sometimes the proxy is hidden, or there's a registry leftover from a failed install. Deleting through the GUI doesn't work. Here's the brute-force method.

Option A: Use a COM+ admin script (PowerShell)

Install the COMAdmin module if you don't have it:

Install-Module -Name COMAdmin -Force

Then run this script (replace YourAppName with your actual app name):

$comCatalog = New-Object -ComObject COMAdmin.COMAdminCatalog
$applications = $comCatalog.GetCollection("Applications")
$applications.Populate()

foreach ($app in $applications) {
    if ($app.Name -like "*YourAppName*Proxy*") {
        Write-Host "Removing proxy: $($app.Name)"
        $applications.Remove($app.Key)
        $applications.SaveChanges()
    }
}

This script deletes all COM+ applications whose name contains "Proxy" and matches your app name. Test it first on a non-production box.

Option B: Registry cleanup (last resort)

If the script doesn't catch it, the proxy might be registered directly in the registry. Be careful — messing with COM+ registry keys can break stuff.

1. Close Component Services.
2. Open Regedit as administrator.
3. Go to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\COM3\Applications.
4. Look for a subkey with your proxy name. It's usually a GUID (like {12345678-1234-1234-1234-123456789ABC}).
5. To find which GUID belongs to your proxy, look at the ApplicationName value inside each GUID key.
6. When you find the proxy GUID, export it first (right-click > Export) to a .reg file as backup.
7. Then delete the entire GUID key.
8. Go to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\COM3\Applications\CLSID and remove any orphaned CLSID entries that reference the deleted GUID. This is tedious — only do it if you're sure.

After registry cleanup, restart the COM+ system service: net stop comsysapp && net start comsysapp. Then start your library app again.

What about the real-world trigger?

I see this most often when someone deploys a COM+ component using an MSI installer that registers both the library app and its proxy. Happens a lot with older dev tools (Visual Basic 6, classic ASP) that assume every COM+ app needs a proxy. Or when you upgrade from Windows Server 2012 to 2016 and the migration tool duplicates entries.

One more thing: If you're using load balancing or clustering, you might need the proxy for remote clients. In that case, you can't use library activation at all — switch to Server activation, keep the proxy, and configure your DCOM permissions for remote access. That's a whole other article, though.

Most people stop after the 30-second fix. Try that first.