1

For over 3 years I have routinely observed the following: while our server is busy compressing backups (7z, all cores, idle priority), the first attempt to RDP to any other computer on the local network results in a timeout. The second attempt then connects and opens immediately. Cancelling and quickly retrying the connection does not help, I have to wait out the 60 seconds.

When I record the exchange with Wireshark on both sides of the connection, I see that around 6kB of data is exchanged within the first 400ms, then the communication stalls. After 60 seconds the remote endpoint sends a RST,ACK and the RDP dialog keeps spinning for 30 more seconds before declaring a timeout. There is nothing obviously wrong in either of the captures and they don't seem to be doing any related network communication while this is happening.

What's odd is that if I do cancel and retry the connection after waiting a bit, it eventually connects. I still see the RST packet for the first connection show up on the 60-second mark. The timeout seems to be a global thing.

So... any clue what I'm dealing with here?

theultramage
  • 413
  • 1
  • 5
  • 15
  • Can you clarify your first sentence? I understand you have a busy server. But what other computers are you trying to RDP to, and from where? How is the server involved in this equation? – Appleoddity Nov 25 '19 at 05:10
  • The server is my starting point, it's where I have all my management tools and where all my outgoing RDP connections originate from. The computers on the network are employee workstations, a mix of various windows versions, Vista and above. – theultramage Nov 25 '19 at 07:37

2 Answers2

1

I've noticed similar behavior on various servers over the years... I've found that adding the following registry modification on the remote server, allows me to extend the default 60 second RDP timeout and the account will then login:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp LogonTimeout REG_DWORD Decimal: 240 (seconds)

You can easily add this new registry value using the REG.EXE command on an elevated Command Prompt (Run-as Administrator):

REG.EXE ADD "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v LogonTimeout /t REG_DWORD /d 240

(Adjust the 240 value to anything above 60. This value is in seconds.)

Please let me know if this addresses your situation!

j4mes
  • 11
  • 2
  • Thanks for the tip. I am hoping there is a way to eliminate that strange 60-second delay, or at least understand why it's there. I will save this as a workaround in case nothing else works. – theultramage Nov 25 '19 at 07:46
  • I have determined that my issue is caused by remote audio, apparently due to an old unsigned codec causing repeated full searches of System32\catroot. This folder is huge on 2012R2. On Win7/Win10/2019 it's many times smaller, so it's possible the issue still present but not as noticeable. – theultramage Mar 11 '23 at 10:49
0

After a long time of seeing the issue come and go randomly, even when the server is not under load, I am now fairly confident that the cause is RDP remote audio. Even though the profile on the management server, used to connect to other hosts on the network, has remote audio disabled, the profile on my PC that is used to connect to the management server, does have it enabled.

The remote audio feature has always been spotty. Sometimes it works fine. Sometimes it plays audio back with a 3-second delay. Sometimes it starts stuttering. And often, it drops out after a period of no playback - the audio device is still there, but no sound will arrive. Presumably an UDP session timeout. Reconnecting temporarily fixes it, but it also removes and re-adds the audio device, which trips up a bunch of software that assumes that the device is persistent.

This week I've observed a moment where the issue was present for multiple hours. Then my RDP session got briefly disconnected due to network issues. When it reconnected, suddenly the issue was gone. But an hour in, I noticed it happening again. I finally went into my PC profile and disabled remote audio, then reconnected. It's been over a day now, and RDP connections open instantly. The downside is that I'm now without remote audio.

So what I assume is happening is that when establishing a connection, the RDP client on the server is trying to do something with the lost audio session, takes 60/90 seconds to time out, and then I guess temporarily flags it as unavailable. That would explain why I'm not seeing any traffic going between the server and the other host while waiting for this timeout.

EDIT: Further testing has revealed the following behavior:

  • If the audio device is idle for more than a few minutes, it malfunctions.
  • The malfunction happens on both TCP and UDP so it is not a NAT timeout issue.
  • During the malfunction, the speaker sound Test will either indicate volume levels but not make any sound, will stall for 10-20 seconds and then play, or will stall for 1-2 minutes and then display a failure popup.

I have tried searching for "rdp audio stops working", and found serverfault.com/q/1076031 (audiodg stops after 5min idle and has long startup delay), pointing to https://superuser.com/q/994536 (audiodg heavy catroot scan), pointing to https://superuser.com/q/584746. One answer implies that a missing embedded signature on l3codeca.acm is causing a recrawl of System32\catroot (350 MB in 20000 files on 2012R2) everytime the audio device is accessed. If this operation runs at low priority, it would explain the timeouts and playback delays when the cpu is busy.

I have applied the DisableProtectedAudioDG workaround and I'm now seeing that audio continues to work even after long idle periods, and remote connections open instantly even with enabled audio.

theultramage
  • 413
  • 1
  • 5
  • 15