RPC_E_REMOTE_DISABLED 0x8001011C fix for COM calls

You see 0x8001011C (RPC_E_REMOTE_DISABLED) when a process—say, a 32-bit Outlook add-in—tries to call a COM object that lives in a different process or across a network boundary. The COM runtime flat-out says "no." The trigger is almost always a call to CoCreateInstance or CoGetClassObject where the CLSID is registered as a remote server (AppID with RemoteServerName) or the object's threading model doesn't match the caller's apartment.

What's actually happening here is that the COM security layer checks the calling process against a per-machine or per-user policy. If the caller isn't explicitly allowed to make remote calls—either because the CoInitializeSecurity call set RPC_C_AUTHN_LEVEL_NONE or because the DCOM restrictions under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole block it—you get this error. The error code literally means "remote calls disabled for this process." It's not a network problem. It's an ACL problem.

Root Cause

The COM runtime enforces two separate security gates:

1. Process-wide security: set by CoInitializeSecurity. If a process never calls it, COM uses defaults that often allow remote calls. But if it does call it with restrictive flags—like RPC_C_AUTHN_LEVEL_NONE or EOAC_DISABLE_AAA—remote activation fails.
2. Machine-wide DCOM restrictions: under HKLM\Software\Microsoft\Ole\MachineAccessRestriction and DefaultAccessPermission. Even if the process allows remote calls, the machine can veto them.

The most common real-world case: a third-party Outlook add-in that hosts a 64-bit background worker process. The add-in calls CoCreateInstance in the worker, but the worker process called CoInitializeSecurity with RPC_C_AUTHN_LEVEL_NONE (or never called it, which triggers COM defaults that still deny remote calls for unregistered CLSIDs).

Fix Steps

1. Identify the calling and target processes. Use Process Monitor (procmon) or a debugger to see which EXE triggers the error. Look for CoCreateInstance calls with CLSID {...}.
2. Check the CLSID's AppID. Open regedit, go to HKCR\CLSID\{your-clsid}\AppID. Note the AppID GUID. Then check HKCR\AppID\{appid-guid}. If you see RemoteServerName, that's the remote target. If it's missing, the object runs locally—but the error still means remote calls are disabled for the caller.
3. Fix the calling process security. Open HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole\MachineAccessRestriction. Look for a value named Default (REG_BINARY). Export it, then edit the ACL to add the calling process's user account (usually NETWORK SERVICE or INTERACTIVE) with Remote Access permission. Apply with dcomcnfg.exe—or just delete the key if you don't need custom restrictions. Rebooting is overkill; restart the calling process only.
4. If the calling process is yours: In your code, before any CoCreateInstance, call CoInitializeSecurity with at least RPC_C_AUTHN_LEVEL_CALL and RPC_C_IMP_LEVEL_IMPERSONATE. Here's the correct call pattern:

HRESULT hr = CoInitializeSecurity(
    NULL,                          // pSecDesc
    -1,                            // cAuthSvc (use default)
    NULL,                          // asAuthSvc
    NULL,                          // pReserved1
    RPC_C_AUTHN_LEVEL_CALL,        // dwAuthnLevel
    RPC_C_IMP_LEVEL_IMPERSONATE,   // dwImpLevel
    NULL,                          // pAuthList
    EOAC_NONE,                     // dwCapabilities
    NULL                           // pReserved3
);

The reason step 3 works is that MachineAccessRestriction is a global deny list. If it's missing or empty, COM falls back to the default access permissions. Deleting it resets to unrestricted (not recommended for production). Better to add the right user.

If It Still Fails

Check these:

• AppID permissions: Open Component Services (dcomcnfg), find your COM app, right-click → Properties → Security. Under Launch and Activation Permissions, make sure INTERACTIVE and NETWORK have local and remote launch.
• Firewall: If the remote server is on another machine, port 135 (RPC Endpoint Mapper) must be open.
• Windows Firewall rule for COM: Check if Windows Management Instrumentation (WMI-In) is enabled—this often gets confused with DCOM.
• Event Viewer logs: Look under Windows Logs → System for DCOM errors—they'll often contain the exact SID or account that's denied.
• Test with a simple client: Write a small C++ or PowerShell script that calls the same CLSID. If it works but your production app doesn't, the issue is your app's CoInitializeSecurity call—go back to step 4.

One last thing: if you're troubleshooting an Outlook add-in, try disabling the add-in, confirm the error stops, then re-enable it. Sometimes the add-in's own security initialization is conflicting with Outlook's default. Run ProcMon filter for Outlook.exe and 0x8001011C to catch the exact call stack.