Quick answer
The RPC Endpoint Mapper (RpcSs) can't create its database entry under HKLM\SOFTWARE\Microsoft\Rpc — either the key's gone, permissions got stripped, or something is blocking writes. Give NETWORK SERVICE and SYSTEM full control on that key, restart the service, and the error clears.
Why this error shows up
Windows RPC is old infrastructure. It's been around since NT 3.1 and it's held together with registry keys that most admins never touch. When RpcSs starts, it needs to write an endpoint database entry under HKLM\SOFTWARE\Microsoft\Rpc. If that registry path is missing, or the ACLs on it are wrong, the service bails with EPT_NT_CANT_CREATE (0xC002004C) and everything that talks to RPC starts dying.
You'll see this in a few specific situations. A Group Policy Object that rips out the Rpc key as part of a "security hardening" template. A malware scanner or "registry cleaner" that nuked the subkey. A backup restore that dropped registry hives from a different machine. I've also seen it on cloned VMs where the image was sysprepped badly — sysprep wipes certain RPC keys and if it fails halfway, you're left with a half-built tree.
What it looks like on the machine: the RpcSs service hangs on starting. Event Viewer logs Event ID 1006 from source Microsoft-Windows-RPC with the EPT_NT_CANT_CREATE code. Anything DCOM-based stops working — print spooler, WMI, Hyper-V management, SQL Server connections from remote boxes, backup agents. If you try net start rpcss you get Error 1067: The process terminated unexpectedly or Error 1068. Restarting the box doesn't help. That's the signature.
Fix it
-
Confirm the diagnosis in Event Viewer. Open Event Viewer, go to Applications and Services Logs → Microsoft → Windows → RPC → Operational (enable it if it's hidden). You're looking for Event ID 1006 with the EPT_NT_CANT_CREATE text. If you see it, you're in the right place. If you don't, this isn't your error — stop here.
-
Check whether the Rpc key exists. Open Registry Editor as admin and look at:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\RpcIf it's missing entirely, that's your problem. If it's there, right-click it → Permissions and check what's listed.
-
Recreate the key if it's gone. Right-click
Microsoft→ New → Key, name itRpc. Then inside it, create two subkeys:HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Rpc\Internet HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Rpc\ServerYou don't need to populate them with values — RpcSs will do that itself once permissions are right.
-
Fix the permissions. Still on the
Rpckey, right-click → Permissions → Advanced → change owner toAdministratorsif it isn't already, then replace permissions on child objects. Grant these two accounts Full Control:SYSTEMNETWORK SERVICE
If you'd rather script it, the command line version is:
reg add "HKLM\SOFTWARE\Microsoft\Rpc" /f reg add "HKLM\SOFTWARE\Microsoft\Rpc\Internet" /f reg add "HKLM\SOFTWARE\Microsoft\Rpc\Server" /f icacls "HKLM\SOFTWARE\Microsoft\Rpc" /grant "SYSTEM:(F)" /grant "NETWORK SERVICE:(F)" /tNote:
icaclsworks on registry keys but the syntax trips people up. If it complains, usereginior just do it in the GUI. I'm not going to pretend the CLI path is cleaner here — it isn't. -
Restart the RPC service. From an elevated command prompt:
net stop rpcss net start rpcssIf it starts clean, you're done. If it still fails with 1067, reboot. RpcSs has dependencies (DcomLaunch, RpcEptMapper) that don't always release cleanly.
-
Verify. Run
sc query rpcss— should show RUNNING. Then test something that uses RPC, like opening Event Viewer's security log or runningwbemtest. If WMI responds, RPC is healthy.
If that doesn't work
Check for a GPO that's blocking writes. Corporate environments often have a hardening GPO that ACLs the whole HKLM\SOFTWARE\Microsoft path. The fix won't stick because GP re-applies on every refresh. Run gpresult /h gpo.html and look for anything touching the Rpc key. Either exclude the subkey or push a GPO that sets the ACL correctly.
Look at the ServicesPipeTimeout. RpcSs shares a 30-second startup window with other svchost services. If the machine is slow (spinning disk, overloaded CPU), RpcSs times out before it writes the entry. Bump it:
reg add "HKLM\SYSTEM\CurrentControlSet\Control" /v ServicesPipeTimeout /t REG_DWORD /d 180000 /f
Reboot. This is a real fix on older hardware and under-spec'd VMs, but don't use it as a band-aid if the ACLs are the actual problem.
Restore the registry hive. If the Rpc key and its neighbors under Microsoft are chewed up (this happens after a bad system restore), pull a fresh SOFTWARE hive from a working machine of the same Windows build. Mount it via reg load, but be careful — copying hives between builds breaks other stuff. Last resort only.
Scan for malware. Some older rootkits modify RPC-related keys to hide themselves. Run a full scan with an offline bootable scanner (Defender Offline, Kaspersky Rescue Disk). If you find anything, the registry damage is a symptom, not the cause.
Prevent it next time
Export the HKLM\SOFTWARE\Microsoft\Rpc key the next time a machine is healthy:
reg export "HKLM\SOFTWARE\Microsoft\Rpc" C:\Backup\rpc-key.reg /y
Keep it with your other build artifacts. When this error shows up at 2 AM on a Friday, double-clicking that .reg file and rebooting gets you back in five minutes instead of an hour of Event Viewer archaeology. I've watched a client's entire print queue and their backup agent die because a "registry optimization" tool removed that key — one .reg file would've saved them a half-day of downtime.