0X000006B7

RPC_S_NO_PROTSEQS (0x000006B7) — No Protocol Sequences

Server & Cloud Intermediate 👁 1 views 📅 Jun 8, 2026

RPC_S_NO_PROTSEQS means the RPC service can't find any valid protocol sequence to listen on. Usually a corrupt registry or missing RPC port binding.

Quick answer for advanced users: The error means RPCSS can't find any ProtocolSequences entry under HKLM\SOFTWARE\Microsoft\Rpc. Restore the default key or rebuild it with rpcss.exe /regserver and reboot.

Why This Happens

I've seen this exact error on Windows Server 2016, 2019, and even some stubborn Server 2012R2 boxes. The culprit here is almost always a registry key that got nuked by a third-party security tool, a botched system restore, or someone manually cleaning "unused" registry entries. The RPC service reads a list of protocol sequences (like ncacn_ip_tcp for TCP/IP, ncalrpc for local RPC) from the registry when it starts. If that list is empty or missing, RPCSS throws 0x000006B7 and won't serve any remote calls.

Typical scenario: you install a security patch, reboot, and suddenly Get-Service RpcSs shows it running but all DCOM calls fail. Event Viewer logs the error in System log with source RPC. Don't bother reinstalling the RPC service — that rarely works and you'll waste hours.

Fix Steps

  1. Check the registry key. Open regedit and go to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Rpc\ProtocolSequences. If this key is missing entirely, that's your problem. If it exists but has no subkeys, same issue.
  2. Restore default protocol sequences. Right-click the Rpc key (not ProtocolSequences), select Export to back it up. Then download a known-good .reg file from a healthy machine (same OS version) or manually create these subkeys:
    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Rpc\ProtocolSequences
    Default (Default) = (value not set)
    Subkey: ncacn_ip_tcp
      Default = (value not set)
    Subkey: ncalrpc
      Default = (value not set)
    Subkey: ncacn_np
      Default = (value not set)
    Subkey: ncacn_http
      Default = (value not set)
    Note: You can skip ncacn_http if you don't use RPC over HTTP. The first three are mandatory.
  3. Re-register the RPC service. Run Command Prompt as Administrator and type:
    rpcss.exe /regserver
    Wait 10 seconds, then reboot. This rewrites the service's in-memory binding table and re-reads the registry.
  4. Check firewall. After reboot, run netstat -an | find "135" to confirm RPC port mapper is listening on TCP 135. If not, your firewall blocks RPC dynamic ports — but you'd likely see a different error (RPC_S_SERVER_UNAVAILABLE). Still worth ruling out.

Alternative Fixes When Main Steps Fail

  • SFC and DISM. If the registry key keeps disappearing, run sfc /scannow then DISM /Online /Cleanup-Image /RestoreHealth. A corrupted system file might be rewriting the key on boot.
  • Export from another machine. On a healthy server with the same OS version, export the entire HKLM\SOFTWARE\Microsoft\Rpc key, copy the .reg file to the broken server, and merge it. Reboot.
  • Kill third-party security tools. I've seen McAfee and Symantec endpoint protection strip these keys during "system hardening." Temporarily disable them, restore the keys, then add an exclusion.
  • Check for DCOM permissions. If the error persists but only for certain apps, run dcomcnfg, go to Component Services > Computers > My Computer > Properties > COM Security. Under Launch and Activation Permissions, make sure Everyone and INTERACTIVE have local launch rights. This doesn't fix the protocol sequence issue directly, but sometimes the error is misleading.

Prevention Tip

Set up a registry audit on HKLM\SOFTWARE\Microsoft\Rpc using Group Policy or a scheduled PowerShell script that checks for the presence of ProtocolSequences weekly. I use a simple script that emails me if any of the three mandatory subkeys vanish. Also, never run registry cleaners — they cause this exact headache. One more thing: before applying any security "hardening" script, test it on a VM first. You'll thank me later.

Was this solution helpful?