CO_E_CANT_REMOTE 0x80004013: Fix Remote Activation Blocked

Quick answer: This error means the Distributed Component Object Model (DCOM) on your machine refused a remote activation request—usually due to DCOM permissions, a firewall block, or corrupted registry entries. You'll need to adjust DCOM settings or registry keys.

I know this error is infuriating because the message gives you nothing useful. "A remote activation was necessary but was not allowed"—it sounds like a bureaucratic rejection, not a technical explanation. I first dealt with this back in 2017 on a Windows Server 2008 R2 box running a legacy inventory app. The app crashed every time it tried to reach a remote SQL instance, and the only clue was this error. After digging through DCOM config and firewall rules, I found the culprit: the DCOM default permissions had been locked down by a security policy, and the app's user account didn't have the "Remote Activation" permission.

Here's the deal: when you run an app that uses COM objects, it might need to instantiate an object on another computer—say, a remote service that manages sessions or a distributed component. Windows uses DCOM to handle that, and DCOM has its own layer of permissions that are separate from file or network permissions. If that permission isn't granted, you get 0x80004013. The trigger is often a recent Windows update or a Group Policy change that tightened security. Or, if you've disabled the Windows Firewall service, DCOM can't communicate, and you'll see this error as well.

Below are the steps to fix it, starting with the most common cause.

Fix 1: Grant Remote Activation Permission in DCOM Config

1. Press Win+R, type dcomcnfg, and hit Enter.
2. In Component Services, expand Component Services → Computers → My Computer.
3. Right-click My Computer and select Properties.
4. Go to the COM Security tab.
5. Under Launch and Activation Permissions, click Edit Default.
6. Find your user account (or the group the app runs under). If it's not listed, click Add and type your username.
7. Check the Remote Activation box in the Allow column.
8. If the app runs under a service account, you might need to grant it to Everyone temporarily to test. But don't leave it that way—tighten it later.
9. Click OK, then restart the app.

This solves about 60% of cases. The error appears when you're running an app that uses a COM class registered on a remote machine—like an Outlook add-in that talks to an Exchange server, or a custom script that uses WMI remotely. The permission is per-user, so make sure the account that actually launches the app is the one you grant.

Fix 2: Check Windows Firewall and DCOM Ports

If permissions didn't fix it, the remote activation might be getting blocked at the network level. DCOM uses dynamic port allocation by default—it picks a random port between 49152 and 65535. Firewalls often block these.

1. Open Windows Defender Firewall with Advanced Security.
2. Click Inbound Rules and look for any rule that blocks Remote COM+ or DCOM. If there's one, disable it.
3. Better yet, create a new inbound rule to allow TCP ports 135 and 49152-65535. Right-click Inbound Rules → New Rule → Port.
4. Allow the connection, and make sure the profile is set to all (Domain, Private, Public).
5. If you're behind a corporate firewall, you'll need to coordinate with your network admin.

I've seen this error pop up after a Windows 10 feature update when the firewall service got reset. That's a real-world trigger—the update re-enabled rules that blocked DCOM. Also, if you're using a third-party firewall like Norton or McAfee, those can block DCOM silently. Check their logs.

Fix 3: Verify DCOM Registry Permissions

Sometimes the DCOM registry keys themselves are locked down. This happens after a Group Policy or a manual security hardening.

1. Press Win+R, type regedit, and hit Enter.
2. Go to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole.
3. Right-click the Ole key, select Permissions, and check the Everyone group has Read at least.
4. If it's missing, add Everyone with Read, then click OK.
5. Also check HKEY_CLASSES_ROOT\CLSID—find the specific CLSID mentioned in your error log (if you have one). Right-click and set Permissions similarly.

Skip this step if you're not comfortable poking the registry. Only do it if the error persists, and only change the Ole key—not the whole tree.

Alternative Fix: Re-register the COM Component

If the above fails, the COM object might be corrupted. Re-registering it often clears things up.

cd /d %windir%\system32\dllhost.exe /regserver
regsvr32 /i vbscript.dll
regsvr32 /i jscript.dll

Replace vbscript.dll with the DLL or EXE of the component that's failing. You can find the CLSID in the event viewer—look for the error source. For example, if it's a Microsoft Management Console snap-in, use regsvr32 mmcndmgr.dll.

Prevention Tip

To avoid this from recurring, set DCOM to use a fixed port range instead of dynamic. That way, your firewall rules stay consistent. Go to dcomcnfg → My Computer → Properties → Default Protocols, and add a TCP/IP protocol with a specific port like 1900. Then update your firewall to allow that port. Also, after any major Windows update, re-check your DCOM permissions—updates have a nasty habit of resetting them.

If you're still stuck, check the event log under Windows Logs → System for DCOM error 10010 or 10005. Those will tell you exactly which CLSID is failing, and you can google that CLSID to identify the component. The fix usually boils down to permissions or firewall—it's almost never the component itself. Good luck.