Fix STATUS_REMOTE_NOT_LISTENING (0XC00000BC) Error

Quick answer: The remote computer isn't listening on the required port (usually TCP 135 for RPC). Check the Remote Procedure Call (RPC) service is running on the remote machine, then verify Windows Firewall allows inbound RPC traffic.

What's going on here?

You're seeing 0XC00000BC — STATUS_REMOTE_NOT_LISTENING when trying to connect to a remote Windows machine from another box. I've seen this mostly with administrative tools like Computer Management, Event Viewer, or custom scripts that rely on RPC or DCOM. The remote machine is alive (it's not a timeout or unreachable), but it's not answering on the specific port your tool expects. The culprit here is almost always a stopped RPC service or a firewall blocking inbound connections on TCP port 135.

Fix steps — do these in order

Check the RPC service on the remote machine. This is step one every time. On the remote computer, open Services.msc and look for Remote Procedure Call (RPC). It should be Running and set to Automatic. If it's stopped, start it. If it's not set to Automatic, change it, then reboot. I've seen a third-party uninstaller kill this service once — took me an hour to figure out.
Verify Windows Firewall. On the remote machine, go to Windows Defender Firewall > Advanced Settings > Inbound Rules. Look for rules named Remote Service Management or Remote Event Log Management. Make sure they're enabled. If you want a direct test, temporarily disable the firewall entirely on the remote box (do this only in a controlled environment). If the error goes away, you know it's firewall rules.
Port check from the local machine. Open Command Prompt and run:
```
Test-NetConnection -ComputerName REMOTE_IP -Port 135
```
Replace REMOTE_IP with the actual IP. If it returns TcpTestSucceeded : False, the remote machine isn't listening on that port. Could be a service issue, a firewall block, or something else entirely.
Enable RPC endpoint mapper in the firewall. Sometimes the default rules aren't enough. Create a new inbound rule allowing TCP port 135 from the local subnet. Make sure it's enabled for Domain and Private profiles. Don't bother with UDP 135 — rare that it helps here.
Check DCOM settings. Run dcomcnfg on the remote machine. Go to Component Services > Computers > My Computer > Properties. On the Default Properties tab, make sure Enable Distributed COM on this computer is checked. Also set Default Authentication Level to Connect and Default Impersonation Level to Identify. Reboot after changes.

Alternative fixes if the main steps don't work

If you've done all the above and still get the error, try these:

Check for third-party firewalls. Norton, McAfee, or even some VPN clients can block RPC ports even when Windows Firewall looks fine. Uninstall them temporarily to test.
Network profile issue. If the remote machine sees the network as Public instead of Private or Domain, Windows Firewall might block RPC by default. Change the network profile to Private via Settings > Network & Internet > Wi-Fi/Ethernet > click the network name and set to Private.
Restart the RPC Locator service. Not always needed, but I've seen it fix weird edge cases. Run services.msc, find Remote Procedure Call (RPC) Locator, set it to Manual, start it. Doesn't hurt.
WMI issue? If the tool uses WMI (like Computer Management does), also check that the Windows Management Instrumentation service is running and the firewall has the Windows Management Instrumentation (WMI) inbound rule enabled.

Prevention tips for next time

Don't let this bite you again. On any Windows machine that needs remote admin, do this upfront:

Set the RPC service to Automatic and test it after every major Windows update (updates sometimes reset service startup types).
Create a Group Policy Object or PowerShell script that enables the necessary firewall rules for RPC and WMI on domain-joined machines. One less thing to chase.
Document the IP and hostname of every machine you manage. Sounds stupid, but I've seen people mix up IPs and waste hours on the wrong box.

Real scenario: A client once had this error because their IT guy added a firewall rule blocking TCP 135 "for security" without testing. The rule was from a security template that wasn't meant for internal servers. Always test after changes.

If you're still stuck after all this, run netsh advfirewall show allprofiles state on the remote machine and check if any profiles are set to block inbound. Also confirm the remote machine's local firewall isn't being overridden by a domain policy — run gpresult /h report.html and look for firewall policies.