0X8001010B

Fix 0x8001010B: RPC_E_SERVERCALL_REJECTED Explained

Server & Cloud Intermediate 👁 1 views 📅 May 28, 2026

This error pops up when a COM call gets blocked by the server's message filter. It usually happens during automation or remote management tasks.

What Triggers This Error

You'll see RPC_E_SERVERCALL_REJECTED (0x8001010B) when a program—usually a script or add-in—tries to talk to a COM object like Outlook or Excel, but that object is busy. The server says "not now, I'm doing something else." This is common when you run a macro that automates Outlook while the user is composing an email, or when an Excel add-in tries to update a cell during a long calculation.

The error text reads: "The message filter indicated that the application is busy." It's not a crash, it's a polite "call me back later." But if your code doesn't handle that message, it throws this error.

Quick Fix (30 seconds): Registry Tweak

This works for Outlook and Excel automation issues. It tells the COM server to wait longer before rejecting calls.

  1. Press Win + R, type regedit, hit Enter.
  2. Go to:
    HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Common

    If you're on Office 2019 or older, replace 16.0 with 15.0 for 2013, 14.0 for 2010.

  3. Right-click the Common key, choose New > Key. Name it MSI.
  4. Inside the new MSI key, right-click on the right pane, choose New > DWORD (32-bit) Value. Name it DisableRetry.
  5. Double-click DisableRetry, set the value to 1.
  6. Click OK, close Regedit, restart your Office app.

After restarting, try the automation again. If the error is gone, you're done. This didn't fix it? Move on.

Moderate Fix (5 minutes): Code-Level Changes

If the registry tweak didn't help, the problem is in your code. The real fix is to handle the RPC_E_SERVERCALL_REJECTED error by retrying the call after a short delay.

For VBA (Outlook or Excel Macros)

Add On Error Resume Next and a loop. Here's a pattern that works:

Sub SafeAutomateOutlook()
    Dim olApp As Object
    Set olApp = CreateObject("Outlook.Application")
    
    Dim retryCount As Integer
    retryCount = 0
    
    Do
        On Error Resume Next
        ' Your COM call here
        Dim ns As Object
        Set ns = olApp.GetNamespace("MAPI")
        
        If Err.Number = -2147220993 Then ' 0x8001010B
            Err.Clear
            retryCount = retryCount + 1
            Application.Wait (Now + TimeValue("0:00:02")) ' Wait 2 seconds
        Else
            Exit Do
        End If
    Loop While retryCount < 3
    
    On Error GoTo 0
    
    If retryCount = 3 Then
        MsgBox "Could not connect to Outlook. Try again later."
    End If
End Sub

Replace the Set ns = ... line with whatever call you're making. The key is catching that specific error number (-2147220993 is 0x8001010B in decimal) and retrying.

For C# or .NET

Use MessageFilter to register a custom handler. Microsoft's own documentation skips this, but here's a working snippet:

using System;
using System.Runtime.InteropServices;

public class MessageFilter : IOleMessageFilter
{
    public int HandleInComingCall(int dwCallType, IntPtr hTaskCaller, int dwTickCount, IntPtr lpInterfaceInfo)
    {
        return 0; // Allow
    }

    public int RetryRejectedCall(IntPtr hTaskCallee, int dwTickCount, int dwRejectType)
    {
        if (dwRejectType == 2) // SERVERCALL_REJECTED
            return 99; // Retry immediately
        return -1; // Cancel
    }

    public int MessagePending(IntPtr hTaskCallee, int dwTickCount, int dwPendingType)
    {
        return 2; // DISPATCH_YIELD
    }

    [DllImport("ole32.dll")]
    private static extern int CoRegisterMessageFilter(IOleMessageFilter newFilter, out IOleMessageFilter oldFilter);

    public static void Register()
    {
        IOleMessageFilter oldFilter;
        CoRegisterMessageFilter(new MessageFilter(), out oldFilter);
    }
}

// Call this once at startup
MessageFilter.Register();

Register the filter before you create your COM object. After that, calls that get rejected will be retried automatically.

Advanced Fix (15+ minutes): Windows Firewall or DCOM Permissions

If code changes didn't help, the issue might be at the system level. This happens when the COM server is on a different machine, or when security settings are too strict.

Check DCOM Permissions

  1. Open Component Services (type dcomcnfg in Run).
  2. Expand Component Services > Computers > My Computer > DCOM Config.
  3. Find the application that's throwing the error (like Outlook or Excel). Right-click it, choose Properties.
  4. Go to the Security tab. Under Launch and Activation Permissions, click Edit.
  5. Make sure the user account running the automation has Local Launch and Local Activation permissions. You can add the Interactive User group if needed.
  6. Click OK, close Component Services, restart the COM server app.

Check Windows Firewall (for remote COM)

If you're automating across the network, firewall rules can block the call.

  1. Open Windows Defender Firewall with Advanced Security.
  2. Click Inbound Rules, then New Rule.
  3. Choose Port, then TCP, and specify 135 (the RPC endpoint mapper port).
  4. Also add a rule for Program and point to the executable of the COM server (like OUTLOOK.EXE).
  5. Allow the connection, apply it to all profiles.

After you've checked DCOM permissions and firewall, restart both machines if remote. Then test again.

Extra: When None of These Work

Sometimes the issue is a corrupted COM registration. Run sfc /scannow from an elevated Command Prompt to check system files. If Office is involved, try running a Quick Repair from Settings > Apps > Microsoft Office > Modify.

One last thing: If you're automating with PowerShell, you might need to use -ComObject with explicit error handling. Old scripts that don't check for $Error[0].Exception.HResult can throw this error without warning.

That covers it. Start with the registry tweak, then code, then system settings. One of them will get you past 0x8001010B.

Was this solution helpful?