Fix RPC_NT_WRONG_STUB_VERSION (0XC003005B)

What's happening

You got hit with error code 0XC003005B — RPC_NT_WRONG_STUB_VERSION. It means the client program and the server program disagree on which version of the RPC interface to use. One side is expecting a different format, different number of parameters, or different types. This usually pops up when you run an older client against a newly patched server, or vice versa.

I've seen this most often in environments running Windows Server 2016 or 2019 with custom COM+ applications, or with third-party apps that use DCOM for inter-process communication. The moment you apply a Windows update that patches the RPC runtime, bam — the error shows up.

The fix: update the server application

Nine times out of ten, the fix is on the server side. The server's RPC interface definition (the MIDL-generated stub) has changed — maybe after a software update, maybe after a Windows update that touched the RPC runtime. You need to make sure the server application's binary matches the version the client expects.

1. Identify the server application. Open Event Viewer (eventvwr.msc). Go to Windows Logs > System. Look for events with source RPC or DCOM around the time the error occurred. The event details will tell you which EXE or DLL registered the RPC interface.
2. Check the version. Right-click the executable or DLL in File Explorer, go to Properties > Details. Note the Product version and File version. Compare this to the client's version (ask the client machine or check the vendor's documentation).
3. Reinstall or update the server app. Download the latest version from the vendor. Run the installer — it should replace the old stub. After installation, restart the service. Open Services (services.msc), find the service related to that app, right-click > Restart.
4. Test from the client. Run the client again. If you still see the error, move on to the next section.

Why this works

RPC stubs are generated from an Interface Definition Language (IDL) file. That file includes a version number (the uuid and version attributes in the interface definition). When the server's stub is compiled, it bakes that version number into the binary. The client's stub has its own version number. If they don't match — even by one minor digit — the RPC runtime refuses to connect. Updating the server ensures both sides speak the same version.

Sometimes a Windows update modifies the system RPC runtime (rpcrt4.dll). That changes the protocol negotiation behind the scenes. Even if the app's stub hasn't changed, the runtime might reject an old stub format. The real fix is still the same: get the latest build of the server application that's compatible with the current OS patch level.

Less common variations

Client is older than server

If you can't update the server (maybe it's a line-of-business app that the vendor stopped supporting), flip the approach — update the client instead. Install the same version of the client app that matches the server's stub. This is rare but happens in large enterprises where a server got patched but a remote office client didn't.

COM+ application mismatch

For COM+ applications hosted on Windows Server, go to Component Services (dcomcnfg). Expand Component Services > Computers > My Computer > COM+ Applications. Find the application that's failing. Right-click > Properties. On the Identity tab, check if the user account has permissions. Then go to the Advanced tab and click Export — this creates a client-side installer (.msi). Install that MSI on the client machine. It registers the correct stub version locally.

Firewall or routing interference

Sometimes the error isn't a real stub mismatch — it's a network issue that corrupts the RPC negotiation packets. Check Windows Firewall logs or use Wireshark to see if the RPC bind request is getting fragmented or dropped. If you see TCP resets, open port 135 (RPC Endpoint Mapper) and the dynamic RPC port range (default: 49152–65535). This is rare, but I've seen it twice this year.

Prevention

Keep your server applications updated. The moment you install a Windows security update that touches RPC (check the KB article — any mention of rpcrt4.dll is a red flag), test your critical RPC-dependent apps immediately. Don't wait for users to scream.

For developers: always use strict RPC interface versioning. Bump the version number in your IDL file every time you change a parameter or method. That way, if a client fails, it fails loudly with this exact error — and you know exactly what to fix.

For IT admins: automate stub consistency checks. Use PowerShell to compare file versions of known RPC server DLLs across all servers. Something like:

Get-ChildItem -Path "C:\Program Files\YourApp\" -Filter *.dll | ForEach-Object { $_.VersionInfo.FileVersion }

Log those versions. If a patched server shows a different version than the rest, you found your problem before the error hits.