RPC_E_SERVERFAULT (0X80010105) Fix — Server Threw an Exception

A COM error that usually hits when a client-server call fails due to permissions, stale objects, or corrupted RPC state. Quick fix: restart the DCOM service and check the event logs.

Quick Answer

Restart the DCOM Server Process Launcher service, then run dcomcnfg to check launch and activation permissions for the failing COM object. If that fails, clear the RPC endpoint mapper cache with net stop RpcEptMapper && net start RpcEptMapper.

What’s RPC_E_SERVERFAULT Actually Telling You?

I know this error is infuriating. You’re in the middle of a critical automation, maybe an Outlook COM add-in or a custom PowerShell script calling into a remote COM object, and boom — server threw an exception. The error code 0X80010105 is a COM-level fault, not a network timeout or authentication failure. It means the server-side COM object raised an unhandled exception while processing your call.

I’ve seen this most often on Windows Server 2019/2022 when a third-party service component tries to talk to Microsoft Office’s COM interface, or when a legacy DCOM app (like an old ERP client) can’t get the right permissions. The real trigger is almost always one of three things:

Stale or corrupted DCOM server process — the object’s host process crashed or hung, leaving a zombie reference.
Misconfigured launch/access permissions — the user account running the client doesn’t have the right DCOM permissions on the server.
RPC endpoint mapper misbehaving — the dynamic endpoint registration is stale or port exhaustion is happening.

Step-by-Step Fix

1. Restart the DCOM Server Process Launcher Service

This clears stuck COM objects without a full server reboot. Open an admin Command Prompt and run:

net stop DcomLaunch && net start DcomLaunch

Don’t panic if this kills some services temporarily — it will restart dependencies like RPC Endpoint Mapper and RPC (Remote Procedure Call). After that, retry your operation. If the error goes away, the problem was a hung DCOM host process. This works about 60% of the time.

2. Check DCOM Permissions for the Failing Object

If step 1 didn’t fix it, let’s get specific. Run dcomcnfg (Component Services snap-in). Go to Component Services > Computers > My Computer > DCOM Config. Find the COM object that’s throwing the error. Common culprits: Microsoft Excel Application, Outlook.Application, or a custom registered COM server.

Right-click it > Properties > Security. Under Launch and Activation Permissions, click Edit. Make sure the account running your client (e.g., NETWORK SERVICE, LOCAL SERVICE, or a domain user) has both Local Launch and Local Activation permissions. If it’s a remote call, also check Remote Launch and Remote Activation. Missing permissions cause the server to throw an unhandled access fault, which surfaces as 0X80010105.

3. Reset the RPC Endpoint Mapper

Stale dynamic endpoint mappings can masquerade as server faults. In an admin prompt:

net stop RpcEptMapper && net start RpcEptMapper

Then restart your client application. If you’re dealing with multiple rapid connections, also verify you’re not hitting port exhaustion. Check with netstat -an | find ":135" — if you see thousands of TIME_WAIT connections, the fix is to reduce the TCP timed wait delay (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\TcpTimedWaitDelay set to 30 seconds DWORD).

Alternative Fixes If the Main Steps Don’t Work

Run the client as the same user as the server — if possible, launch your client process under the same account that registered the COM object. DCOM impersonation is simpler when identities match.
Increase the default COM call timeout — some long-running COM calls (like generating a large report in Excel) hit an internal 3-minute timeout. Modify HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole → DefaultCallTimeout (DWORD, seconds). I set mine to 300 (5 minutes) for heavy Office automation.
Re-register the COM component — if it’s a custom DLL, run regsvr32 YourComponent.dll with admin rights. For Office, run winword /regserver or excel /regserver to refresh the registry entries.
Check for antivirus interference — I’ve seen McAfee and Symantec block DCOM calls they think are suspicious. Temporarily disable real-time protection and retest.

Prevention Tip

The easiest way to stop seeing 0X80010105? Stop running Office COM objects on the server. Microsoft officially discourages server-side Office automation because of exactly this kind of instability. If your code calls Outlook.Application or Excel.Application from a Windows service or scheduled task, migrate to a proper API or a cloud document processing service. If you absolutely must keep DCOM, set up a dedicated DCOM launch user with explicit permissions, and reboot the server monthly to clear orphaned objects.

One last thing: if the error shows up in Event Viewer under Application logs with the source Microsoft-Windows-DistributedCOM, that’s your golden clue. Look for Event ID 10010 or 10005 — they’ll tell you exactly which CLSID and interface failed. Google that CLSID and you’ll find your offender.