RPC_E_FAULT (0x80010104) on Windows Server: Real Fixes

RPC_E_FAULT looks like a network error but almost never is. By the time you see 0x80010104, the client already reached the server over RPC and the server process picked up the call. What failed is the return trip — the COM server either crashed, hung past the call timeout, or couldn't marshal its result back. The message on the client side is deliberately vague because the client genuinely doesn't know which of those happened.

What's actually happening here is that RPC_E_FAULT is a container error. Inside the server's event log there's always a more specific failure sitting right next to it. Your job is to find that one.

Cause 1: The COM server process crashed mid-call

This is the one you'll hit most often. A client calls into a DCOM or COM+ server, the server starts doing work, then throws an unhandled exception. The RPC runtime on the client waits for a reply that never comes, and after the call timeout expires it hands you 0x80010104.

A real-world trigger: a document management app on a Windows Server 2019 terminal server. Users open a PDF, the app calls into a legacy 32-bit COM component that handles OCR. If the PDF is malformed, that component dereferences a null buffer, process dies, and every user on that server gets RPC_E_FAULT for the next few clicks. Restarting the app "fixes" it for ten minutes. It's not a fix.

The reason step 3 below works is that it forces the server side to log its own fault before the process vanishes. Without that, you're staring at an empty client log.

1. On the server, open Event Viewer and look under Windows Logs > Application. Filter for Application Error and .NET Runtime sources within a minute of the client error.
2. Note the faulting module. If it's a third-party DLL, that's your culprit.
3. Enable WER local dumps so you can actually open the crash. Set this registry key and recreate the failure:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\YourServer.exe]
"DumpFolder"=hex(2):43,00,3a,00,5c,00,64,00,75,00,6d,00,70,00,73,00
"DumpType"=dword:00000002
"DumpCount"=dword:0000000a

DumpType 2 gives you a full dump. Load it in WinDbg, run !analyze -v, and the stack trace will point at the faulting frame. Nine times out of ten it's a bad input the component didn't validate.

If the crash is in Microsoft code and you can't patch it, the real fix is to give the COM server its own process rather than sharing one. In DCOMCNFG, find the AppID under Component Services > Computers > My Computer > DCOM Config, open Properties, go to the Identity tab, and check This user with a dedicated service account. That isolates it from the client's session and stops one bad call from taking down everyone else.

Cause 2: DCOM identity or permissions are wrong

When the client and server are on different machines, DCOM has to launch the server under some identity. If that identity can't be resolved, can't log on interactively, or lacks the right launch/access permissions, the call gets partway in and dies. The HRESULT you see is still 0x80010104 because the client never learns why.

Classic scenario: someone hardens a server by removing the ANONYMOUS LOGON and Everyone entries from the DCOM default access permissions, then wonders why a backup tool that calls into a COM service breaks. The tool's service account was relying on one of those.

Fixes:

• Run dcomcnfg, expand Component Services > Computers > My Computer, right-click, Properties, and check the COM Security tab. Default Access Permissions should include SYSTEM, INTERACTIVE, and Administrators. Add your service account explicitly if you've pulled the broad groups.
• On the specific DCOM application, open Properties > Identity. If it's set to The launching user, and the launching user is a domain account without Log on as a batch job, the launch fails silently. Switch to This user and supply credentials, or grant the right via secpol.msc > Local Policies > User Rights Assignment > Log on as a batch job.
• Check HKLM\SOFTWARE\Microsoft\Ole for EnableDCOM. It needs to be Y. If Group Policy turned it off, you'll get this error on every remote call.

Also worth checking: if the machine was recently promoted or renamed, the SPNs for the COM service account may be stale. A quick setspn -L yourserviceaccount will show you. Missing SPNs cause Kerberos to fall back to NTLM, which doesn't always work for DCOM callbacks.

Cause 3: Call timeout or hang, not a crash

The server didn't die. It just took too long. RPC has a default call timeout of about 60 seconds for many operations, and if the server is blocked on a database query, a file lock, or a slow disk, the client gives up and logs 0x80010104.

Scenario: a WMI query against a busy SQL server. The WMI provider sits on top of a COM server that talks to the DB. If the DB has a lock held for 90 seconds, the WMI call times out client-side, you see RPC_E_FAULT, and the provider eventually completes happily with nobody listening.

How to tell this apart from a crash:

1. Open Performance Monitor on the server and watch the process's CPU and I/O during the failing call. If it's still working after the client errors, it's a timeout.
2. Check whether the server's event log shows a completion after the failure. No crash event = timeout.
3. Look at the client's DCOM error code in the Application log. If it's 10010 (server did not register within timeout), the launch is slow, not the call.

The fix depends on where the slowness lives. If it's a known slow query, tune it. If it's a genuinely long operation, raise the call timeout on the client side by setting COLE_DEFAULT_TIMEOUT or passing an explicit timeout to CoInitializeSecurity. Don't just raise it blindly — a longer timeout hides the problem and ties up server threads.

For WMI specifically, you can override the timeout per call:

Get-WmiObject -Class Win32_Product -ComputerName SRV01 -OperationTimeoutSec 300

Note that OperationTimeoutSec only helps if the underlying COM call honours it. Some providers ignore it entirely, in which case the real fix is upstream.

Quick reference

The single most useful habit with 0x80010104: stop debugging the client. The answer is always on the server. The client just tells you the call failed. The server tells you why.