RPC_NT_PROTSEQ_NOT_SUPPORTED (0XC0020004) Fix

Quick answer

Run reg add HKLM\SOFTWARE\Microsoft\Rpc /v EnabledState /t REG_DWORD /d 2 /f and restart the RPC services. That forces Windows to load all default protocol sequences.

What's actually happening here

When you see 0xC0020004, the RPC runtime (rpcrt4.dll) tried to bind to a protocol sequence like ncacn_ip_tcp or ncalrpc but couldn't because that sequence isn't registered in the system. This isn't a permission issue—it's a transport layer registration failure. The RPC subsystem maintains an internal table of supported protocol sequences, and if that table gets corrupted or limited (often by group policy or a security product), any RPC call using an unlisted sequence throws this exact code.

I see this most often on Windows Server 2016 and 2019 after a security update or when someone tried to lock down RPC ports. The ncacn_ip_tcp sequence is the usual culprit because it's the default for remote calls. If TCP/IP transport isn't registered, everything from DNS queries to Exchange management fails.

The fix

1. Check which protocol sequences are registered
   Open an elevated PowerShell and run:
   Get-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Rpc' -Name 'ProtocolSequence'
   If this key is missing or empty, that's your problem. Windows only loads sequences listed here.
2. Restore the default protocol sequences
   Run this from an admin command prompt:
   reg add HKLM\SOFTWARE\Microsoft\Rpc /v ProtocolSequence /t REG_MULTI_SZ /d "ncacn_np\0ncalrpc\0ncacn_ip_tcp\0ncacn_spx\0ncacn_dnet_nsp\0ncacn_at_dsp\0ncacn_vns_spp" /f
   The \0 is a null separator—each sequence must be on its own line in the multi-string value.
3. Enable all protocol sequences via the EnabledState
   Still in the same registry key, set:
   reg add HKLM\SOFTWARE\Microsoft\Rpc /v EnabledState /t REG_DWORD /d 2 /f
   Value 2 means "load everything." Value 1 restricts to named pipes only; 0 disables all RPC.
4. Restart the RPC services
   The RPC runtime reads these registry keys at service start. Run:
   net stop RpcSs && net start RpcSs
   Then restart the RPC Endpoint Mapper too: net stop RpcEptMapper && net start RpcEptMapper
5. Verify the fix
   Check the Application Event Log for source RPC with event ID 0. If you see no new 0xC0020004 errors, you're good. Or just run rpcinfo from a remote machine—if it returns endpoints, the transport is alive.

If the main fix doesn't work

Sometimes the registry is fine but something else is blocking. Here's what I'd check next:

• Windows Defender or third-party AV — Some security suites kill the RPC protocol registration. Temporarily disable the real-time protection and repeat the service restart. If the error goes away, add an exclusion for C:\Windows\System32\rpcrt4.dll and the RPC services.
• Corrupt RPC endpoint database — Stop both RPC services, delete the file C:\Windows\System32\RpcEpMap.db, then restart. Windows recreates it on the next RPC call. I've seen this fix a stubborn case where the protocol sequence was registered but the endpoint mapper couldn't initialize.
• Group policy override — Check HKLM\SOFTWARE\Policies\Microsoft\Rpc. If a policy key exists, it overrides the SOFTWARE\Microsoft\Rpc settings. Delete the policy key if you're not in a domain environment, or ask your admin to adjust the RPC policy.

Prevention tip

Don't let anyone muck with the ProtocolSequence registry value manually. If you need to restrict RPC to named pipes only (e.g., for security audits), use the EnabledState value instead—set it to 1 and it'll load only ncacn_np. That way you can't accidentally leave a null separator or misspell ncacn_ip_tcp as ncacn_ip_tcp.

Also, after any Windows update that mentions RPC or networking, run the verification step above. Updates sometimes reset the registry key to a minimal set, and you won't know until something breaks.