RPC_E_SERVERCALL_RETRYLATER (0X8001010A) Fix – App Busy

Cause #1: The Target Application Is Stuck on a Modal Dialog

This is the #1 reason you see 0x8001010A. Your script or code is trying to automate Excel (or Outlook, Word, etc.) and the app has a modal dialog box open – like a "Do you want to save changes?" prompt or a "Cannot open file" error. COM waits a few seconds then throws this error because the message filter on the target app says "I'm busy, try later."

You've probably seen this when an Excel macro fires off a COM call to another instance, or a PowerShell script automates Outlook to send an email. The fix is straightforward: kill the stalled dialog.

Fix It – Kill the Hidden Dialog

1. Open Task Manager (Ctrl+Shift+Esc).
2. Go to the Details tab. Look for EXCEL.EXE or OUTLOOK.EXE. If there are multiple instances, look at the one that's using CPU or sitting at 0% but won't respond.
3. Right-click the process and select End task. Yes, you'll lose unsaved changes, but you already lost them because the app is stuck.

Don't bother with taskkill /f /im excel.exe from an admin prompt unless you're sure. If you have multiple instances, use taskkill /f /pid <PID> after identifying the correct one.

Or better: prevent it from happening. In your automation code, set DisplayAlerts = False before doing any save or close operations. Example in VBA:

Application.DisplayAlerts = False
wb.Close SaveChanges:=False
Application.DisplayAlerts = True

For PowerShell with COM objects, do:

$excel.DisplayAlerts = $false
$wb.Close()

That suppresses the "Do you want to save?" dialog entirely. The app won't block, and you won't get 0x8001010A.

Cause #2: DCOM Timeout Too Short for a Slow Operation

Sometimes the app isn't stuck – it's just slow. A large Excel file saving to a network share, or an Outlook rule processing hundreds of emails. The default COM call timeout is around 30 seconds. If the operation takes longer, you get this error. But honestly, this is rare. Most people blame the timeout when the real issue is a hidden dialog.

Still, if you've ruled out dialogs, you can adjust the timeout on the calling side.

Fix It – Increase the COM Call Timeout

In your automation code, you can set the message filter timeout. In C# or VB.NET, implement IMessageFilter:

public class MyMessageFilter : IMessageFilter {
    public int HandleInComingCall(...) => 0;
    public int RetryRejectedCall(...) => 5000; // retry after 5 seconds
    public int MessagePending(...) => 0;
}
Application.RegisterMessageFilter(new MyMessageFilter());

For VBA, you can't directly set this. Instead, use Application.OnTime to retry later, or break your operation into smaller chunks. Or set a registry key on the server side to lengthen the default timeout.

On the machine running the COM server (the busy app), add this DWORD:

HKLM\SOFTWARE\Microsoft\Ole\EnableDCOM = Y
HKLM\SOFTWARE\Microsoft\Ole\DefaultCallTimeout = 120000  (2 minutes)

But frankly, I've done this maybe 3 times in 14 years. Dialogs are the culprit 9 times out of 10.

Cause #3: The COM Server Process Has Hung or Crashed Silently

Less common but nasty. The server app (e.g., Excel) is running but not responding – maybe a corrupted add-in, a network drive that dropped, or a crash that left the process alive. The message filter sees a non-responsive window and returns 0x8001010A.

Fix It – Clean Up the Process and Add-in

1. Open Task Manager, find the hung process, and end it (same as Cause #1).
2. Restart Excel in safe mode: excel.exe /safe. This disables all add-ins. If the error goes away, disable add-ins one by one to find the bad one.
3. Check for corrupted templates in %APPDATA%\Microsoft\Excel\XLSTART. Rename that folder to something else, then try again.

Also, check the Windows Event Viewer under Windows Logs > Application. Look for errors from the COM source or the Office app. A crash event (Event ID 1000 for example) points to a specific faulting module.

If it's a DCOM configuration issue (rare), use dcomcnfg to review the identity settings for the component. Make sure it's running under the correct user account. But again, don't spend time there unless you've exhausted the first two causes.

Quick-Reference Summary Table

Bottom line: when you see 0x8001010A, think "modal dialog" first. Fix that and you're done. The other causes are noise. Save yourself the headache and automate with DisplayAlerts turned off.