RPC_S_UUID_NO_ADDRESS (0x000006CB): Real Fixes That Work

You double-click an app, a service tries to start, or a script calls a COM object over DCOM, and boom: RPC_S_UUID_NO_ADDRESS (0x000006CB). It looks scary. It isn't. The RPC runtime needed a network address — usually a MAC address from an active NIC — to generate a UUID, and it couldn't find one.

I've seen this on freshly imaged servers, on VMs where someone disabled all adapters "for security," and on physical boxes where the NIC driver silently failed after a Windows update. Every time, it comes down to the same handful of causes. Let's go through them in order of how often they actually happen.

Cause 1: No active network adapter (the 80% case)

This is it. Nine times out of ten, the machine has no working NIC, or all adapters are disabled/disconnected. RPC tries to get a MAC address to seed the UUID, finds nothing, and throws 0x000006CB.

How to check

Open an elevated Command Prompt and run:

ipconfig /all

If you see "Media State . . . . . . . . . . . : Media disconnected" on every adapter, or you only see a loopback entry, that's your answer. Loopback doesn't count — RPC can't build a UUID from 127.0.0.1.

Also check Device Manager under Network adapters. A yellow triangle means the driver is broken. Right-click, uninstall, reboot, let Windows reinstall it. On Intel I219-V chipsets especially, the driver bundled with some Windows Server 2019 cumulative updates caused exactly this — reinstalling from Intel's site (version 26.2 or newer) fixed it.

The fix

1. Enable the adapter:

   netsh interface set interface "Ethernet" admin=enable

2. Plug in a cable or connect to Wi-Fi. RPC needs a real MAC.
3. If it's a VM, make sure the virtual NIC is connected in the hypervisor settings — VMware calls this "Connected" and "Connect at power on."
4. Reboot. The RPC service caches adapter state at boot.

That last step matters. I've watched admins enable a NIC, retry the operation, and get the same error — because the RPCSS service was still holding a stale view. A restart clears it.

Cause 2: RPC services not running or dependencies broken

Even with a healthy NIC, if the RPC endpoint mapper or RPCSS service is stopped, you'll hit 0x000006CB. This shows up a lot after someone "optimized" services using a script from a forum post, or after a malware cleanup that disabled services aggressively.

Check the three services

Run services.msc and verify these are Running and set to Automatic:

• Remote Procedure Call (RPC) — RpcSs
• RPC Endpoint Mapper — RpcEptMapper
• DCOM Server Process Launcher — DcomLaunch

Or from the command line:

sc query RpcSs
sc query RpcEptMapper
sc query DcomLaunch

If any show STOPPED, start them with sc start. RpcSs and RpcEptMapper are protected — you can't just disable them through the GUI, which is why broken dependency chains are usually the real culprit. Check the Dependencies tab. If something upstream is disabled, RPC won't initialize even though its own startup type says Automatic.

Restore if tampered with

This is the one time I'll tell you to trust sfc:

sfc /scannow
DISM /Online /Cleanup-Image /RestoreHealth

Yes, it's slow. Yes, it usually does nothing. But if someone deleted or renamed service registry keys under HKLM\SYSTEM\CurrentControlSet\Services\RpcSs, this is the fastest route back to a sane state.

Cause 3: Missing or stale DNS suffix / no IP address bound

Rare, but it bites in specific setups. If the NIC is up but has an APIPA address (169.254.x.x) and no DNS registration, RPC sometimes can't construct the UUID in a domain context. This appears on DHCP-starved networks — think branch offices where the DHCP scope ran dry and 40 machines quietly fell back to link-local addresses.

Symptoms: ping works locally, no internet, and DCOM calls between two machines on the same subnet throw 0x000006CB on one side.

Fix

1. Release and renew:

   ipconfig /release
   ipconfig /renew
   ipconfig /registerdns

2. If you get a 169.254 address again, the DHCP server's out of leases. Expand the scope.
3. For static setups, confirm the subnet mask and gateway are actually correct. A typo in the mask gives you an IP that can't reach anything.

Quick sanity check: can the machine resolve its own FQDN with nslookup %COMPUTERNAME%? If not, that's the layer to fix, not RPC itself.

Cause 4: Hyper-V or container with no virtual switch

Worth a mention because it catches people during lab setups. A Hyper-V VM created without attaching a virtual switch to the vNIC has no MAC available to the guest in some configurations. Same error, different layer. Attach the vNIC to the default switch or an external one, then reboot the guest.

Quick reference

The short version: 0x000006CB is almost always "Windows has no usable network address." Get a real NIC up, restart RPCSS, and it goes away. If it doesn't, you've found a broken driver or service dependency — and now you know exactly where to look.