Fix RPC_NT_NO_PROTSEQS 0xC0020014: Protocol Sequences Missing

RPC_NT_NO_PROTSEQS means the RPC runtime has no protocol sequences. Usually caused by disabled RPC services or misconfigured registry. Restart services, check RPC config.

Quick answer

For the impatient: restart the Remote Procedure Call (RPC) and DCOM Server Process Launcher services, then retry. If that fails, check the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Rpc\ServerProtocols registry key for the presence of ncacn_np.

Why this happens

The error 0xC0020014, RPC_NT_NO_PROTSEQS, is the RPC runtime's way of saying "I've got no protocol sequences to listen on." In plain terms, the RPC subsystem has no transport (like named pipes or TCP) configured to accept incoming calls. This usually shows up when a COM/DCOM client tries to connect to a server component, and the server side can't even start listening. It's common in distributed apps, SQL Server linked servers, or any custom COM object exposed remotely.

The culprit here is almost always one of two things: either the RPC-related services didn't start (maybe a delayed boot or a service dependency failure), or the RPC configuration got clobbered — often after a bad uninstall, a registry cleaner that got too aggressive, or a security policy that disabled named pipes. Don't bother checking Windows Firewall first; if the RPC stack isn't listening, firewall rules are irrelevant.

Fix steps

Verify and restart RPC services. Open an elevated PowerShell or Command Prompt and run:
```
sc query RpcSs
sc query DcomLaunch
sc query RpcEptMapper
```
If any show STOPPED, start them:
```
sc start RpcSs
sc start DcomLaunch
sc start RpcEptMapper
```
For good measure, restart them anyway: net stop RpcSs && net start RpcSs (this also restarts DcomLaunch as a dependency).
Check the protocol sequences registry key. Open regedit and go to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Rpc\ServerProtocols. You should see at least ncacn_np and usually ncacn_ip_tcp. If the key is missing or empty, that's your problem. Create a new DWORD value named ncacn_np with value 1, and also ncacn_ip_tcp with value 1 if you need TCP. Reboot or restart RpcSs after the change.
Re-register RPC runtime components. Sometimes the DLLs get unregistered. Run these from an elevated command prompt:
```
regsvr32 /s rpcrt4.dll
regsvr32 /s rpcss.dll
dcomcnfg
```
The last command opens the Component Services console—just close it after it loads, that's enough to reinitialize the RPC configuration.
Check the RPC Endpoint Mapper. In the ServerProtocols key, also ensure ncacn_np is set to listen on the endpoint mapper. Run netstat -an | findstr 135 to confirm port 135 is listening. If not, your RPC Endpoint Mapper may be bound to the wrong interface. That's rare, but a misconfigured HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Rpc\Internet key can mess that up. Delete that key if it exists and reboot.
If all else fails, pull the registry from a known-good machine. Export the HKLM\SOFTWARE\Microsoft\Rpc key from a healthy Windows box (same OS version), then compare. You can import it if you're confident, but back up the current one first.

Alternative fixes if the main steps don't work

Sometimes the standard fix doesn't stick, especially if you're dealing with a domain-joined machine that has a restrictive Group Policy. Look for Network access: Named Pipes settings in secpol.msc or gpedit.msc. If named pipes are denied for the service account, RPC will fail exactly like this.

Also check that the Remote Procedure Call (RPC) service's logon account is NT AUTHORITY\NetworkService. If someone changed it to a local user, the service may start but won't have the right to create endpoints. Open services.msc, right-click RpcSs → Properties → Log On, and verify.

Another angle: if this happens on a SQL Server or Exchange server, you might have a corrupted msdtc (Distributed Transaction Coordinator) configuration. That can interfere with RPC's protocol sequence setup. Reinitializing MSDTC with msdtc -uninstall and msdtc -install is worth a shot—I've seen it clear up weird RPC errors.

Prevention tips

Once you've fixed it, don't let it come back. Keep these in mind:

Never use third-party registry cleaners on servers. They don't understand RPC internals and will strip out protocol sequences like a bad haircut.
If you're running security hardening scripts, review them for anything that disables RPC or deletes registry keys under HKLM\SOFTWARE\Microsoft\Rpc. It's tempting to lock down everything, but RPC needs those keys.
Monitor the RPC service status. Set up a simple scheduled task that checks sc query RpcSs every 5 minutes and logs a warning if it's down. Good for catching early failures.

The bottom line: 0xC0020014 is a configuration failure, not a hardware fault. You can get it back up in minutes if you know where to look. Start with the services, then the registry, and you'll beat it.