Fix RPC_E_UNSECURE_CALL (0X80010118) in COM+ Apps

Cause #1: DCOM Authentication Level Is Too Low

This is the one I see 80% of the time. Your COM+ server component is trying to impersonate the caller (client) but the DCOM call itself isn't authenticated. Windows won't let you impersonate over an anonymous or low-auth channel. The fix is to bump the authentication level on the COM+ application.

Here's how to check and fix:

Open Component Services (run dcomcnfg).
Expand Component Services > Computers > My Computer > COM+ Applications.
Right-click your app and choose Properties.
Go to the Security tab. Under Authentication Level for Calls, pick Packet or higher (Packet Integrity or Packet Privacy).
Click OK, then restart the COM+ application.

If you're stuck with a 3rd-party component that doesn't expose these settings in the GUI, you can force it via the registry. Find the AppID GUID under HKEY_CLASSES_ROOT\AppID\{YourAppID} and set AuthenticationLevel to 4 (Packet). Reboot or restart the COM+ app.

Real-world trigger: This happens often when a legacy VB6 or .NET COM+ component tries to access a network resource (like a file share or SQL Server) using the caller's identity. The DCOM default is Connect-level auth, which doesn't carry enough context for impersonation.

Cause #2: The COM+ Component Forces Impersonation Without a CoImpersonateClient() Call

Sometimes the problem is in the code itself. The component's code might have a CoImpersonateClient() call (or impersonate via a WindowsIdentity object) but the call context doesn't support it. This can happen if the component runs without proper security blanket settings.

Before you blame the dev, check this: In your COM+ component's activation code, make sure the call context is set to allow impersonation. If you're writing in C++, you can call CoSetProxyBlanket() on the incoming interface pointer:

HRESULT hr = CoSetProxyBlanket(
    pInterface,           // the incoming interface
    RPC_C_AUTHN_DEFAULT,
    RPC_C_AUTHZ_DEFAULT,
    NULL,
    RPC_C_AUTHN_LEVEL_PKT_PRIVACY,  // or PKT_INTEGRITY
    RPC_C_IMP_LEVEL_IMPERSONATE,
    NULL,
    EOAC_DEFAULT
);
if (FAILED(hr)) { /* handle error */ }

For .NET COM+ components, you might need to set the SecurityRole attribute or manually call CoImpersonateClient() only after verifying the call context. But honestly? The simpler fix is to change the authentication level at the app level (Cause #1) rather than patching code.

Skipping this: If you're not the dev, don't bother digging into the code. Just apply Cause #1 first. It works 9 times out of 10.

Cause #3: The Component Runs Under the Wrong Identity or Has No Impersonation Privilege

Less common but still a pain. The COM+ app might be configured to run under a specific user account (like Network Service or a custom service account) and that account lacks the Impersonate a Client After Authentication privilege. Without that, the OS blocks the impersonation attempt.

Check two things:

In Component Services, right-click your app > Properties > Identity. Make sure it's not set to Interactive User if the service runs headless. Use This user and a dedicated service account.
Grant the account the impersonate privilege. Open Local Security Policy (secpol.msc) > Local Policies > User Rights Assignment. Find Impersonate a client after authentication. Add your service account there.

You'll need to reboot or at least restart the COM+ application for the change to take effect.

Real-world trigger: This crops up when you migrate a COM+ app from a dev machine to a production server. The dev box uses your admin account (which has all privileges). The production server runs under a constrained account. Suddenly, the call fails with 0x80010118.

Quick-Reference Summary Table

Cause	Symptom	Fix
Low DCOM auth level	Error on any impersonation call	Set authentication level to Packet or higher in COM+ app properties
Code forces impersonation without context	Error only from specific code paths	Call CoSetProxyBlanket() before impersonation, or change app-level auth
Missing impersonation privilege	Error after account change or server move	Grant 'Impersonate a client' privilege to the app's identity account

Start with Cause #1. If that doesn't kill the error, move to Cause #2. Cause #3 is your tiebreaker. I've never seen a case where all three needed fixing — one of them always did the job.

One more thing: If you're still stuck after these, enable COM+ event tracing. Run tracelog with the COM+ provider GUID ({F3A3A3A3-...}). But honestly? I've done that maybe twice in 14 years. These three fixes cover almost everything.