Remote Desktop Sessions Freeze with 1809 RRS feed

  • Question

  • RDP sessions freeze randomly.  User Input still gets to the other end, but the client display is frozen except for the cursor.

    Best way out is stop that session and start a new RDP session.

    This is new behavior that began occurring immediately after the recent update to 1809 in the spring of 2019.

    Does this on all 4 of my Win 10 Machines.

    • Moved by cloris_sun Monday, April 29, 2019 7:53 AM correct forum
    Sunday, April 28, 2019 10:15 PM

All replies

  • You could set the color depth of the remote session to "True Color (24 bit)" and test if it helps.

    Monday, April 29, 2019 5:00 AM
  • hi,

    0 from your description ,when you remote access from win10 to session host server ,the remote desktop session freeze,is it true?
    1 can you enter winver in command prompt on win10 computer and look the os version and os version number? [for example windows 10  enterprise 1809 (os build 17763.316)]

    2 can you enter winver in command prompt on session host server and look the os version and os version number? [for example windows 10  enterprise 1809 (os build 17763.316)]

    3 find one problematical win10 computer, please check the symptom in a clean boot (refer to windows 10 steps) environment if it is possible. Ensure the latest update has been installed to avoid known issue on this test win10

    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact

    Tuesday, April 30, 2019 5:42 AM
  • Is there any progress on your question?

    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact

    Thursday, May 2, 2019 12:47 PM
  • Hi,

    Thanks for the reply

    0 yes, I use 2 Surface Pros (SP4 and SP6) as RD clients to 2 win10 desktops as RD servers. Freezes occur in any combination thereof.

    1 all computers involved are 1809 17763.437

    3 Not possible now due to time constraints (need to work) maybe later...

    Thursday, May 2, 2019 3:49 PM
  • HI again,

    This still occurs, but only 2-10 times a day.  Mostly seems to correlate to times when I am at home connecting to work over the Internet and there is some network congestion.  Never seems to happen when I am using the same client and server when I am at work going over the Intranet.  I mostly just restart the RD session immediately now that I recognize the signature so it doesn't slow me down much.


    Thursday, May 2, 2019 3:54 PM
  • Tried that but no joy.
    Friday, May 3, 2019 5:43 PM
  • Hello,

    I did not experienced this issue before on windows, however firstly try to test It from antoher client and then try to update your workstation.

    Mark it as answer if your question has solved. MCT Regional Lead. x2 MCSE-MCSA Exchange Server & Windows Server

    Friday, May 3, 2019 8:07 PM
  • Update 5/5/19,

    Thanks for the suggestions, but no positive result from any of them.

    Further info.  Last time this happened (just now), I waited through the freeze, only clicking on a few places in Acrobat reader.  When it unfroze after about 20 seconds of my doing nothing but waiting, I saw that the clicks had been recognized on the other end but not displayed to me until the un-freeze.  I then did the same thing that triggered it originally, going forward one particular page in the pdf document I was reading.  And it froze again!

    Killed the RDP session and started a new one and it did not repeat.

    Conjecture that fits my symptoms:  Something in the downstream channel that updates my client screen becomes unhappy and freezes my screen as the result of something in the downstream data.  When this happens the client display freezes, but the upstream channel keeps functioning.  Once this happens the RDP session may appear to recover, but it is unreliable and needs to be killed to fully clear the problem.


    Sunday, May 5, 2019 4:52 PM
  • This is not related to Acrobat reader, it does this on many apps.
    Sunday, May 5, 2019 4:54 PM
  • hi,

    when the problem happened again .can you write the system time and look if there is any related log .

    when the problem happened ,we can write the system current time then  look if there is any log information about current issue on both client win10 and server win10.

    event viewer\windows logs\




    on both client and  server

    Event Viewer – Applications and Services Logs – Microsoft – Windows – TerminalServices-**** 

    Event Viewer – Applications and Services Logs – Microsoft – Windows – RemoteDesktopServices-****

    Event Viewer – Applications and Services Logs – Microsoft – Windows-remoteapp and desktop connections

    Event Viewer – Applications and Services Logs – Microsoft – Windows-remoteapp and desktop connection management

    when you ping target server on your client computer ,is there any difference between normal time and fault  time ?

    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact

    Tuesday, May 7, 2019 2:26 PM
  • I've been having the same issue since upgrading to 1809 and 1903.

    I keep a ping window open at all times to check ms and packet loss, and I've found that almost every single time it freezes, I lose a packet in the ping.

    I've tested this with several ISP's in different locations, and found it always seems to correlate with packet loss.

    I'm going to see if I can disable UDP over RDP, because UDP has to be re-transmitted manually. I suspect that somewhere along the way that mechanism has broken.

    Tuesday, June 25, 2019 2:46 PM
  • I have the same problem here, also after upgrading from 1809 to 1903.

    And it's seems to be related on what application on the remote machine is running.

    When Skype is started it happens more frequently.



    Thursday, June 27, 2019 7:39 AM
  • Driving me nuts. I'm a sysadmin for global company and often work from home and remote into my office PC over a Cisco AnyConnect VPN. All since updating that PC to 1903........grrrrrrrrrr

    • Edited by Garret NZ Tuesday, July 9, 2019 8:51 AM
    Tuesday, July 9, 2019 8:49 AM
  • I am also experiencing this issue after updating to 1903.

    This morning I changed my RDP protocol configuration from Use either UDP or TCP (2) to Use both UDP and TCP (0). I did that by modifying registry value SelectTransport under registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp from 2 to 0 and have not experienced any freezes since then. Note that this setting can be controlled by a group policy (c.f. Microsoft.Policies.TerminalServer::TS_SELECT_TRANSPORT).

    For those who want to give it a try, make sure you reboot the remote workstation after applying the registry change.


    • Proposed as answer by Pelle Chevelle Monday, October 14, 2019 8:31 PM
    • Unproposed as answer by Pelle Chevelle Monday, October 14, 2019 8:57 PM
    • Proposed as answer by A123777 Monday, October 28, 2019 1:02 PM
    Friday, July 19, 2019 4:01 PM
  • Actually, changing 'SelectTransport' registry value to '0' didn't make much difference in the long run. However, as suggested on https:: //, changing it to '1' did.
    • Proposed as answer by monobjorn Friday, October 4, 2019 10:59 AM
    Thursday, August 1, 2019 5:13 PM
  • I am having the same issue on 10 clients. I've tried everything I could find:  I've tried turning off/on just about every MSTSC setting there is, I've updated all drivers for everything(was specifically targeting network and graphics), I've disabled auto-tuning on the NIC, I've edited the registry to only only allow TCP connections in TS, I've reset our router and all hardline connections, and I've tried other remote desktop apps. Did a Ping Monitor and it isn't a connection issue. Still happening and can't figure it out. 
    Friday, August 30, 2019 5:26 PM
  • Update: 

    Since I first posted this at the end of April (after 1809 upgrade), the behavior has remained about the same.  The problem only occurs when I am using RDP to connect to my office remotely through my VPN over the internet.  It never occurs when I am just going through my office intranet.  It also correlates to times of "network congestion."  The session will usually become sluggish (excessive latency) first.  Then typically I will click on something and the screen will not respond.  I click on a few other things and notice that there is no response.  Stop that session and start a new session and it shows the effect of all the clicks while it was frozen.

    This occurs on all my machines: 2 Win10 Surfaces Pro Clients and 4 Win10 Desktop Servers.  They are all now running 1903.

    I have just been living with this behavior since updating to 1809.  

    Possible Solution?:  For the last couple of days, I have switched to using the Remote Desktop App on the Surface client machines instead of the Remote Desktop Connection (*.rdp files) that I have used for the last decade or so.  I read about this as a possible solution suggested on another thread.  So far it works better - no freezes yet.  Under conditions where I previously would have experienced a freeze, it seems to recover without freezing.  The session becomes very slow and spastic, but recovers after a few seconds - without requiring a restart.


    Tuesday, September 3, 2019 6:26 PM
  • @penyberg I also tried the "new" Remote Desktop App that was available in the microsoft app store. While it didn't have the freezing, it would always say something like "session disconnected, reconnecting" every time I come back to it after being in another program. Sometimes it would come up fine but other times I would have to disconnect the session and go through the log in process again. Eventually I went back to the regular MSTSC app because it was doing that so much it wasn't really better than the freezing I was getting. 
    Tuesday, September 3, 2019 7:11 PM
  • Success with the Remote Desktop App. No Freezing, no "session disconnected..." I don't like the "full screen" mode. Maybe I'm not setting up right. But the top and bottom of my client screen still shows so I have two task bars. Obnoxious.

    The whole RDP experiences is very 90s in look and feel.

    Friday, September 6, 2019 1:53 PM
  • @Arron-PS I had better results than you report, but also had issues with the App.  My experience is more along the lines of @CT Andy- yes the app doesn't freeze, but...

    The App remote desktop has it's own "usability issues" - it works pretty good for me at getting and keeping connections, but my "user experience" is not so good.  It's not just the (IMHO) "weird" way it has changed full screen mode etc., it's the greatly dis-improved real-time operation.

    I basically only use the App when I "have to" - when I get or expect to get freezing with the old RDP method.  Why?  Because the App is annoying to use:  

    1) The precision of mouse motion is much worse, so I have to move the mouse very slowly to get the cursor to end up where I want it as it jumps abut on my screen for no reason.  The mouse wheel basically ignores the first two clicks when changing direction.  The whole experience is very squirrely.  This is even true when I am going over a fast intranet connection.  I switch to the old RDP method and it works much better under the same circumstances. 

    2) This on top of the full screen operation thing.  When I am logged into a remote computer, I want that computer to be the only thing that appears on the whole  screen - just as if I was sitting in front of the remote computer on its own screen.  The app doesn't seem to get that, it keeps putting up the task bar from the local computer.  To get "real" full screen back, you have to cycle through some rigmarole - and once you get it back, you find all your windows have been moved into one big pile on your screen.

    That said, I do like the app, which I assume is the future of RDP - it just needs more work to improve usability, etc.

    My bottom line for now is that I use both the "legacy" and the App RDP client, depending on the situation.  They both have issues that make them unusable for me, depending on the situation.

    Good intranet connection - I use the legacy RDP.

    Marginal Net connection - I use one or the other until it gets too annoying.


    Thursday, September 12, 2019 8:57 PM
  • Hi everyone.  Looks like we ran into this bug in our enterprise environment.  What I've noticed is that in the windows event viewer under the application area, is the following error:

    Followed closely by:
    NOT spawning provider, eventType=0x4, session=2, PID=7392

    This combination repeats 4x.

    Becoming a hot item around here as we have lots of remote users.  We recently rolled out 1809 and this is when it popped up.  Same symptoms as described in the initial post.  RDP session freeze but mouse continues to move.  Have to close and reconnect.  I can reproduce this on our internal network from 1809 desktop to 1809 desktop, as well as a hardware VPN connection from a 1903 client laptop to a 1809 desktop.  

    We have a case open with Microsoft, but have no traction from them.  I was wondering if anyone here had any new information with regards to their experience.  

    Tuesday, September 17, 2019 7:48 PM
  • Hi All,

    Final(?) Update:  I now pretty much exclusively use the RDP app and rarely use the legacy RDP client.

    As usual, I can't point to any single thing to explain this.  Either the RDP app is getting better, or I am just getting used to the somewhat different way that it operates, or both (1).  I also made some improvements to the quality of my Wifi connection at home(2).  Microsoft has been pushing updates as well, so this may also account for some improvement.

    1.  The RDP app still is sub-optimal for small mouse motions, which is still annoying, but I have gotten used to it.  However, on the positive side, it works better in some areas that the legacy RDP never did - like my Surface Stylus can actually execute a right-mouse-click when using the app. When I switch to the legacy RDP client, it does not work under the same conditions.  And it is the future....

    2.  I noticed that both clients were as having problems even over my home Wifi network to a local RDP server at home.  When I looked into this, I discovered that there were on the order of ~20-30 competing/interfering Wifi networks in the 2.4GHz band.  I switched to using 5GHz connections and local and remote RDP connections got a lot better.


    Thursday, October 3, 2019 4:48 PM
  • Actually, changing 'SelectTransport' registry value to '0' didn't make much difference in the long run. However, as suggested on https:: //, changing it to '1' did.
    After adding this entry in the registry on my remote computer my RDP session has been working great all day.
    Friday, October 4, 2019 11:00 AM
  • The session will usually become sluggish (excessive latency) first. 

    Do you have observed that ths issue is more likely to occur once you do a task switch, using Alt-Tab?  For me the issue seems having to do with the data amount transferred, i.e. a task switch replaces a bigger part of the screen content. The latency you describe may become more effective in this case.

    • Edited by msms843 Sunday, October 20, 2019 1:53 PM
    Sunday, October 20, 2019 1:53 PM
  • @monobjorn, is this still working well for you? All fixed now?
    Tuesday, October 22, 2019 12:47 PM
  • spcad's second comment did the trick (value = 1 , have not tested 0 btw), thanks alot
    • Edited by A123777 Monday, October 28, 2019 1:05 PM
    Monday, October 28, 2019 1:03 PM
  • the SelectTransport = 1 worked right a way! Thanks!
    Thursday, November 21, 2019 6:24 PM