Fix RPC_E_OUT_OF_RESOURCES (0x80010101) on Server 2019

The exact scenario that triggers this error

You're managing a Windows Server 2019 or 2022 box—could be a file server, an app server, or a terminal server. Users start complaining that a specific app—maybe a legacy ERP client, or a custom COM+ component—just stops responding mid-session. You open Event Viewer and see RPC_E_OUT_OF_RESOURCES (0x80010101) logged under the application or system section. It feels like the server is running fine otherwise—CPU is low, RAM shows 60% free. But the COM call fails every time.

I saw this last month on a customer's Exchange 2019 hybrid server. Every time the transport service tried to connect to a third-party archiving tool, it'd pop this error after about 4 hours of uptime. The server had 128GB RAM—plenty. But COM objects were leaking like a sieve.

Root cause: it's almost never about physical RAM

The error message says "out of resources," but don't go buying more RAM. The real culprit is the COM/RPC resource limit. Windows budgets RPC and COM resources per session—things like LRPC handles, private bytes, and unnamed kernel objects. When a component (like a DCOM server or a COM+ application) leaks these resources—typically by failing to release interface pointers—the RPC runtime hits a hard cap. After that, any COM call returns 0x80010101. It's a per-process or per-session limit, not system-wide.

The typical trigger: a poorly written COM component that doesn't call Release() on its interfaces. Or a service that opens RPC channels in a loop without closing them. Or an antivirus hook that intercepts COM calls and holds resources.

The fix: clear the blocked resources (3-step)

Step 1: Restart the offending COM+ application or service

1. Open Component Services (dcomcnfg from Run).
2. Expand Component Services > Computers > My Computer > COM+ Applications.
3. Find the application that's throwing the error. Right-click it and choose Shut down. If you can't shut it down, restart the associated Windows service.
4. Wait 10 seconds, then right-click and Start it again.

This clears the resource pool for that application. In my client's case, restarting the third-party archiving service fixed it for about 6 hours, then the leak came back. So we moved to step 2.

Step 2: Increase the RPC resource limits (if restarting doesn't stick)

If the leak is persistent (some apps just leak), you can raise the per-process RPC resource caps. This is a workaround, not a fix—but it keeps things running while you pressure the vendor.

1. Open Registry Editor (regedit).
2. Navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Rpc.
3. If the Rpc key doesn't exist, create it (right-click Microsoft > New > Key).
4. Inside Rpc, create a new DWORD (32-bit) called MaxRpcSize.
5. Set its value to 1048576 (that's 1 MB) in decimal.
6. Reboot the server for the change to take effect.

This raises the per-call memory allocation limit. It won't fix the leak, but will delay hitting the wall. I've also seen people adjust HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RpcSs—don't mess with that unless you know exactly what you're doing.

Step 3: Identify the leaking component with Process Monitor

If the error keeps coming back, find the source. Use Process Monitor from Sysinternals.

1. Download Procmon from Microsoft.
2. Set a filter for Process Name equal to the service/process that's failing.
3. Add another filter: Result contains RPC_E_OUT_OF_RESOURCES.
4. Reproduce the error.
5. Look at the call stack for each failure. It'll show you which DLL or executable is holding onto the resource.

In a case last year on Server 2016, it was a third-party backup agent that was calling CoCreateInstance in a loop without releasing the interface. Found it in 15 minutes with Procmon. The vendor's fix was a patch they'd been hiding in their knowledge base.

What to check if it still fails

• Antivirus exclusion: Some AV products hook COM calls—exclude the process from real-time scanning.
• Windowing station limits: On terminal servers, check HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\InstanceId—not common, but I've seen it.
• Memory fragmentation: Even if physical RAM is free, the RPC heap can fragment. A restart of the service buys you time.
• Hardware issue: Rare, but faulty memory controllers can corrupt RPC buffers. Run mdsched.exe if you're desperate.

Bottom line: 0x80010101 is almost always a leak inside a COM component. Restart buys you time, registry tweak buys you more time, but the real fix is finding who's not calling Release().