RPC_E_CONNECTION_TERMINATED (0X80010006) — What Actually Breaks the RPC Channel

1. Stale COM Proxy (Most Common)

This is what you're hitting 8 times out of 10. The error 0x80010006 translates to RPC_E_CONNECTION_TERMINATED. What's actually happening here is that your application holds a COM interface pointer that points to an object in another process (or on another machine). The communication channel between them — the RPC connection — got torn down while the pointer was still alive. The next time your code calls a method on that pointer, COM says “nope, that channel is dead.”

The real trigger is almost always the server process or service that owns the COM object. It either crashed, was restarted, or timed out. Client apps that cache COM interface pointers without reconnecting after a failure will hit this.

The Fix

1. Identify which COM object is involved. Look at the call stack in the error log — you'll see a CoCreateInstance or a QueryInterface call up the chain.
2. Restart the application that's crashing. That clears all cached COM pointers.
3. If the server process is a Windows service (like BITS or WMI), restart that service:

net stop "Background Intelligent Transfer Service" && net start "Background Intelligent Transfer Service"

I've seen this happen frequently with Office add-ins that talk to Outlook's COM object. Outlook recycles its process sometimes, and the add-in's cached interface dies. The fix there is to restart Office, not the whole system.

2. RPC Service Itself Dies or Is Blocked

Less common but more annoying. The RPC Endpoint Mapper and Remote Procedure Call (RPC) services are the backbone of all COM communication. If either stops — even briefly — every active RPC channel goes with it.

What typically kills the RPC service? A third-party security suite. I've seen Symantec Endpoint Protection and some McAfee versions block RPC dynamic port ranges. The giveaway: the error appears across multiple unrelated applications, not just one.

Check Service State

sc query RpcSs
sc query RpcEptMapper

Both should show STATE : 4 RUNNING. If they're stopped, start them:

net start RpcSs
net start RpcEptMapper

But if they keep stopping, dig into the Event Viewer under System logs for source Service Control Manager. You'll see a 7031 or 7034 error saying the RPC service terminated unexpectedly. That points to a driver or filter causing the crash.

Firewall Rule Check

RPC uses dynamic port range 49152-65535 (or 1025-5000 on older Windows). If a firewall blocks these, the endpoint mapper can't negotiate a channel. For local COM, this isn't the issue — but for DCOM across machines, it's the first thing to verify.

3. Corrupted Proxy/Stub Marshaling

This one's rare but nasty. COM uses proxy/stub DLLs to marshal method calls across process boundaries. If the proxy DLL is missing, wrong version, or corrupted, the RPC channel will terminate mid-call with this exact error.

I hit this once with a custom COM component where the interface definition changed but the proxy DLL wasn't rebuilt. The client's marshaling code tried to pack parameters with the old layout, the server couldn't unpack them, and the channel died.

How to Confirm

• Check the application event log for CO_E_OBJNOTCONNECTED alongside 0x80010006 — that's a dead giveaway of a proxy mismatch.
• Run DCOMCNFG, find the failing component under Component Services, and verify the proxy DLL path in its properties.
• Re-register the proxy DLL: regsvr32 <proxydllname>.dll

For built-in COM objects (like Shell or Internet Explorer's), you can re-register the whole COM infrastructure:

regsvr32 /s vbscript.dll
regsvr32 /s jscript.dll
regsvr32 /s oleaut32.dll

Doesn't hurt, takes 10 seconds. I've seen it fix weird COM errors after a failed Windows update.

Quick-Reference Summary

The bottom line: don't waste time chasing ghosts. 90% of 0x80010006 errors are the first cause — just restart whatever owns the COM object and move on. The other 10% need a look at the RPC service health or the proxy DLLs. No reformat required.