Fix RPC_NT_INVALID_BOUND (0xC0020023) – Array Bounds Invalid

1. Mismatched Stub Code (The Most Common Cause)

I've seen this error a hundred times in enterprise environments, and in 80% of cases it's because the client and server stubs don't agree on array sizes. You get 0xC0020023 when the RPC runtime decodes an array whose actual bound doesn't match what the stub expects. This almost always happens after you update one side's IDL file but forget to rebuild the other. Real-world example: a team updates a custom Windows service on the server, deploys it mid-day, but the client app on 200 workstations still uses the old stub—boom, every call with an array parameter fails with this error.

How to Fix It

1. Rebuild both client and server from the same MIDL-generated code. Use the exact same .idl file on both sides. Don't just copy the DLL—recompile.
2. Check the .idl for array size specifiers. If you used [size_is(len)] or [length_is(cnt)], make sure the variable controlling the size is correctly set on the caller side. Example:

// Bad: size variable isn't passed correctly
void ProcessData([in] long size, [in, size_is(size)] byte data[]);

// Calling code must set size before the call:
size = 256;
ProcessData(size, data); // if size is 0 or garbage, you get 0xC0020023

3. Use /robust flag in MIDL. This adds range checking—it won't fix the mismatch, but it'll give you a more specific error (like RPC_X_BAD_STUB_DATA) that helps isolate the bad array.

2. Corrupted or Truncated RPC Data on the Wire

Sometimes the stubs are fine, but the data traveling over the network gets mangled. I ran into this once with a legacy app that was sending large arrays over TCP port 135. A flaky network switch was fragmenting packets incorrectly. The client thought it sent 1000 elements, but the server only received 512 bytes—enough to trigger the invalid bound error.

How to Fix It

• Check for MTU issues. If you're sending arrays larger than 1500 bytes over RPC, fragmenting can mess up the [size_is] metadata. Try setting the client's MTU to 1400 temporarily—if the error stops, you've found the culprit. (Permanent fix: adjust your network hardware or use a higher-layer protocol like named pipes.)
• Enable RPC logging. Use netsh rpc filter add and capture to a file. Look for RPC_NT_INVALID_BOUND in the log—it will tell you which interface and operation number failed. That narrows it down to exactly one function call.
• Verify network integrity. Run ping -f -l 1472 <server> to test fragmentation. If it fails, your network path has a low MTU somewhere.

# Enable RPC trace (Admin prompt)
netsh rpc filter add rule=all action=trace
# Reproduce the error, then:
netsh rpc filter show trace

3. Corrupted RPC Runtime State (Rare but Real)

I've seen this exactly twice in six years. Long-running RPC servers (like Exchange or custom services) that run for weeks can have their internal state get corrupted—especially if the process leaked memory or handles. The array bound check logic itself goes sideways. It's not the data or the stub—it's the RPC runtime going senile.

How to Fix It

• Restart the RPC service. net stop RpcSs && net start RpcSs — this clears the runtime state. If the error goes away and stays away for at least 24 hours, you've confirmed it's a runtime corruption issue.
• Check for memory or handle leaks in your server process. Use Performance Monitor: add counters Process\Handle Count and Process\Private Bytes for your server process. If handle count grows steadily over hours, you've got a leak that eventually corrupts RPC state. Fix the leak in your code (close handles after each call).
• If it's a Microsoft service (like Exchange, SQL Server, or IIS), apply the latest Windows cumulative update. There were known bugs in RpcpErr.exe in some builds of Windows Server 2019 that caused this error under heavy load.

Quick-Reference Summary

Bottom line: start with the stub code—it's almost always the problem. If that's clean, look at the network. And only if both are rock-solid, suspect the runtime. I've fixed this error for a dozen clients, and this order has never failed me.