Fix RPC_NT_NO_PROTSEQS_REGISTERED 0xC002000F on Windows Server

You're staring at Event Viewer or a failing app and it spits out RPC_NT_NO_PROTSEQS_REGISTERED (0xC002000F). Translated from NTSTATUS, that means the RPC runtime came up but couldn't find a single registered protocol sequence. TCP, named pipes, ALPC — nothing. Without at least one protocol sequence registered, RPC can't open a binding handle, so every DCOM call, every WMI query, and every remote service check dies on arrival.

I've seen this on Server 2012 R2 through Server 2022, and in every case it traces back to the same handful of culprits. Here's the order I check them in.

Cause 1: The RpcSs service (Remote Procedure Call) isn't running or is stuck starting

This is the one that bites 8 out of 10 admins. RpcSs is the service that registers protocol sequences on boot. If it's stopped, disabled, or hung in a Starting state, nothing downstream works. The trigger I see most often: someone hardened a server by disabling "unnecessary" services, or an imaging script flipped RpcSs to Manual and it never came back.

Open an elevated PowerShell and check:

Get-Service RpcSs, RpcEptMapper, DcomLaunch | Format-Table Name, Status, StartType

You should see all three as Running with StartType Automatic. If RpcSs shows Stopped, try starting it by hand:

Start-Service RpcSs

After that command completes, run Get-Service RpcSs again. You should see Status: Running. If it fails with error 1053 (service didn't respond in time) or 1067 (process terminated unexpectedly), jump to Cause 2, because that's usually a dependency problem, not a corrupt binary.

If the StartType is wrong, set it back:

Set-Service RpcSs -StartupType Automatic
Set-Service RpcEptMapper -StartupType Automatic
Set-Service DcomLaunch -StartupType Automatic

Then reboot. Don't just restart the service — a full reboot lets the service control manager re-evaluate the dependency chain, and that's what actually fixes the stuck-starting cases.

RpcSs depends on DcomLaunch and RpcEptMapper. If either of those is disabled, RpcSs won't start no matter how many times you click Start. Check the Dependencies tab in services.msc before you waste an hour.

Cause 2: The RPC protocol sequence registry keys are missing or damaged

The RPC runtime reads its list of protocol sequences from the registry at boot. The key lives here:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Rpc\ProtocolSequences

You should see entries like ncacn_ip_tcp, ncacn_np, ncacn_http, ncalrpc. If that key is empty, gone, or has a stray space in a value name, RPC has nothing to register and hands you 0xC002000F.

How does it get damaged? A bad driver install that writes to the wrong hive. A half-finished Windows Update. Malware cleanup that nuked registry entries it thought were suspicious. I've also seen backup-restore tools overwrite the SOFTWARE hive with an older copy that predates a Windows feature update.

Check what's registered:

reg query "HKLM\SOFTWARE\Microsoft\Rpc\ProtocolSequences"

If you get "ERROR: The system was unable to find the specified registry key or value," the key has been deleted. On a healthy Server 2019/2022 box you'd expect output listing ncacn_ip_tcp, ncacn_np, ncalrpc, ncacn_http, and a few others, each with an Endpoint value and an Internet value.

The fix: copy the key from a working server running the same Windows build. Don't hand-craft it from a blog post — the binary values inside (Internet, Endpoint) are build-specific and a wrong value will make RPC fail differently. Export from the good box:

reg export "HKLM\SOFTWARE\Microsoft\Rpc\ProtocolSequences" C:\temp\rpcproto.reg

Then import on the broken server:

reg import C:\temp\rpcproto.reg

After the import, close the Registry Editor and reboot. You should see the key present with all subkeys when you re-run the reg query. If RPC still won't start, run sfc /scannow — the runtime DLLs (rpcrt4.dll, rpcss.dll) may also be damaged.

Cause 3: Winsock catalog corruption is breaking the TCP protocol sequence

RPC registers ncacn_ip_tcp through Winsock. If the Winsock catalog is corrupted — usually after an LSP (Layered Service Provider) from a security agent or VPN client was uninstalled uncleanly — RPC tries to register the TCP sequence, fails silently, and you get 0xC002000F even though the registry key looks fine.

The real-world trigger I see most: uninstalling an old third-party firewall and rebooting. The catalog still has orphaned LSP entries pointing to a DLL that no longer exists. RPC's TCP registration dies on that.

Check the catalog:

netsh winsock show catalog

Scan for entries under "Winsock Catalog Provider Entry" that reference DLLs you don't recognize, or paths to files that no longer exist. Warning signs: a path under C:\Program Files\OldVendor\ that returns "file not found" when you check it.

The fix is a Winsock reset. It's not pretty — it clears every non-Microsoft LSP — but it's the correct fix when the catalog is genuinely corrupted. Before you run it, note which third-party network tools are installed (VPN clients, endpoint protection, WAN accelerators) because you'll need to reinstall them.

netsh winsock reset catalog
netsh int ip reset reset.log
shutdown /r /t 0

After the reboot you should be able to run net start rpcss and see it come up clean. Also test with a quick DCOM ping:

Get-WmiObject Win32_OperatingSystem | Select-Object Caption, Version

If that returns a result without error, RPC's TCP sequence is registered and working.

Quick-reference summary

One last thing: if all three checks pass and you still see 0xC002000F, run sfc /scannow and then DISM /Online /Cleanup-Image /RestoreHealth. Corrupted rpcrt4.dll throws the same error code and hides behind all the other symptoms. Don't skip that step just because it takes 20 minutes — I've watched two teams rebuild servers that only needed a DISM repair.