Fix RPC_X_BAD_STUB_DATA (0x000006F7) in 3 Tiers

What's Actually Happening?

When you see RPC_X_BAD_STUB_DATA (0x000006F7), the RPC runtime has received data from a client that doesn't match what the server-side stub expects. This usually means a mismatch in the interface definition — either a corrupted RPC endpoint mapper, a broken DCOM configuration, or a third-party service sending malformed packets. I've seen this most often after a Windows Update (especially on Server 2019 and 2022) when the update changes RPC internals but leaves old registrations hanging around. Another common trigger: an antivirus or firewall blocking or mangling RPC traffic between machines on the same subnet.

Tier 1: The 30-Second Fix — Restart RPC Services

Start here because it takes 30 seconds and fixes about 40% of cases. The RPC Endpoint Mapper can cache stale references after a service crash or update. Kill it and let it rebuild.

1. Open an elevated Command Prompt or PowerShell (Run as Administrator).
2. Run these commands in order:

net stop RpcSs && net start RpcSs
net stop RpcEptMapper && net start RpcEptMapper

The reason we stop RpcSs first is that RpcEptMapper depends on it. If you get a 'service is not responding' error, use sc query RpcSs to check the state, then kill it with taskkill /F /FI "SERVICES eq RpcSs" if needed.

After restarting both, try whatever operation gave you the error. If it's gone, you're done. If not, move to Tier 2.

Tier 2: The 5-Minute Fix — Clear the RPC Stub Cache

If restarting services didn't work, the problem is likely a corrupted stub cache or a bad interface registration. Windows stores these in the registry under HKLM\SOFTWARE\Microsoft\Rpc and HKLM\SYSTEM\CurrentControlSet\Services\RpcSs. A clean reboot doesn't always clear them, so we'll do it manually.

1. Open Regedit as Administrator.
2. Navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Rpc\CachedInterface.
3. If that key exists, export it first (right-click → Export) as a backup, then delete it.
4. Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RpcSs\Parameters.
5. Look for a value named MaxCachedStubs. If it's not there, create a new DWORD (32-bit) and set it to 0 to disable caching entirely. This isn't a permanent fix but it will isolate whether caching is the problem.
6. Restart the RpcSs service again (net stop RpcSs && net start RpcSs).

What we're doing here is forcing the RPC subsystem to rebuild its stub cache from scratch. The MaxCachedStubs=0 trick is a diagnostic — if the error goes away, you know caching was the culprit. You can then either leave it at 0 (safe, minimal performance impact) or investigate which app is registering bad stubs (often a legacy COM+ component).

Tier 3: The 15+ Minute Fix — Repair DCOM Permissions and Re-register Components

If you're still seeing 0x000006F7 after clearing the cache, the problem runs deeper — likely a broken DCOM configuration or a corrupt interface registration from a third-party app. This tier requires care because you're modifying system-level security settings.

Step 3a: Verify DCOM Launch and Access Permissions

Many RPC stubs are actually DCOM calls in disguise. A common cause of bad stub data is a client calling a DCOM interface with permissions that don't match what the server expects.

1. Press Win+R, type dcomcnfg, and hit Enter.
2. In the Component Services window, expand Component Services → Computers → My Computer.
3. Right-click My Computer and choose Properties.
4. Go to the COM Security tab.
5. Under Access Permissions, click Edit Limits. Ensure NETWORK and ANONYMOUS LOGON have Remote Access allowed. If they're missing, add them with Allow checked.
6. Under Launch and Activation Permissions, do the same: allow NETWORK and ANONYMOUS LOGON remote launch and activation.

Why anonymous? Because some RPC calls come from unauthenticated sources (e.g., a remote WMI query from a non-domain machine). If those are blocked, the stub gets garbage data because the authentication handshake fails halfway.

Step 3b: Re-register Corrupted COM Components

If the DCOM permissions look correct, the next suspect is a corrupted COM component that registered a malformed interface. Use DCOMCNFG again, but this time look in the list of DCOM applications for anything with a yellow exclamation mark or an unknown status. Right-click and unregister it, then run regsvr32 /i on the original DLL if you know which app it belongs to.

For broader cleanup, run these commands in an elevated prompt:

regsvr32 /u /s ole32.dll
regsvr32 /s ole32.dll
regsvr32 /u /s rpcrt4.dll
regsvr32 /s rpcrt4.dll
regsvr32 /u /s rpcss.dll
regsvr32 /s rpcss.dll

This re-registers the core RPC and OLE DLLs without a reboot. The /s flag suppresses success messages — only errors will show up.

Step 3c: Check for Third-Party Interference

If you're still stuck, disable third-party services one by one. The biggest offenders are:

• Antivirus with network inspection (e.g., McAfee, Symantec) — they sometimes inject into RPC to scan traffic and corrupt the stub.
• VPN clients (especially OpenVPN-based) — they can route RPC traffic through a tunnel that mangles headers.
• SQL Server — if you're running SQL, check for named pipes or RPC over TCP. A misconfigured SQL Server can register bad stubs for its own RPC interfaces.

Boot into safe mode with networking (msconfig → Boot → Safe boot → Network). If the error disappears in safe mode, start re-enabling services until it comes back. Then you have your culprit.

When to Give Up and Rebuild

If none of these work, the RPC subsystem itself might be corrupted beyond repair (I've seen this after a failed cumulative update on Server 2022). In that case:

• Run SFC and DISM: sfc /scannow then dism /online /cleanup-image /restorehealth. Takes about 15 minutes but can fix system file corruption that manifests as stub errors.
• System Restore: Roll back to a point before the error started. Use rstrui from an admin prompt.
• In-place upgrade: Last resort — download the same Windows version ISO, run setup.exe, and choose 'Keep personal files and apps'. It replaces the RPC binaries without wiping your data.

In 80% of cases, Tier 1 or Tier 2 fixes this. Tier 3 is for the stubborn ones that make you question your career choices.