Remote Desktop error 0x204: we couldn’t connect to the remote PC

Fix it now

The client reached the end of its attempt without a Remote Desktop listener answering. Microsoft publishes no meaning for the codes the client prints here, so treat them as a prompt rather than a diagnosis, and start with the one cause no configuration can fix: Microsoft states that Windows Home editions cannot serve as Remote Desktop hosts, although they can be used as clients.

Get-ComputerInfo -Property WindowsProductName
Get-Service TermService
netstat -ano | findstr :3389
Get-NetConnectionProfile

1. If the edition comes back as Home, stop. Microsoft states Remote Desktop can connect to Windows Professional, Enterprise and Education editions and to Windows Server editions, and that Home cannot host. No registry value adds the host side.
2. On a Pro, Enterprise or Education host, turn it on: Start, Settings, System, then Remote Desktop, and switch Enable Remote Desktop on, confirming the prompt.
3. Check the listener. TermService should be running and the netstat line should return a listening entry on 3389. A running service with nothing listening is a different problem from a stopped one.
4. Note which profile the adapter is on, then enable the Remote Desktop inbound rules in Windows Defender Firewall with Advanced Security for that profile. A rule enabled for Domain does nothing on an adapter classified as Public.
5. From the client, run Test-NetConnection hostname -Port 3389. False means the path or the firewall, not your credentials.

Confirm the name you typed resolves to the host you mean. Resolve-DnsName hostname on the client against ipconfig on the host settles it, and a stale record is a common cause of a perfectly healthy host being unreachable.

If you reach the desktop you are done. If not, the next section covers everything that has to be true before a session can start.

Why it happens

Remote Desktop is not a feature either end can decide to offer. The host runs a service that listens on TCP 3389 and, where enabled, UDP 3389 alongside it. That listener exists only in editions licensed to host sessions. Microsoft’s own wording is that you can use Remote Desktop to connect to computers running Windows Professional, Enterprise and Education editions and Windows Server editions, and that Windows Home editions cannot serve as Remote Desktop hosts although they can be used as clients.

Assuming the host can listen, four more things have to line up: the service is running, the firewall permits the connection on the profile the adapter is currently using, the machine is awake, and the name you typed resolves to its current address. A laptop that has moved to a new network, taken a new address and been reclassified as a Public connection fails the last three at once, which is why this error so often follows a machine being moved rather than anything being changed.

Be careful with the numbers themselves. Microsoft does not publish meanings for the codes the Remote Desktop client prints when a connection fails, and none of them appears in the protocol specification’s error table either. They are worth recording in a ticket because they distinguish one failure from another, and they are not worth reasoning from. Every step here is a test of something you can observe rather than an inference from the digits.

Full reference

What is and is not published about these codes

This is worth stating plainly because there are a great many pages that will tell you exactly what each of these means. They are guessing, and the guesses tend to be built backwards from whatever fixed one person’s problem. Record the code so you can tell two tickets apart, and diagnose from the host.

What has to be true on the host

Work down that table rather than around it. Six of the seven are one command, and the order matters: there is no point testing a port on a machine whose edition cannot listen, and no point resolving a name for a host that is asleep.

Reaching a host from outside the network

Reach the host through a VPN or a Remote Desktop Gateway. Both put the authentication somewhere designed for it and keep the listener off the public internet.

Do not forward port 3389 from your router to work around this. An exposed Remote Desktop listener is found by automated scanning within hours, and it will appear to work perfectly while that happens.

One session or several

A client edition that can host serves the desktop to one person at a time, which is what somebody connecting to their own machine needs. Where several people must each have their own session on the same machine, that is Remote Desktop Services on Windows Server with the appropriate client access licences, and it is a different design rather than a setting. Products that claim to add multiple sessions to a client edition do it by modifying system files, which is unsupported and breaks at the next feature update.

When the host checks out and it still will not connect

• Test from a second client on the same network, to separate the client from the path.
• Check whether an endpoint security product on the host is blocking the port locally. Its own logs will say so and the Windows firewall will look correct.
• Check whether the host has a second adapter that the name resolves to, which is common on machines with a virtualisation stack installed.
• Try connecting by address rather than by name once, purely to split name resolution from reachability.
• Check the host’s own Remote Desktop connection logs in Event Viewer, under Applications and Services Logs, Microsoft, Windows, TerminalServices-RemoteConnectionManager, Operational.

Every code this article covers

Confirm the fix worked

1. Run Test-NetConnection hostname -Port 3389 from the client and confirm it returns True.
2. Connect and confirm you reach the desktop, not only the credential prompt.
3. On the host, confirm netstat -ano | findstr :3389 shows a listening entry after a reboot.
4. Check the host’s TerminalServices-RemoteConnectionManager Operational log for the successful connection.
5. Reboot the host, let it settle, and confirm the connection still works without anyone logging on locally first.

Questions people ask about this