RPC_X_WRONG_PIPE_VERSION (0x728) fix for Windows Server

You're getting the RPC_X_WRONG_PIPE_VERSION error, and it's annoying as hell.

I've seen this on Server 2019, Server 2022, and even some Windows 10 Pro machines acting as RPC clients. The error shows up when an application tries to communicate over a named RPC pipe but the pipe version doesn't match what the server expects. Usually hits during COM+ or DCOM calls, or when using tools like dcomcnfg or oleview.

The fix: update your RPC runtime layer

Don't touch the registry. Don't mess with RPC port ranges yet. The culprit here is almost always a missing Windows security update that patches the RPC runtime. Specifically, look for these KBs:

• Server 2019 / Windows 10 1809+: KB5005565 or later cumulative updates
• Server 2022: KB5008223 or later
• Older systems: KB5004331 for Server 2016

Install the latest cumulative update from Microsoft Update Catalog or Windows Update. Reboot. Then test your app again. In 9 out of 10 cases, that's it — error gone.

But wait — what if updates don't help?

Here's the less common scenario: your app or driver is manually specifying an RPC pipe version that's too old or too new. This can happen with:

• Custom COM+ components compiled against an older Windows SDK
• Third-party backup agents (Veeam, Commvault) that use named pipes
• Legacy SQL Server named instances using RPC over TCP

For those cases, check the application logs for the exact pipe name. Run netstat -aon | findstr 135 to confirm RPC port mapper is running. Then restart the RPC service (net stop rpcss && net start rpcss) — but be warned, it'll kill all COM+ apps briefly.

Why this happens — the boring technical part

The RPC runtime negotiates a pipe version during connection setup. Both endpoints must agree on the version number. If one side got patched and the other didn't, the versions don't match. Windows Update KBs from mid-2021 onward changed how RPC handles pipe versioning to close a security vulnerability (CVE-2021-26414). So if your server is patched but the client isn't, or vice versa, you get error 0x728.

Named pipes use a version field in the RPC bind header. The server sends its supported version list, the client picks one. When neither side can agree — boom, RPC_X_WRONG_PIPE_VERSION. The fix is always to align the RPC runtime versions across all systems involved.

Less common variations of the same bug

I've seen this error pop up in three edge cases:

1. Hyper-V host to guest RPC calls: If your host runs Server 2022 and the guest runs Server 2016 without the 2021 update, you'll hit this. Patch the guest first.
2. Cross-forest trusts: Active Directory uses RPC for replication. If one DC is patched and the other isn't, you might see this in dcdiag. Patch all domain controllers to the same level.
3. Antivirus interfering with named pipes: Some AVs hook RPC calls and mangle the pipe version. Temporarily disable the AV to test if that's your issue. If so, update the AV or exclude RPC processes.

Prevention — don't let this come back

Keep your Windows Servers on the same patch level for RPC-related updates. Use WSUS or SCCM to push the same cumulative update to all machines in a role. For critical RPC-dependent apps (SQL, Exchange, SharePoint), test patches in a staging environment first — but don't skip them. The security risk from unpatched RPC is worse than a temporary pipe version error.

Set a monthly reminder to check the Microsoft Security Response Center for RPC CVEs. Subscribe to the MSRC RSS feed if you're that kind of sysadmin. And for heaven's sake, don't disable RPC port mapper — some forums suggest it. It'll break everything.

One more thing: if you're using firewall rules to restrict RPC dynamic ports, make sure the version negotiation doesn't get blocked. The RPC endpoint mapper uses TCP 135, but named pipes can use any port. Open the range 49152-65535 for RPC dynamic ports if you filter them. Otherwise, you'll get a different RPC error — but that's a story for another day.