Windows Explored

Everyday Windows Desktop Support, Advanced Troubleshooting & Other OS Tidbits

When RDP “Disconnects”, It Might Be Crashing

Posted by William Diaz on June 18, 2012

It was reported by a local office technician that over the course of a few days several users were connecting to a site over the web that used Remote Desktop Connection to connect a remote desktop/terminal services session. Shortly after connecting, users complained the their session was being disconnected. The issue was initially troubleshot as possibly a local setting in the OS, such as the IE proxy or maybe the TMG firewall client, but switching to different proxy made no difference. It was then assumed that perhaps our network work was part of the problem. Port issue? Not likely, ports 443 and 3389 are too common and since the users were able to connect initially, this could be eliminated as the cause. Last, the remote site technical support was contacted and asked at what point inactive sessions were being dropped. The answer to that was 1 hour and so this, too, was eliminated as the cause.

Eventually, the issue made it my way, and the first thing I thought was that this was not specifically a “disconnect”. When I think disconnect, I’m thinking along the lines of excessive packet loss or corruption between the client and the server which results in a dropped connection. Another cause for a disconnected application could be that the client app or one of its components that handles the connection is crashing. To confirm my suspicion, I asked the local tech to provide me the name of one of the affected workstations. All the affected workstation were running Windows XP, which meant that if the RDP client was crashing, the post mortem debugger might be capturing this. I navigated across the network to \\computername\c$\Documents and Settings\All Users\Application Data\Microsoft\Dr Watson and saw a recent drwtsn32.log and user dump.


I love Dr Watson because it makes basic crash analysis so easy. Bypassing the dump, you can just jump into the plain text log. The log contains a history of application crashes that the it has captured over the course of the operating system’s install-lifetime experienced in any user account. This makes it an excellent troubleshooting tool for going back into time (the user.dmp is overwritten each time it is generated). Scrolling to the bottom of the log and searching up for the last application crash confirms the RDP client, mstsc.exe, was encountering an access violation exception:

Application exception occurred:
        App: C:\WINDOWS\system32\mstsc.exe (pid=4928)
        When: 6/4/2012 @ 21:07:39.607
        Exception number: c0000005 (access violation)


The next step is to find the thread stack where the FAULT is occurring, perhaps some 3rd party module might allude to the cause:

FAULT ->77c46fa3 f3a5            rep  movsd ds:0221e000=???????? es:021acdac=00000000
        77c46fa5 ff2495b870c477  jmp dword ptr [msvcrt!memcpy+0x148 (77c470b8)+edx*4]
        77c46fac 8bc7             mov     eax,edi
        77c46fae ba03000000       mov     edx,0x3
        77c46fb3 83e904           sub     ecx,0x4
        77c46fb6 720c             jb      msvcrt!memcpy+0x54 (77c46fc4)
        77c46fb8 83e003           and     eax,0x3
        77c46fbb 03c8             add     ecx,eax
        77c46fbd ff2485d06fc477   jmp dword ptr [msvcrt!memcpy+0x60 (77c46fd0)+eax*4]
        77c46fc4 ff248dc870c477  jmp dword ptr [msvcrt!memcpy+0x158 (77c470c8)+ecx*4]
        77c46fcb 90               nop

*—-> Stack Back Trace <—-*
WARNING: Stack unwind information not available. Following frames may be wrong.
ChildEBP RetAddr  Args to Child             
0305fe20 4d8820ef 021aa1ac 0221b400 0000ff80 msvcrt!memcpy+0x33
0305fe40 4d881b4c 0221b400 0000ff80 0305fe70 mstscax+0x1720ef
0305fe50 4d879913 02094338 0221b400 0000ff80 mstscax+0x171b4c
0305fe70 4d87c4d6 02094338 021f7d88 00000014 mstscax+0x169913
0305fe9c 4d87d3d4 02094338 00000000 02094338 mstscax+0x16c4d6
0305feb0 4d87a7f1 02094a28 02094338 00000101 mstscax+0x16d3d4
0305fef4 4d881e11 02094a28 02094338 00000000 mstscax+0x16a7f1
0305ff14 4d881399 02095ad0 021a9584 01ea7c10 mstscax+0x171e11
0305ff58 4d88140c 01eabe20 0000000c 0305ff8c mstscax+0x171399
0305ff68 4d85bfe8 021a9584 0000000c 01eabe20 mstscax+0x17140c
0305ff8c 4d85e961 01ea7c10 0010f478 00000000 mstscax+0x14bfe8
0305ffac 4d85e9a2 0305ffec 7c80b729 02096998 mstscax+0x14e961
0305ffb4 7c80b729 02096998 0010f478 00000000 mstscax+0x14e9a2
0305ffec 00000000 4d85e995 02096998 00000000 kernel32!GetModuleFileNameA+0x1ba


Nothing 3rd party here, mstscax is the Terminal Services ActiveX client. Assuming the problem is with the Remote Desktop Connection client itself or one of its other components, I recommended that the users needing access to the remote server upgrade to the latest RDC client for Windows XP, 7.0. This can be found here: From previous experience with a similar issue, installing the latest RDC client was enough to correct; and after a follow up with the local tech, the problem was reported as resolved.

The important lesson here is that being disconnected from network resource doesn’t necessarily mean that this is due to packet loss or instability. This kind of assumption can send you on a wild goose chase through the OS networking subsystem or the larger network itself. With a little knowledge of crash dumps, and more specifically the post-mortem debugger in XP, the problem was quickly identified.

That being said, Windows Vista/7 has done away with a default post-mortem debugger of any kind. However, you can enable crash dump archiving in all Windows OS’ after XP by simply creating a registry key. See here or here for details.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: