Fixing 0x80010116 RPC_S_WAITONTIMER OLE Errors

You'll see 0x80010116 when an OLE automation client (like a legacy VB6 app or an older COM+ component) calls a remote server and the RPC call takes too long. Common trigger: a scheduled task that runs a COM object on a remote Windows Server, and the remote server is slow or unreachable for a few seconds. The client waits, times out, and throws this error.

What's really happening

The error code RPC_S_WAITONTIMER means OLE is stuck in a retry loop. It sent a request via RPC to a remote DCOM object, didn't get a response in time, but instead of failing fast, it's waiting and retrying. The culprit here is almost always the DCOM timeout defaults — they're too short for your network conditions, or the remote server's RPC service is bogged down.

Don't bother reinstalling the COM component or rebuilding the app. That rarely helps. The fix is in the DCOM configuration and network stack.

Step-by-step fix

1. Check the remote server's RPC service – log into the server that hosts the COM object. Open Services.msc. Make sure "Remote Procedure Call (RPC)" is running. If it's set to Manual or Disabled, change it to Automatic and restart it.
2. Increase DCOM timeout on the client – This is the big one. Open Component Services (dcomcnfg.exe). Navigate to Component Services > Computers > My Computer. Right-click My Computer, choose Properties. Go to the Default Protocols tab. Add Connection-oriented TCP/IP if it's missing. Then go to the COM Security tab and click Edit Limits under both Access and Launch permissions. Set everyone to Allow Remote Access and Remote Launch. Apply. Then reboot the client machine.
3. Tweak the RPC port range – If you're seeing this across a firewall, the default RPC dynamic port range (49152-65535) might be blocked. Open an admin command prompt on the remote server and run:

netsh int ipv4 set dynamicport tcp start=49152 num=16384
netsh int ipv4 set dynamicport udp start=49152 num=16384

Then reboot the server. If your firewall rules are tight, open those ports on the remote server's firewall.

4. Reduce OLE retry attempts via registry – This one's for stubborn cases. On the client machine, open Regedit and go to:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole

Create a DWORD (32-bit) value named EnableDCOM and set it to Y (hex 59). Also create a DWORD named DefaultTimeout and set it to 300000 (5 minutes in milliseconds). This gives OLE more time before it throws the timeout. Reboot after changes.

5. Check network latency – Run a continuous ping from the client to the remote server. If you see packet loss or latency spikes above 200ms, that's your problem. Fix the network or move the COM object to the same subnet.

If it still fails

Check the Application event log on both machines. Filter for Event ID 10010 (DCOM timeout) or Event ID 10028 (RPC timeout). Those logs tell you exactly which COM class ID and which server is causing the hang. Also check if the remote server's Windows Firewall is blocking RPC traffic. Quick test: temporarily disable the firewall on the remote server and see if the error goes away. If it does, you've got a firewall rule issue, not a DCOM one.

One last thing: if the COM object is an out-of-process EXE, make sure that EXE is running on the remote server. Some lazy devs wrote COM servers that don't auto-start. You might need to set the EXE to run as a service or trigger it manually once before the client connects.