COMADMIN_E_APPDIRNOTFOUND Fix: Application Directory Missing

When This Error Shows Up

You're setting up a new COM+ application on a Windows Server 2016 box, or you've just moved an old app from a decommissioned server. You right-click the COM+ application in Component Services, hit Properties, and try to change the Application Directory or launch it—and boom, you get COMADMIN_E_APPDIRNOTFOUND (0X8011041F). This also happens after you've restored a COM+ application from an export file, but the original install folder is gone or renamed.

Root Cause in Plain English

Every COM+ application has a property called ApplicationDirectory. That's the folder where the DLLs and config files live. When you import an MSI or export a COM+ app, Windows stores the absolute path to that folder. If that path doesn't exist—because the folder was moved, deleted, or the drive letter changed—the system throws 0X8011041F. It's not a permissions issue or a corrupted registry (though you might think it is). It's simply that the path is stale.

The Fix: Three Ways to Get It Working

You don't need to reinstall the whole app. Skip the registry hacking—there's a cleaner way. Try these in order.

Option 1: Point the App to the Right Folder (Easiest)

1. Open Component Services (run dcomcnfg from the Start menu).
2. Expand Component Services > Computers > My Computer > COM+ Applications.
3. Right-click the problem application and select Properties.
4. Go to the Advanced tab (or the General tab if it's there—it varies by app).
5. Look for Application Directory. It’s a text field, often empty or showing a path like C:\Program Files\MyApp.
6. Enter the correct path—the one where the DLLs actually live now. If you're not sure, browse to the folder that contains the .dll files for that app.
7. Click OK. The error should be gone.

That worked for me 90% of the time. It's the direct fix.

Option 2: Recreate the App from Scratch

If the app was installed from an MSI, you can just delete it and reinstall. This is the nuclear option, but it's quick if you have the installer.

1. In Component Services, right-click the app and choose Delete.
2. Run the original MSI or setup.exe. It’ll create a fresh COM+ application with the correct directory.

This also clears any other odd config that might be lingering.

Option 3: Use the Command Line (When the GUI Fails)

Sometimes the Properties window won't even open because the directory is missing. Then use mscom+adm.exe or PowerShell. Here's a PowerShell one-liner that sets the directory directly:

Get-COMApplication -Name "YourAppName" | Set-COMApplication -ApplicationDirectory "D:\MyApps\YourApp"

Replace YourAppName and the path with your values. If Get-COMApplication isn't available (it's on newer servers), you can use the COMAdmin COM object in a script:

$comAdmin = New-Object -ComObject COMAdmin.COMAdminCatalog
$apps = $comAdmin.GetCollection("Applications")
$apps.Populate()
foreach ($app in $apps) {
    if ($app.Name -eq "YourAppName") {
        $app.Value("ApplicationDirectory") = "D:\MyApps\YourApp"
        $apps.SaveChanges()
        break
    }
}

What to Check If It Still Fails

So you set the path, it's correct, but the error persists. Don't assume it's you. Check these three culprits.

• Is the folder accessible to the service account? The COM+ app runs under a specific identity (usually Network Service or a custom account). That account needs read and execute permissions on the directory. Right-click the folder, go to Security, and verify the account has Read & Execute. I've seen this trip up people who used a local admin account but the app runs as Network Service.
• Is the path's drive mapped? If the app directory points to a mapped drive like Z:\Apps, but that drive only exists when a user logs in, the service won't see it. Use a UNC path like \\Server\Share\Apps instead.
• Did you export and import the app? When you export a COM+ application to an MSI, it bundles the files, but the directory property might be set to the original install location on the old server. After import, you'll need to manually update the Application Directory—even if the files are in the right place. The import doesn't auto-detect.

That last one is the sneakiest. You think you've done everything right, but the exported MSI carries the old machine's path like a bad souvenir.

Final Word

This error is annoying because it's misleading—it says "directory not found" but it's really a path mismatch. Don't waste hours blaming the registry. The fix is almost always in the app's properties. Now go fix it and get back to real work.