Fix RPC_E_CALL_REJECTED (0x80010001) – the real cause

Yeah, you've seen this. You're in the middle of an automation script—maybe an Outlook macro, maybe a VBScript slamming Excel—and boom: RPC_E_CALL_REJECTED (0x80010001). The COM call was rejected by the callee. The message is useless. Here's what actually fixes it.

Immediate Fix: Kill the Stale Instance

The fastest way out is to terminate the hung Office process that's holding the COM object. The callee (your Excel, Outlook, Word) is still running but its RPC channel is broken—it won't accept new calls until it's restarted.

Open Task Manager (Ctrl+Shift+Esc). Go to the Details tab.
Look for OUTLOOK.EXE, EXCEL.EXE, WINWORD.EXE, or POWERPNT.EXE depending on what you're automating.
Right-click and End task. Force it if needed.
Now run your script again. It should work—for now.

If you're running this from a command line and can't open Task Manager, use taskkill /F /IM outlook.exe (adjust the name). That kills the process instantly.

Why this works: What's actually happening here is that the COM object (the callee) has entered a state where its outgoing RPC channel is blocked or broken—often because a previous call timed out or the thread pool is exhausted. The object itself is alive, but it can't accept new marshaled calls. Killing it forces the COM runtime to release the object, and your next CreateObject or GetObject spawns a fresh instance with a clean RPC channel.

Root Cause: Why the Channel Breaks

The error 0x80010001 means the server process rejected the call. But the server didn't crash—it's running. Three things cause this most often:

Stale COM references. Your script created an object, the user closed the application manually, and now you're trying to call a method on a zombie. COM still thinks the object is there but the RPC endpoint is dead.
Thread exhaustion in the Office app. Office applications have a finite thread pool for COM calls. If your script fires too many calls too fast without waiting for replies, the pool fills up. New calls get this rejection.
DCOM permission mismatch. On multi-user systems or Terminal Servers, the DCOM launch permissions for the Office application may not match the calling user's session. This is rare on a single-user machine but common in RDS environments.

Preventing It Long-Term

The kill-and-retry fix is a band-aid. To stop seeing this error:

1. Always Release COM Objects Explicitly

In VBScript:

Set objExcel = CreateObject("Excel.Application")
' ... do work ...
objExcel.Quit
Set objExcel = Nothing

In C# or PowerShell, call Marshal.ReleaseComObject() in a finally block. Don't rely on garbage collection—COM objects are reference-counted, and the GC won't release them deterministically.

2. Add Retry Logic with Backoff

If you're hammering the same object with rapid calls, add a short sleep between them:

For i = 1 To 10
    On Error Resume Next
    objExcel.Workbooks.Open "C:\report.xlsx"
    If Err.Number = -2147221503 Then ' 0x80010001
        WScript.Sleep 500
        Err.Clear
    Else
        Exit For
    End If
Next

3. Check DCOM Permissions (Multi-User Systems Only)

Run dcomcnfg → Component Services → Computers → My Computer → DCOM Config. Find Microsoft Excel Application. Right-click → Properties → Security. Under Launch and Activation Permissions, set it to Customize and add Interactive User with Allow for Local Launch and Local Activation. This ensures the calling user can spawn the object in their own session.

Less Common Variations

Sometimes you'll see 0x80010001 in contexts that aren't Office automation:

Scenario	What's Happening	Fix
Internet Explorer COM automation	IExplore.exe rejects calls after a navigation timeout	Kill iexplore.exe. Switch to WebDriver for reliable automation.
Windows Shell COM (e.g., `Shell.Application`)	Explorer.exe thread pool is starved	Restart Explorer via Task Manager. Rare unless you're hammering shell folders.
COM+ queued components	Message queue listener is offline or crashed	Restart the COM+ application from Component Services.
.NET interop with STA objects	Your background thread tried to call an STA COM object without marshaling	Use `[STAThread]` attribute on the calling thread or use `Thread.SetApartmentState`.

When to Reboot vs. When to Just Kill the Process

If you're seeing this error daily, don't reboot the whole machine—it's overkill. The issue is almost always a single hung Office process. Reboots waste time and don't teach you anything. Kill the process, inspect your script, and fix the object lifetime. That's the real solution.

One edge case: on Windows Server 2016 with Office installed (not recommended, but people do it), the RPC timeout for DCOM defaults to 60 seconds. If your automation takes longer, you'll get this error regardless of object cleanup. Bump the timeout via HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole\DefaultTimeout (DWORD, in milliseconds, max 60000). But honestly, just refactor your script to do smaller chunks.

Summary

0x80010001 is a misbehaving callee, not a broken OS. Kill the hung Office process, release your COM objects, add retry logic, and you'll rarely see it again. Don't let the error code scare you—it's just COM telling you politely that its hands are full.