Fixing COMADMIN_E_CANTCOPYFILE (0X8011040D)

Most Common Cause: The File Is Locked by Another Process

You're trying to install or update a COM+ application and get hit with 0X8011040D. The error message says it can't copy the file. Nine times out of ten, it's because something has that file open. COM+ tries to copy the DLL or EXE to the system directory (usually C:\Windows\system32\COM\ or %windir%\system32\inetsrv\), and if the file's in use, it chokes.

This usually happens when you're reinstalling an app that's currently running, or when IIS has a lock on a COM+ component that's still registered. I've also seen it with antivirus scans holding files open.

The Fix

1. Close any application that might use the COM+ component. That includes IIS, SQL Server, or any service hosting the component.
2. Run tasklist /m <yourdllname.dll> from an admin command prompt. If it returns a PID, you've found the culprit.
3. Kill that process with taskkill /f /pid <PID>. Be careful — don't kill critical system processes.
4. If the lock persists, use handle64.exe from Sysinternals. Run handle64.exe -a -u <filepath> to see what process holds the handle. Don't bother with unlocker tools — they're unreliable and can crash the system.
5. Once the lock's gone, retry the COM+ installation. It'll work 95% of the time.

If you're in a hurry and can't identify the process, reboot. A clean boot gets rid of almost all locks. Then install the COM+ app immediately after the restart before anything else starts.

Second Common Cause: Permissions on the Target Folder

Sometimes the file isn't locked — the COM+ installer just can't write to the destination folder. This happens more often than you'd think, especially on hardened servers or after a security update changes folder permissions.

The default COM+ application directory is %systemroot%\system32\com\. The account running the COM+ installer (usually NETWORK SERVICE or LOCAL SYSTEM) needs write access there. If it doesn't, you get this error.

The Fix

1. Open an admin command prompt.
2. Run icacls %windir%\system32\com to check current permissions. Look for the account that's running the COM+ application — it's often listed in the Component Services console under the application's Identity tab.
3. If that account is missing, add write permissions: icacls %windir%\system32\com /grant "NT AUTHORITY\NETWORK SERVICE":(OI)(CI)W. Replace the account name with whatever your app uses.
4. Don't give Everyone access — that's lazy and a security risk. Use the minimum needed.
5. Retry the installation.

I've also seen this happen when the COM+ app is set to run as a specific domain user and that user doesn't have local logon rights. Check the application's Identity setting in Component Services. If it's a domain account, make sure it has "Log on as a batch job" and "Log on as a service" rights via Local Security Policy.

Third Common Cause: Antivirus Interference

Antivirus real-time protection can block COM+ from copying files, especially if the file is a new or modified DLL. This is more common with aggressive AV like McAfee or certain Symantec versions, but I've seen it with Defender too.

The Fix

1. Temporarily disable real-time file scanning. Don't disable the whole AV — just file system protection.
2. Retry the COM+ installation.
3. If it works, add an exclusion for the COM+ application directory (%windir%\system32\com\) and the specific DLL or EXE you're installing.
4. Re-enable real-time scanning.

Don't leave AV disabled. Set the exclusion right and move on. Also exclude the COM+ system registry keys under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\COM3 if your AV scans registry writes.

Quick-Reference Summary Table