Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Someone asked this question a few months ago and I have the exact same problem. I have tried all of the suggested solutions in the other posting (in particular reinstalling the video card on the server), but have not had any luck. I have gone through this troubleshooting guide in detail with no results:

I have a client with Remote Desktop enabled that I can't connect to in our local network. When I enter in the machine ip/port in the connect box and hit Connect, it briefly gives the normal "Connecting..." dialog box.

However, after 2 seconds it just drops. No error message, nothing. Just disappears as if nothing was happening.

  • Windows XP SP3
  • Windows firewall is open for 3389TCP
  • Machine is on a domain
  • RDP is enabled in My Computer
  • User is a local admin

I have loads of other machines on the same domain with the same GPO that work fine.

Any ideas?

share|improve this question
Have you checked the logs to see if it's giving a reason for the crash? – Greeblesnort Sep 28 '09 at 20:21
More information about the network (speeds, connection type (wireless? ethernet?), firewalls, etc) would be useful here. Any anti-virus? – Ashley Steel Sep 15 '11 at 8:25
possible duplicate of telnet to 3389 connects, RDP remote desktop app bails? – Skyhawk Oct 14 '11 at 18:15

I was having the same issue. It turned out to be a graphics card driver issue. I've posted a more detailed response here:

telnet to 3389 connects, RDP remote desktop app bails ?

share|improve this answer

Is this a temporary issue or has it continued to fail after a reboot? I've seen things like this on the rare occasion but it's usually temporary. Using Terminal Services Manager you may be able to connect remotely and kill the existing stub session. Often times when that session is logged off or killed it will allow you to log on again. You can also prove the same by trying to log in with a different user.

share|improve this answer

I had similar problems related to time differences between servers, if that's the case, set up ntp sync in the server and clients.

share|improve this answer

I've had something similar happen when the CPU on the server is too busy and the RDP server gets starved of CPU time. There were runaway processes on the server and it took numerous retries to get an RDP login before we could troubleshoot. (The alternative would have been to have a tech go login at the keyboard and manually restart the Win2003 server.)

Once the CPU-hogging processes were killed, the RDP service started responding normally.

share|improve this answer

Similar behaviour can sometimes be seen if there is a problem with Path MTU Discovery, the initial connect succeeds but as soon as larger packets start being sent the connection drops.

Check whether PMTU Discovery is enabled on the faulting machine, also check whether the machine has a hard-set MTU on its primary interface other than the default. It's also worth checking whether there are any routers, switches or VPN tunnels between you and the faulting machine which may force fragmentation.

If you are connected to the same switch as the faulting machine then PMTU Discovery is probably not the problem ... Does the machine show any other network issues?

share|improve this answer

For my case, it was a network problem. When connecting to our office LAN via wifi, some of the network packets were dropped. Each time I tried to RDP to the machine, it would hang at the login prompt. If I ever got to the desktop, the windows were half-way rendered, and nothing happens when I clicked icons or the start menu. When I plugged in the LAN cable, then everything was alright.

So, I would suggest to do a ping and see how's the network connection.

Or it could be a faulty LAN cable on the other machine.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.