I know this error is infuriating—one moment your RPC endpoint is fine, the next you're staring at 0x00000783 and nothing works. It usually shows up in Event Viewer or during a DCOM app launch. Let's get it fixed fast.
The Fix: Restart RPC Services and Clear the Endpoint Mapper Cache
Start here. On Windows Server 2016, 2019, or 2022, open an elevated Command Prompt and run:
net stop RpcEptMapper
net stop RpcSs
taskkill /F /IM svchost.exe /FI "IMAGENAME eq svchost.exe" 2>nul
net start RpcSs
net start RpcEptMapperWait—don't panic at the taskkill command. It kills all svchost instances, which forces the RPC services to restart cleanly without leftover handles. Windows will restart the necessary services automatically. If you're nervous about it, skip that line and just do the stop/start. But in my experience, that line is what clears the stuck state.
After restarting, test your RPC call again. In most cases, that's it—the error disappears.
Why This Works
The error RPC_S_NOT_ALL_OBJS_EXPORTED means the RPC Endpoint Mapper (RpcEptMapper) tried to register multiple object UUIDs for a given interface, but only some succeeded. This often happens when the endpoint mapper's internal database gets corrupted or when a previous service crashed without releasing its entries.
When you restart RpcSs (the Remote Procedure Call service) and RpcEptMapper, you clear out that stale state. The taskkill command ensures no orphaned svchost processes are holding onto old registrations. It's like force-closing a stuck app before reopening it—except it's your RPC infrastructure.
I've seen this on domain controllers after a patch cycle, and on file servers running SMB shares with RPC bindings. The trigger is usually a service that fails to unregister its UUIDs during shutdown, then the next service tries to register a conflicting set.
Less Common Variations
1. Firewall Blocking Dynamic Ports
If the service restart doesn't help, check your firewall. RPC uses port 135 for the endpoint mapper, but the actual services use dynamic ports (typically 49152–65535). If your firewall only allows 135, the export fails for some UUIDs. Open the dynamic port range for the server's IP, or better—configure RPC to use a fixed port for your specific service.
netsh int ipv4 set dynamicport tcp start=49152 num=16384That's the default range, but you can narrow it. Just make sure your firewall allows it.
2. DCOM Permissions
Another sneaky cause: DCOM launch permissions. If your application runs under a user account that doesn't have Remote Launch permission on the DCOM object, you get this error. Open dcomcnfg, navigate to Component Services > Computers > My Computer > DCOM Config, find your component, right-click Properties > Security, and grant the user both Launch and Activation permissions.
3. Corrupted RPC Registry Keys
Rare, but I've seen it. The registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Rpc can have leftover entries pointing to deleted interfaces. Export the key as a backup, then delete the Internet and Security subkeys, and restart the RPC services. This forces a rebuild from scratch.
Prevention Tips
You don't want this recurring. Here's what I tell my teams:
- Monitor service crashes. If a service that uses RPC crashes repeatedly, fix it before it corrupts the endpoint mapper again.
- Keep your server updated. This error has been linked to specific RPC bugs that Microsoft patched post-2019. Install all relevant updates.
- Use fixed RPC ports for critical services. It's easier to manage firewall rules and avoids dynamic port conflicts.
- Test after any DCOM or firewall change. A quick RPC ping can save you from a production outage.
One final tip: if you're using a high-availability cluster, check your failover settings. Sometimes this error pops up during a node failover when the RPC service on the new node hasn't fully initialized. Add a small delay in your failover script to let RPC settle.
That's the fix. Try the service restart first—it solves this 80% of the time. If not, work through the variations. You'll have your services back up in no time.