What's actually happening here
When you see RPC_NT_PROTSEQ_NOT_FOUND (0XC002002D), the RPC runtime can't locate the protocol sequence string you passed to it — usually something like ncacn_np or ncacn_ip_tcp. The error isn't about the network being down; it's about the RPC endpoint mapper not having the protocol registered on the local machine.
I've seen this mostly on Windows Server 2016 and 2019 after a failed update, or when someone disabled the Server service (LanmanServer) to "harden" the box. The named pipes protocol sequence (ncacn_np) lives on that service. Kill it and RPC calls that expect named pipes break with this exact code.
Another common trigger: a custom application or script hardcodes ncacn_np but the target machine only has TCP/IP registered. You'd think the RPC mapper would fall back — it doesn't. Each protocol sequence must be explicitly registered in the registry.
Here's the fix path. Try them in order, and stop as soon as the error disappears.
Fix 1: Quick check (30 seconds) — Is the Server service running?
Open an elevated PowerShell and run:
Get-Service LanmanServer | Select-Object Status, StartTypeIf the status is Stopped, start it and set it to automatic:
Set-Service LanmanServer -StartupType Automatic
Start-Service LanmanServerThen retry your RPC call. The reason this works: the ncacn_np protocol sequence is implemented by the SMB named pipe listener, which the LanmanServer service hosts. No service, no pipe, no protocol.
If it's already running, move to Fix 2.
Fix 2: Verify the protocol sequence registry entry (5 minutes)
RPC protocol sequences are registered under this key:
HKLM\SOFTWARE\Microsoft\Rpc\ServerProtocolsOpen regedit and navigate there. You should see values like ncacn_np, ncacn_ip_tcp, and ncacn_http. Each is a REG_SZ with a value of 1.
If ncacn_np is missing, add it:
- Right-click ServerProtocols → New → String Value.
- Name it
ncacn_np. - Set the value to
1.
Then reboot the machine (or restart the RPC service — but beware, restarting RPCSS affects a lot more than you'd think). A reboot is safer and faster.
I've also seen the value accidentally set to 0 by a third-party security tool. Make sure it's exactly 1.
Fix 3: Rebuild the RPC configuration (15+ minutes)
If the registry key looks fine and services are running, the problem is deeper — likely a corrupted RPC configuration or a missing dependency. Here's the longer path.
Step 1: Reset the RPC service dependencies
Open an elevated command prompt and run:
sc config RpcSs start= auto
sc config RpcSs depend= DcomLaunch
sc config DcomLaunch start= autoThen restart:
net stop RpcSs /y
net start RpcSsThe /y forces dependent services to stop too. What's actually happening here is that RPCSS depends on DcomLaunch, and if that dependency chain broke (common after a bad uninstall), the RPC runtime never initializes its protocol sequences.
Step 2: Check and repair the ProtocolSequences value in RpcSs
Under HKLM\SYSTEM\CurrentControlSet\Services\RpcSs, look for a value called ProtocolSequences (type REG_MULTI_SZ). It should contain:
ncacn_np
ncacn_ip_tcp
ncacn_httpIf it's empty or missing, create it as a multi-string value and add those three lines (without quotes). Reboot afterward.
Step 3: Re-register the RPC runtime DLLs
This step is my go-to when nothing else works. Run these from an elevated cmd:
regsvr32 \windows\system32\rpcrt4.dll
regsvr32 \windows\system32\rpcss.dllYou'll get a success popup — don't ignore it. Then reboot. These DLLs are the core of the RPC runtime. Re-registering them rewrites the COM class registration and protocol sequence bindings. I've fixed a stubborn Windows 2019 box this way after a security tool overwrote the DLLs.
Step 4: If the error comes from a specific application
Sometimes the application passes a protocol sequence that was never registered. Check the app's config or code — look for the protocol sequence string. If it says ncacn_np, but the app runs on a client that only connects via TCP, you can often force TCP by changing the endpoint to ncacn_ip_tcp on the client side. The server doesn't care which protocol the client uses as long as the server has it registered.
I've also seen this when an app runs under a service account that doesn't have network logon rights. The RPC call succeeds locally but fails remotely with 0XC002002D because the protocol sequence isn't available over the network for that identity. Fix: grant the service account "Access this computer from the network" in Local Security Policy.
Why you shouldn't just ignore it
Leaving this unresolved means more than one app breaks. RPC underlies DCOM, WMI, and a good chunk of Windows management tools. You'll start seeing secondary failures in Event ID 7036 (service control manager) and random "RPC server unavailable" errors that blame the network when the problem is local.
The quick fixes take seconds. Try them first. Only if you're still stuck do you need the registry surgery in Fix 3.