Remote Desktop black screen Windows server 2012 R2

Many people, including me and many, have problems with this. However, there is a lot of information full of confusion. An easy way for those who have this problem in ARP connection. This problem is mostly caused by the ARP connection being left open.

SOLUTION: FOR DC SERVER: Write a rule from Server GPO. In case of disconnection or exit, log out within 5 minutes. Hello to everyone, If there are programs that need to remain open on the current server, apply the rule only for computers that will connect.

*Note! * Doing 5 minutes will minimize possible risks.*

TERMINAL SERVER: Apply the rule you will create on the DC Server only for the terminal server or apply it to the users who will connect.

If you have difficulty in creating rules, just write an answer.

In this article, I will be showing you the steps to take if you see a black screen instead of a desktop screen when you connect to a remote computer via Remote Desktop Protocol (RDP). This problem usually happens on Windows 10 and Windows Server editions. When you try to access a remote system remotely using RDP Client (mstsc.exe) and enter your valid credentials what you see next is a blank screen and leaves you with no clue on what to do. Follow the below steps on resolving this issue that is not new to the Windows system. For more related Windows Operating System errors you can read this: How to Fix “Insufficient System Resources Exist to Complete the Requested Service” error, how to fix the issue “The Security Database on the Server does not have a Computer Account for this Workstation Trust Relationship” on Windows Server [Part 2], How to Quickly Fix Windows Search Bar Not Working, Windows Out Of Box Experience: OOBESETTINGSMULTIPLEPAGE error on Windows 10, how to fix Windows cannot connect to the printer: Operation Failed with error 0x000004f8,  and How to Fix “Unknown hard error” on Windows Server and Windows 10.

The first thing you need to do is to open the Remote Desktop Connection and click on the Display tab and try to adjust the display configuration (Small-Large). You may also want to see this guide: Terminal Server (Now RDS): How to setup and configure Remote Desktop Services.

• The next thing you need to do is to click on the Experience tab and uncheck the box Persistent bitmap cashing.

• One temporary measure is to launch the Task Manager by pressing Ctrl+Shift+Esc on the keyboard. The launching of the Task Manager can display something on the screen.

• Another resolution to this issue is to update your system. It is very possible you have some pending updates to be completed and can result to issues like this

I hope you found this blog post on How to resolve Microsoft RDP connection black screen very interesting and helpful. In case you have any questions do not hesitate to ask in the comment section.

Microsoft has released emergency out-of-band updates to fix a Windows Server bug that is causing screens to go blank, general slowness, slow sign-ins, and, in some cases prevents users from using Remote Desktop to reach the server. Users first started reporting issues after installing the KB5008218 update that was released on December 14, 2021.

The bug affects the following versions of Windows Server:

• Windows Server 2022
• Windows Server 2019
• Windows Server 2016
• Windows Server 2012 R2

Microsoft said the updates have not been made available through Windows Update, so they will not be automatically installed on affected systems. Instead, they are being made available through standalone updates.

Currently, Microsoft has only released updates to fix the bug in Windows Server 2019 and Windows Server 2012 R2, which are provided as cumulative updates – KB5010196 for Windows Server 2019 and KB5010215 for Windows Server 2012 R2, which means it is not necessary to apply previous updates before fixing the bug.

The updates do not fix any security issues. They only install updates to fix performance issues and to make quality improvements.  The updates can be downloaded from the Microsoft Update Catalog on the above links, and instructions are available here.

Microsoft said it is still working on updates to fix the bug in Windows Server 2022 and Windows Server 2016 and expects to release updates for those Windows Server versions in the coming days.

• Have the same issue intermittently on my 2012 R2 server. Was never able to figure it out.

  Had to TeamViewer in when it did that, a reboot usually fixed it temporary, but that is certainly not a solution for a live environment.

• How about the licensing on these servers - are you guys sure the Licensing server is running - and functioning as it should?

• Are the user's logging out at the end of the day or simply locking their session?  One of the reasons why I reboot my terminal servers each night.  Users would not be able to reconnect to the session from the day before and would show a black screen upon login.
  

• Agreed with Randy - If the users are not logging out and just disconnects, that could produce this error. Use Group policy to limit the hanging sessions. You could also try to enforce this on one server directly on the RDP settings to see if there is any difference on the two servers.

• Thanks for the replies.  The licensing server is running and appears to be distributing licences normally.  The users' sessions are all terminated by policy overnight, so the morning logons are to new sessions.

  Thanks.
  

• Good afternoon,

  I have been fighting with a similar issue myself using Server 2012 R2.  One thing I did on my Server 2012 R2 boxes was to install KB2887595.  The KB has an item on there that addresses the black screen directly:

  "2897632 Logon screen turns black in Windows 8.1 or Windows Server 2012 R2"

  So far, it seem to have worked for all of the desktops in my office.there is download for the KB in the Microsoft Download Center, just seach KB2887595 and download/install.

  If you can't find the download let me know and I can point you in the direction I get it from.

  Hope it helps.  

  
  Spice (2) flagReport
  Was this post helpful? thumb_up thumb_down

• Thanks for the heads-up on that hotfix! I've installed the KB2887595 update on one of the impacted servers.  I'll report back in a few days once the problem shows up again on (hopefully) just the unpatched server.

  Spice (1) flagReport

  Was this post helpful? thumb_up thumb_down

• Hey there WillD2001! Was wondering how you made out with that hotfix install?

• I ran into this on a file server one time and it turned out to be a server that ran out of space. 

• Prime201, I have not encountered the problem again yet on either of my servers (patched or unpatched).  If the pattern holds, I would expect to have a relapse on (at least) the unpatched server by the beginning of next week.

  Thanks.

• Now that roughly two weeks have passed, I'm getting the black screens on login again.  KB2887595, sadly, did not fix this issue.  Something that strikes me as especially odd about this situation is that the user is always able to login properly on the first attempt after I force-logout a failed attempt.

• WillD2001, I was wondering if you found any resolution to this issue?  We are facing the same issue but with a larger environment, we have 6 session host servers and it seems our thin clients (also using FreeRDP) start experiencing this issue after a week or so.  Rebooting the servers resolves this issue for a while and then it starts happening again.  We are about to deploy 10 additional session host servers and add 400 additional users, I fear this is going to become a nightmare.  Any other suggestions would be greatly appreciated.  

• chadgeisler, I have not been able to resolve this issue.  Fortunately, my environment can tolerate off-hours downtime on the weekends, so I have my servers rebooting themselves late Saturday night as an interim solution.  I had high hopes for the patch mentioned earlier in this thread as it seemed to describe the problem pretty directly - but it has proven to be a failure.  

  Good luck.

• My new about-to-be-live SQL server is now doing this and I tried this patch, but it was already installed on both servers.

  But mine is not only RDP, but console does this as well.  If I logon console then hit Ctrl-alt-delete then click task manager I can run apps with CMD.

  More oddness is that now the cluster isnt on the best speaking terms at the moment... Server 1 isnt reporting anything to Server 2.  I think the issue is something deeper then this RDP issue.

• Question... HP hardware?

• 4c...55:72,

  I'm running a pair of Dell R710s  I don't know if it ever happens on console, because I'm rarely at the console.  I can tell you that if I look at the task manager for a user, all the proper programs (including those just in the "Startup" folder) have all been launched - the user just can't see them.

  Hope that helps,

  Will

• I've started experiencing the same thing today. User can log in and on the server side I can see all of his applications running, but he simply can't see them. I had to reboot the server to get things working again. Did you make any progress Will?

• One thing I tried that seemed to make a difference.  I added the DNS suffixes manually to the TCP/IP properties of the workstation accessing the remote server and I have yet to see the problem since.  DHCP is supposed to be giving the correct DNS suffix(s), and ipconfig /all does show those suffixes (2 in my case), but unless I add them manually to the DNS tab it doesn't seem to make a difference.

  Interesting WillD - I too am running most of my stuff on R710's...

  4c ... are you able to resolve back and forth from server 1 to server 2 manually?  that could be something with your DNS

  Food for thought.

• Try turning bitmap caching off, in the RDP file on your thinclient and see if that helps. I never had to reboot btw, I just log off the user and the second time he/she always sees his/her desktop correctly.

  It sounds like an issue with explorer.exe not starting correctly. Can you check eventvwr / process explorer, if there are any issues there?

  Spice (1) flagReport

  Was this post helpful? thumb_up thumb_down

• Tried everything still cannot RDP this Windows 2012 R2 server?

  is that cause any windows update?

• I've the very same issue on two different customer servers.

  I observed that in my cases only a single session id is affected. You can see all connected session ids with procxp (running as administrator of course). 

  Summary for me:
  After the customer called and told me that he gets a black screen I had a look into procxp and noted his session id (for example 114). I logged him off via task manager and told him to reconnect after his session gets fully logged off. He gets back his previous session 114 and a black screen. I logged him off a again and logged a test user to grab his old session number 114. My test user gets the black screen now. Now I told him to reconnect - he gets a new session id (115) and his desktop shows up normally.

  This is a really strange thing - it seems the Session ID 114 is corrupt in this case until I reboot the server. I really don't know how to fully wipe such a session. It seems that logging off a user doesn't fully clean up things related to such a session number...

• Hi Martin, 

  We have this exact same issue in a large RDS Deployment. It would appear that session 114 gives us the same issue. I have raised a call with Microsoft and they don't seem to be getting anywhere. Can you confirm what servers your customers are running on e.g. Physical/Virtual (if virtual what hypervisor)?

  From speaking to Microsoft there is no way to reset the session ID's other than rebooting the server and there isn't a workaround or way to skip the session ID.

  Kind Regards

  Jon B
  

• Hi Jon, 

  I can confirm that said machines running as virtual machines on ESX hypervisor. And as you said it seems there no other way as to restart the whole virtual machine. Very annoying but it seems that this problem is showing up rarely.

  Regards

  Martin

• I had this issue on Server 2012, while the guests were Fedora Linux machines running xfreerdp. I saw the comment above about DNS suffix, and tried adding the fully qualified hostname when connecting and it immediately resolved my problem.

• UAC. UAC is the problem. That bullshit, yes. In my case the first login was successful and working, but any other consecutive attempt was not working. I was getting either a flickering(unusable) or completely black screen, on RDP or directly on the console of the 2012 R2 server. In the Application eventlogs there were lots of errors with eventID 1000(Faulting application name: explorer.exe, version: 6.3.9600.17415, time stamp: 0x54503a3a Faulting module name: unknown).

  UAC was disabled. I just enabled it, reboot the server, and then I was able to log in with multiple working sessions. I even disabled back UAC and reboot the server again and things were working normally. Beware of UAC :)%uFEFF

• Just a quick note for anyone still fighting this.  Try disabling all smart card services if you don't use them.  I used proc mon to see what was hanging for my users and it turns out it was hanging looking for smart cards but we don't use them.  After disabling the services all is well.
  

• I came across this post quite by chance. We have had Black Screens plaguing us for 6 months. Here is what we did to help alleviate: I posted this on Technet -https://social.technet.microsoft.com/Forums/en-US/0a6774d6-f5db-407f-8c6b-b9f4991b2224/session-id-11...and thought I'd copy it to Spiceworks.

  This has got go be a bug. We use VMs as well. We opened a ticket to VMWare and they said that they have seen this issue before and it's Microsoft Related. We have been dealing with this issue for about 6 months. Since the beginning of the year. It's June of 2016 now. It's been driving my department crazy. We usually have to get our users to log into the backup TS running 2008 R2. Since Microsoft will not acknowledge the issue, I have created a GPO and tied it to our OU containing the TS server. It creates a scheduled task to reboot the server daily at 6:00AM. Hopefully this will help alleviate our Black Screen/Session 114 issues on my Windows 2012 R2 server. Hopefully Google will re-crawl this forum entry and get it more widespread for IT Departments. As a workaround: if you can't reboot the server during working hours..

  1. Login remotely from a console and server with access to the Terminal Server and verify logged in users.

  2. Check who is logged in using the console command: c:\>qwinsta /server:

  3. That will list the users and identify the one that currently holds Session ID: 114

  5. Manually disconnect Session ID 114 by using the console command: c:\>rwinsta /server: 114

  6. Now login with a dummy account so the RDP Session Host will divvy out 114 to your test user.

  7. The user having trouble should be able to log back in.

  8. Reboot as soon as you can off hours to alleviate the problem for 5-10 days or setup a daily task GPO to reboot it daily.

  Jason

• I had been searching a while to solve the issue of not being able to log back on the 2012R2 RDS Server. I tried all the recommended solutions. Either the problem would be that suddenly the existing clients logged in appeared to freeze and/or when you would RD Connect it never got to the Server login prompt but instead a black screen (this is not to be confused with logging in and then seeing a black screen as has also been reported). Nothing resolved this except to reboot the RDS Server (2012R2). I finally read that by disabling the Network card Large Send Offload on the 2012R2 RDS Server it resolved everything. All red herring errors and warnings pointing me everywhere but to the solution that actually worked, stopped. Once I saw that this worked immediately, then I also disabled the Large Send Offload on the domain controller as well. The related error that pointed me in the right direction was (A timeout (30000 milliseconds) was reached while waiting for a transaction response from the UmRdpService service.) Thank you
  

• Thanks for your response. I will try this on a server that is experiencing the back screen with RDP. 

  Were you also getting the system event  4005 Winlogon process has unexpectedly terminated at the time of the issue?

  Thanks

• Been seeing this a lot since roughly mid august when that update (KB3172614) was automatically installed.

  This is a multi server environment affecting more than one server with a usage of around 60+ users at any one time. (farm of 3 with the issue, and 2 single servers which haven't had the issue yet)

  So far, the only clients that have had the issue (20+) have been windows 10, most of them being forced to use windows 10 because of Microsoft.
  

  FYI more than anything.

• I am also running into this issue and it started immediately after KB3172614. Apparently there is no fix at this time and the short term workaround is to reboot the server.

• We have found that Microsoft have resolved the issues around re-using session ID's for new logins which has meant the sessions recycle properly and don't reach ID 114. This was resolved by installing all the latest available patches provided by Microsoft. Unfortunately we aren't able to say which one exactly as they were installed in bulk.During a microsoft case we were told to ensure that the below hotfixes were installed on top of the standard windows updates:KB2995388KB2996799KB3000850KB3003057KB3014442KB3013769KB2993651KB2975719KB2993100KB2979582KB2990532KB2995004KB3047296

• We have had 2 or the 3 Remote Desktop 2012 R2 hosts with the random black screen issue for about a month

  From another forum, we determined that the 2 Windows that must be removed are KB3172614

  KB3179574

  https://social.technet.microsoft.com/Forums/windowsserver/en-US/f425a7ff-6544-40d0-afef-a8bd07371fa7/rdp-into-black-screen-then-disconnects-2012-r2?forum=winserverTS

  And installed hotfix
  KB3047296 Issues have not appeared today.

• Good find on the hotfix, but it's pretty old. Usually these black screens appear after a few days of running so it'll be interesting to see if yours are gone completely.

• jonbarnett, 

  Can you confirm you've still not had any issues with the ID 114?

  We're in the process of making sure all the patches you've listed are installed this week, so confirmation on issue fully resolved would be appreciated.

  Thanks, J

• Any update on the resolution yet ?

• Hi Tonyspencer2 

  Please can you let us know are you still facing the random black screen issue with remote desktop after removing below Hotfix as you mentioned in earlier post.

   

• Hi jdeaneads,

  I can confirm we haven't had this since the updates were installed. Sorry for the late reply, i didn't see the email notification for your post. Apologies i cannot be more specific with the hotfix that resolved 

• also interested to know if after uninstalling the two patches if the issue was resolved?

  KB3172614 KB3179574  

• We have been facing this bugging issue for months now since our upgrade to Windows Server 2012 R2. Currently, we are downloading and installing all these hotfixes as suggested by jonbarnett2 and will revert on whether or not the black screen issue was resolved.

  Our last option will be to revert back to Windows Server 2008 R2 and continually curse Microsoft forever if no fix is provided!!

• @ isaac9101:

  Same as what has been suggested here.

  For us what made the black screen with RDP go away was to uninstall:

  KB3172614 KB3179574  

  Please read the "known issues in this update"

  https://support.microsoft.com/en-us/kb/3179574
  https://support.microsoft.com/en-us/kb/3172614
  

  " SymptomsAfter you apply this update on a Remote Desktop Session (RDS) host, some new users cannot connect to an RDP session. Instead, those users see a black screen, and they are eventually disconnected. This issue occurs at unspecified intervals.

  "

  Spice (1) flagReport

  Was this post helpful? thumb_up thumb_down

• user5926, you sir are awesome!  None of the other solutions I've found seemed to apply to me (most dealt with Webroot AV).

• Hello,

  we had exactly the same problem. RDP from W2K12 to remote W2K12 worked for a while and after a couple days we got just black screens. We tried all mentioned items above. At the end what really helped, is to disable networking negotiating. You can find that under Network -> Properties -> Configure -> Advances. Just put "Speed & Duplex" to 100Mbps Full Duplex or something fix. As well put "Large Send Offload V2 (IPv4)" to Disabled.

  That way you will have less UDP packages passing your firewalls and routers and it will work better.

  Good luck

  %u2003Thomas