Fix 0X000004C9: Connection Refused on Windows

Quick Answer

Run netsh advfirewall firewall show rule name=all to find the blocking rule, then verify the remote service is running with sc query <servicename>. That covers 80% of cases.

What's Actually Happening Here

Error 0X000004C9 means your Windows machine sent a TCP SYN packet, the remote system received it, but then immediately sent a RST (reset) packet back. That's not a timeout — the remote machine is alive and saw your request, but decided not to complete the handshake. Why? Three common reasons:

1. Firewall blackholing — Windows Firewall or a third-party firewall (Norton, McAfee, corporate VPN clients) has an outbound rule that matches your destination IP or port and drops the connection.
2. Service not listening — The target port has no application bound to it. You're knocking on a door with no one home. Happens when a service like SQL Server, RDP, or IIS crashes or never started.
3. Port conflict on the remote — Another application grabbed the port before the intended service could. This is rarer but I've seen it with Skype hijacking port 443 or a rogue svchost.exe instance.

On Windows 10 22H2 and Windows 11 23H2, I see this most often with RDP (port 3389) after a Windows Update reboot that leaves the TermService in a stopped state, or with SQL Server after a cluster failover where the listener IP moves but the port binding doesn't.

Fix Steps

Step 1: Confirm the Port Isn't Reachable

Don't guess. From the client machine, run:
telnet <remote_ip> <port>
If telnet isn't installed (it isn't by default since Windows 10 1809), enable it via “Turn Windows features on or off” or use PowerShell:
Test-NetConnection -ComputerName <remote_ip> -Port <port>
A successful connection shows TcpTestSucceeded : True. If it's False with RemoteAddress populated, the remote sent a reset — that's 0X000004C9 territory.

Step 2: Check the Remote Service

On the remote machine, open an admin PowerShell and run:
Get-Service | Where-Object { $_.Status -eq 'Running' -and $_.Name -like '*term*' }
For RDP, you're looking for TermService. For SQL Server, it's MSSQLSERVER or a named instance. If the service is stopped, start it:
Start-Service TermService
Also check the service's startup type — if it's Disabled or Manual when it should be Automatic, that's your root cause. Set it with:
Set-Service TermService -StartupType Automatic

Step 3: Review the Windows Firewall

On the remote machine, run:
netsh advfirewall firewall show rule name=all dir=in verbose
Look for rules that explicitly block the port or protocol. Focus on inbound rules — the remote's firewall is what rejects your SYN. If you see something like “Block TCP 3389” from a security policy, that's it. Delete or disable it:
netsh advfirewall firewall delete rule name="Block RDP"
But don't just delete blindly — if it's a corporate policy, talk to your network team. A better approach is to add an allow rule above the block:
netsh advfirewall firewall add rule name="Allow RDP" dir=in action=allow protocol=TCP localport=3389

Step 4: Check for Port Conflicts with netstat

On the remote machine, run:
netstat -ano | findstr :3389
You'll see the process ID (PID) that's listening. Then match it:
tasklist /fi "PID eq 1234"
If the PID belongs to something like svchost.exe for a non-RDP service, or a third-party app, you've got a conflict. You can either stop that application or change the service's port. For RDP, edit the registry at HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp\PortNumber and change it to something else (like 3390).

Alternative Fixes If Steps 1-4 Don't Work

Winsock Reset

On the client machine, open cmd as admin and run:
netsh winsock reset catalog
netsh int ip reset reset.log
Then reboot. This clears any corrupted socket state that could cause the client to send malformed SYN packets. I've seen this fix a weird 0X000004C9 on Windows 10 after a VPN disconnect.

Disable IPv6

If your remote server is on an IPv4-only network but the client prefers IPv6, the connection may hit a v6 endpoint that's not listening. Uncheck IPv6 in the NIC properties (or set netsh interface ipv6 set state disabled). Test again.

Check Third-Party Firewalls

Norton, McAfee, and corporate VPN clients (like Palo Alto GlobalProtect) inject their own filter drivers. Temporarily disable the third-party firewall from its own UI — not just Windows Firewall — and retest. If the error disappears, you found the culprit. Re-enable and create an exception for your target IP:port.

Prevention Tip

Once you've fixed it, set up a scheduled task that runs daily and logs the status of critical services. Use this PowerShell one-liner in the task:
Get-Service TermService,MSSQLSERVER | Export-Csv C:\Logs\service_health.csv -Append
That way, if the service stops again, you'll see it in the log before a user reports the error. Also, document any firewall rule changes in a change log — I can't tell you how many times I've spent hours tracking down a rule someone added “just for testing” and forgot.