none
Black Screen for Users in RDS 2016 RRS feed

  • Question

  • Windows Server 2016 RDS setup with one DC and 3 session host servers, all running as VMs under Citrix XenServer. This is a session-based deployment for RDP sessions.

    Occasionally (that means approx every 7-10 days), new users logging in to RDS get a
    black screen. That is, they can successfully log in but then see only a black screen, no task bar, nothing. Users can see moving mouse cursor, and they can bring up the Task Mgr with Ctrl+Alt+End. Sometimes, after 10-15 minutes the user desktop becomes visible, but most of the
    time it never does.

    Normally, every additional user logging in after this occured also gets the black screen. The only solution is to reboot this session host server.

    The servers are updated to PT (July 2018).

    Note - I installed an additional session host server recently and noticed that this phenomena does not seem to happen on that one (at least not as frequent). Same update status but was installed from later download media (evaluation edition download from internet, then converted to Standard edition by inputting a license). They do, however, all show the same build number in the settings app: 14393.2248.

    So is it recommended to make a new install for all session host servers? Do not really understand why I would have to do that. They have the same update level, just one was installed from a later base media - but it's the same edition. Doesn't a server end up with an identical setup no matter what original media file was used, with all the updates? That should be the point of the updates, or not?

    Or is there any other underlying reason for the black screen phenomenon which I should address?


    Atradius

    Tuesday, July 24, 2018 5:59 PM

All replies

  • Hi,

    Thanks for your question.

    Please refer to the link below:

    https://partnersupport.microsoft.com/en-us/par_servplat/forum/par_winserv/rds-2016-sessions-black-screening/7101c19a-4eb1-4cb8-9420-4cedd628110b?page=2

    Best regards,

    Travis


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

    Wednesday, July 25, 2018 6:34 AM
  • Hi,

    Was your issue resolved?

    If you resolved it using our solution, please "mark it as answer" to help other community members find the helpful reply quickly.

    If you resolve it using your own solution, please share your experience and solution here. It will be very beneficial for other community members who have similar questions.

    If no, please reply and tell us the current situation in order to provide further help.

    Best Regards,

    Travis


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

    Thursday, July 26, 2018 9:38 AM
  • Hi,

    Was your issue resolved?

    If you resolved it using our solution, please "mark it as answer" to help other community members find the helpful reply quickly.

    If you resolve it using your own solution, please share your experience and solution here. It will be very beneficial for other community members who have similar questions.

    If no, please reply and tell us the current situation in order to provide further help.

    Best Regards,

    Travis


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

    Tuesday, July 31, 2018 7:57 AM
  • Thanks, and I have followed the link you posted.

    According to this link there seems to be 2 possible reasons:

    (1) a specific update relating to "app framework". Per the description this relates mostly to cloned server instances which wouldn't apply in my case. Anyway, I did go ahead and install that update. It seems that the issue occured again 24h later. Will have to confirm after next reboot if that is becoming stable.

    (2) Browsing issue occuring with Firefox. Yes, the users are mostly using Firefox here, pretty much in every session. If  that is really the problem, I cannot mark this as solved - then the problem is with Microsoft because how come one single misbehaving "3rd party" program can crash an entire RDS session host server? That is a serious flaw (if true).

    Cannot easily test the Firefox theory. Could uninstall Firefox, forcing all users to use Chrome (or is that not any better?) They'll be loosing their bookmarks etc though.

    The issue does not occur every day but currently approx once a week, so it'll be a prolonged test period where I would have to ask the users to hang on without their Firefox settings ...


    Atradius

    Tuesday, July 31, 2018 8:20 AM
  • Just saw there is an additional hint in one of the posts in the link you referred to

    (3) Disable the AppReadiness service.

    Stopped that service on all 3 RDSH servers, and disabled (seems it is set to "Manual" by default).

    Will let you know how this develops. Probably will be a few days before I can say for sure. I'll test if that needs a reboot as well.


    Atradius

    • Proposed as answer by asd456456 Wednesday, November 20, 2019 11:04 AM
    Tuesday, July 31, 2018 8:33 AM
  • One of the servers did the black-screening again. Stuck and had to be force-rebooted. Like earlier.

    This thing did have the AppReadiness service disabled, so #3 did not handle it and
    the update (#1) was put there too, so that does not handle it either.

    Any other ideas, or is my only option to try to test the Firefox browsing idea?


    Atradius

    Thursday, August 2, 2018 2:09 PM
  • Currently testing the Firefox theory.

    Disabled users from starting Firefox. Will post results here. Will have to test this over a couple of days, as the issue does not occur daily.


    Atradius

    Thursday, August 2, 2018 2:56 PM
  • BTW, this issue persists, but there is a workaround that actually works.  However, I'm incensed (as I'm sure everyone with this issue is also) that MS hasn't given any explanation, direction, or patch regarding this ubiquitous issue. 

    There's an ongoing Spiceworks forum thread about this as well, where it has been determined that restarting the audio service for the affected session host will correct the black screen without needing to restart

    While I believe at least one tech reported the issue without Firefox, I'm pretty sure it's something to do with Firefox and W2016: https://community.spiceworks.com/topic/2018699-rds-windows-server-2016-desktop-freeze-black-screen

    What makes this issue even more annoying is that W2016 doesn't get Edge, at least not currently.  At least if MS had a current browser to offer for RDS, this wouldn't seem so bad.  Instead, they just ignore the problem, presumably, and leave all of us to struggle to explain why such things exist, and why we continue to use their products.  Meanwhile my client cannot use Chrome due to company policy, so their basically left with FF or IE, and one of them breaks RDS, sigh.

    Thursday, August 2, 2018 7:02 PM
  • Hi,

    Thanks for your reply.

    It is indeed a sad situation that ws2016 does not get Edge.

    Best regards,

    Travis


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

    Friday, August 3, 2018 8:35 AM
  • Restarting the audio service - that does NOT work for me, and has never worked.

    Most of the time the server is so "down" that it reacts to nothing - I can start Task Manager and try to do anything from there but it won't do anything. I can (via TaskMgr) attempt to restart the Audio Service but it hangs at stopping it. 

    Only one time I succeeded in restarting the audio service and it did not change anything. 

    This is still a problem. Today I will remove Firefox from the entire RDS setup and see if that helps. I guess I'll have to be watching it for a month until end of January to be sure.


    Atradius

    Tuesday, January 1, 2019 8:41 PM
  • Hi,

    Thanks for your reply.

    Here are two suggestions:

    • when use logging in to RDS get a blackscreen, we can enter Ctrl+Alt+End and select task manager, go to file item and run new task ,enter explorer.exe and look if there will be normal display
    • After you uninstall the Firefox ,we can check if the problem persist.when use logging in to RDS get a blackscreen again, we can enter Ctrl+Alt+End and select task manager,go to detail item and look which processes with high CPU or memory usage.

    BTW, I would suggest you create a new post because others may have different ideas.

    Best regards,

    Travis


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

    Wednesday, January 2, 2019 7:16 AM
  • Very surprised restarting the Audio Service doesn't correct your blackscreen issue.  I suppose your issue could be different somehow.  We restart the service remotely, as commonly we cannot sign-on to the affected server either.  However, console desktop sign-on often works when RDC doesn't, due to the blackscreen.  Also, I would use a local admin for a console sign-on, instead of a domain account.

    Yes, sometimes the Audio service fails to stop, which to me only confirms there's an issue related to that service.  In that case we determine the PID used by the Audio Service and kill it, then start the service again, thankfully that service runs in its own process.

    In our case, if the client didn't rely on audio, we'd opt to try and keep it stopped (manual or disabled).  Many of our clients do not rely on audio on their RDS sessions.  However, in the case where we have the issue, they need audio.

    Unfortunately, our affected client needs to keep using firefox, or we would have tested removing it.  So, we're patiently waiting for Edge based on Chromium...


    Wednesday, January 2, 2019 1:05 PM
  • Thanks for the hint. 

    Unfortunately the most common scenario here is that when a server gets a black screen, there is no way to get it to do anything. While I am capable to log in locally with a local Admin password, there is still a black screen. I can start tasks with the Task Manager but it won't show Explorer. Does show command prompt but fails to respond to any command entered to stop services etc. Remote access won't work in any way - PSExec, remotely logging in to services, none of them ever connect.

    So maybe the issue is different. In any case, we are testing how it goes without Firefox and will come back here to report the outcome.


    Atradius

    Friday, January 4, 2019 10:16 AM
  • Not sure if you guys have been able to resolve? I have experienced similar with 2016 RDS box and UPD's being used. Veeam was being used to backup the infrastructure and had been set to backup All Disk. We saw that when users disconnected their sessions from the RDS (which left the UPD attached) when they next logged in they had the issue. Amended the backup job to only back up Disk 0;0 on the RDS boxes and this seems to have resolved the issues for now. 

    Friday, March 8, 2019 11:08 AM
  • Update regarding Firefox - this does not solve  the problem. 

    We removed Firefox entirely, in fact did new installs for all session hosts servers with no Firefox, just to be sure. And it is still black-screening. Possibly less frequently, but still does.

    @cliveinton - thanks for the tip. In our case, the black-screening also occurs when there is no backup being made at all of any kind.


    Atradius

    Friday, March 15, 2019 8:07 PM
  • Unbelievable... we have the exact same issue and none of the proposed solutions do anything. Sometimes the black screen is for 5-10 seconds and sometimes 5-10 minutes.... WTH is going on?

    WS16 1607

    Thursday, March 21, 2019 11:03 AM
  • No firefox installed on our 2016 server.  Restarting the audiosrv did the trick though.

    Anyone has any solution for this?

    Friday, March 22, 2019 2:52 PM
  • Hello to all!
    Has anyone defeated the black screen problem when connecting over 15 or 20 users to Windows 2016 Server?

    disabling the Windows Audio service - Disabled, the problem remains.
    disable caching of turned drawings in the RDP settings - disabled, the problem remains.
    disable compression for RemoteFX - disabled, the problem remains.

    Can anyone give an exact link to Microsoft April 2019 CU for Windows Server 2016?

    We use Windows Server 2016 Standart 64-bit (10.0 Build 14393)

    Friday, December 6, 2019 7:37 AM
  • I did not have the issue since about 2 months.

    I cannot exactly pinpoint what solved it but having re-installed new session hosts multiple times, the below seems to be a workable mix:

    - Make sure Windows update is fully patched to present time, minimum July 2019 update
    - Stop and disable AppReadiness Service
    - Stop and disable Windows Search service
    - add the key DeleteUserAppContainersOnLogoff to registry as described in the post linked below by Andy You (for this to work, you have to install the update KB4467684 - it might not be installed on your system despite being current on updates)
    - add registry key DelayedDesktopSwitchTimeout as described above in the post (in below link)

    And finally

    - remove Mozilla Firefox and Thunderbird, these apps seems to mess with the Audio service and can cause Windows to hang

    See also following forum entry for more information:

    black-screen-server-2016

    Hope this helps.


    Atradius


    • Edited by Atradius Sunday, December 8, 2019 6:17 PM
    Sunday, December 8, 2019 6:15 PM