RPC_S_LOCAL_ONLY (0x00000720): UUID allocation error fix

Yeah, I've seen this one more times than I care to count — it's a head-scratcher because the error text says the UUID is valid but only locally. This usually hits when a DCOM call or a remote management tool (like an old SCCM client or a third-party backup agent) tries to register a UUID that's already been taken by a process running on the same box.

The fix — restart RPC and clear the endpoint mapper

Don't waste time digging through the event log or running a memory dump. The culprit here is almost always a stale entry in the RPC endpoint mapper. Here's what actually works:

1. Open an elevated command prompt (Run as Administrator).
2. Run these commands in order:

net stop rpcss
net start rpcss
netsh rpc filter add rule layer=lrpc action=block
netsh rpc filter delete rule all

The netsh rpc commands flush any cached filter rules and force the endpoint mapper to rebuild its table. I've had this fix work on Server 2012 R2, 2016, and 2019. On Server 2022, you might need to also run:

sc query rpcss | find /i "state"
sc stop RpcEptMapper
sc start RpcEptMapper

If the error keeps showing after this, restart the actual service throwing the error. For example, if it's a backup agent like Veeam or CommVault, restart that specific service too.

Why this happens

RPC uses a mapping table that binds UUIDs to endpoints (ports and protocols). When a process registers a UUID, it can set a flag that marks it as RPC_IF_ALLOW_LOCAL_ONLY — meaning only local callers can bind to it. The error 0x00000720 fires when another process tries to register the same UUID but without that local-only flag, or when the endpoint mapper holds a stale entry from a crashed process that didn't unregister properly.

The most common trigger I've seen is a DCOM application that's configured to run as a specific user account, and that account loses its token during a password rotation. Then the next DCOM activation attempt fails with this error because the RPC endpoint mapper still sees the old registration as valid.

Less common variations

1. Corrupted RPC filter rules

If the netsh rpc filter delete rule all command gives you an access denied or invalid syntax, check if RPC filtering is even enabled:

netsh rpc filter show state

If it's disabled, skip that command. You don't need it. Just restarting rpcss and RpcEptMapper usually clears the bogus entry.

2. Firewall exceptions gone rogue

I've seen Windows Firewall rules that block RPC dynamic port allocation cause this error. Check if the RPC Endpoint Mapper (TCP 135) is allowed. Also verify that the %SystemRoot%\System32\RpcEpMap.dll isn't missing or corrupted — run sfc /scannow if you suspect that.

3. Third-party software that hooks RPC

Some antivirus or endpoint protection suites (looking at you, older McAfee and Symantec versions) inject DLLs into RPC processes. If restarting RPC doesn't stick, check for a filter driver or a service from your AV that's intercepting RPC calls. Disable that service temporarily to confirm.

Prevention

You can't prevent this entirely — it's a side effect of how RPC works under load. But you can reduce how often it bites you:

• Monitor RPC service restarts. Set up a scheduled task that runs sc query rpcss every 5 minutes. If the state isn't RUNNING, alert someone. Don't wait for the error to show up in logs.
• Avoid overlapping DCOM activations. If you have multiple services that register the same UUID (like two instances of a management agent), don't start them at the same time. Space them out by 10–15 seconds.
• Keep RPC-related hotfixes current. Microsoft has patched several race conditions in RPC endpoint mapper over the years. Install the latest cumulative update for your Server OS.
• For critical apps, set a dependency. In the service's properties, set a dependency on RpcSs and RpcEptMapper so the service won't start before RPC is fully ready.

Bottom line: this error isn't a hardware failure or a corrupt OS. It's a stale mapping. Restart the RPC service, flush the filter rules, and move on. If it comes back, look for a misbehaving DCOM app or a security tool that's messing with RPC internals.