RPC_E_SERVER_CANTMARSHAL_DATA 0x8001000D Fix

That 0x8001000D error means the RPC server ran out of room or resources while packing the reply. Fix memory, timeout, or payload size — in that order.

You've got an app throwing RPC_E_SERVER_CANTMARSHAL_DATA (0x8001000D) and the stack trace points somewhere useless. Welcome to the club. This one's been around since the NT days and it still pops up in 2024 on Server 2019/2022 boxes running COM+ or any DCOM service that returns fat payloads.

Here's what the code actually means: the RPC callee (the server side) received your call fine, did the work, and then couldn't serialize its return value back to the caller. Almost always that's memory pressure on the server process, a payload that blew past a buffer, or a proxy/stub mismatch. Let's walk it.

Step 1 — The 30-second fix: kill stale processes and free memory

The culprit here is almost always a leaking COM+ process that's been chewing memory for days. Before you touch any config, do this:

Open Task Manager on the server (not the client — people always check the wrong box).
Sort by Working Set, descending.
Find your COM+ surrogate — dllhost.exe — or the service EXE in question.
Note its memory. If it's north of 1.5 GB on a 32-bit process, that's your problem.
Restart the COM+ application (Component Services → COM+ Applications → right-click → Shut down), then start it again.

If the error clears after restart, you've confirmed it's a leak — not a config bug. Don't pat yourself on the back and walk away. It'll come back in 3 to 10 days. Schedule a proper fix (Step 3).

Quick check: if dllhost.exe is over 1 GB and climbing, stop troubleshooting and start looking at your object pooling settings.

Step 2 — The 5-minute fix: bump the RPC timeout and buffer sizes

If the server isn't leaking and this happens intermittently under load, you're probably hitting a marshaling buffer or timeout limit. Two registry knobs matter here.

Raise the RPC receive buffer

On both client and server:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Rpc
  Value: MaxRpcSize (DWORD)
  Default: 1048576 (1 MB)
  Try: 4194304 (4 MB) or 8388608 (8 MB)

Reboot required. This is the one that actually helps when your return payload is a big array, a large dataset, or a serialized object graph. Don't set it to 100 MB "just in case" — you'll just move the OOM elsewhere.

Check the DCOM timeout

Under load, marshaling takes time. If the server takes longer than the client's timeout, you get this error wrapped in a timeout. Bump it via dcomcnfg:

Component Services → Computers → My Computer → Properties
  → Default Protocols → DCOM Protocols → Properties
  → Timeout: raise from 5 to 15 minutes

Also check the COM+ application's activation and call timeouts under its Properties → Options tab. The defaults (3 min call, 3 min activation) bite hard on busy servers.

Step 3 — The 15+ minute fix: fix the actual leak or payload

Now the real work. Ninety percent of recurring 0x8001000D errors on production servers come from one of these three things.

3a. Object pooling is off (or wrong)

If your COM+ component creates a new instance per call and never releases it, memory grows until marshaling fails. Turn on object pooling:

Component Services → COM+ Applications → [Your App]
  → Components → [Your Class] → Properties → Activation
  → Enable object pooling
  → Min pool size: 1
  → Max pool size: 20
  → Creation timeout: 30000 ms

Set IObjectControl::Deactivate to release your heavy resources (DB connections, large arrays, file handles). This alone fixes most cases.

3b. Your return type is too big for the wire

Returning a 200 MB DataSet over DCOM will fail. Every time. There's a hard practical limit around a few MB per marshaled call. Fix it at the source:

Return IStream or a reference token instead of the raw object
Page the results — return 1000 rows, not 1,000,000
Push the data to a shared queue or file and return a handle
If you control both ends, switch to a proper service (gRPC, HTTP) — DCOM is not the tool for fat payloads

3c. 32-bit process hitting the 2 GB wall

Classic. Your COM+ app is 32-bit, running on a 64-bit Server 2019, and it dies at ~1.4 GB working set because of fragmentation. Options:

Rebuild as x64. This is the real fix.
If you can't rebuild, enable /LARGEADDRESSAWARE on the binary — buys you up to 4 GB.
Short-term: recycle the COM+ app on a schedule (set Recycle → Memory Limit to 800 MB).

Quick reference: what each symptom points to

Symptom	Likely cause	Fix
Errors after 3–7 days uptime	Memory leak	Object pooling + Deactivate cleanup
Errors under heavy load only	Timeout or buffer size	MaxRpcSize + DCOM timeout
Errors on specific large calls	Payload too big	Stream/page the return
Errors immediately after deploy	Proxy/stub mismatch	Re-register the type library
`dllhost.exe` at 1.4+ GB	32-bit address space	Rebuild x64

One thing people get wrong

Don't chase this on the client side. 0x8001000D is a server-side marshaling failure — the client got a valid error reply, which means the client's RPC stack is fine. Every forum thread where someone "fixed" this by patching the client machine was a coincidence (they rebooted the server at the same time).

Also skip the sfc/DISM dance. It won't help. Corrupted rpcrt4.dll gives you different errors (RPC_S_* codes in the 1700s), not marshaling failures.

If you've done Steps 1–3 and it's still failing, enable RPC ETW tracing with logman or grab a memory dump of the failing dllhost.exe with ProcDump and look at the heap. At that point it's not a Windows problem — it's your component.