A client reported an issue that when some one RDP into their Windows 2012 server (which is also a domain controller) s/he get a black screen, The same black screen exist even if some one logs into console session, however apart from this all the services on the server functions just fine. The only thing they can do to resolve the issue is to reboot the server.
We researched on the issue and found that a lot of people are facing same or similar issues on server 2008 R2 and Windows 2012, We did implement some possible solutions on the server but as of now I am not Cent Percent sure if the issue is resolved as it happens rarely.
Solution 1:
We have observed that when a user gets black screen s/he, usually it has a disconnected session which is not getting reinitialize, so as a solution we implemented an idle session timeout limit on the server, so that after a specific time (18 hrs in our case), any disconnected session will be logged off immediately. The settings can be implemented in session state if the server is configured as a Terminal server or session host server. it can also be configured by manually editing registry, we although configured it using local Group policy on the server.
Session timeout connection Group policy settings
Solution 2:
Some people have claimed to resolve this issue by configuring following group policy setting to enable both TCP and UDP protocols, if you do so, ensure that you make required changes in your network router or Firewall.
Computer Configuration\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Connections
Solution 3:
If you are RDPing into the server from Internet and you get this black screen issue, than try to RDP into the server from local Lan, some people have found the issue only happens from internet. If that is the case than an easier workaround would be to connect to VPN and then access the server on local IP
Solution 4:
This solution is also published by MS as a fast publish article here, this one talks about Authenticated Users and Interactive logon not having enough rights on the server, here is the solution
Method 1:
Add the “Authenticated Users” and “Interactive Logon” to the local “Users” group and reboot. If the machine is a DC, do the same in the builtin\users Group
Click Start, Run, type lusrmgr.msc then ENTER.
Select Groups in the left pane.
Double-click Users in the right pane.
Click Add, and then click Locations. Scroll to the top of the Locations dialog and select the local computer name, then click OK.
In the Enter the object names to select field, type Interactive; Authenticated Users (separated by a semi-colon). Then click OK.
Restart the computer.
Method 2 :
Run the following commands from a command prompt:
Net localgroup Users Interactive /add
Net localgroup Users “Authenticated Users” /add
Solution 5:
Some people have observed that this issue happen if “On resume display logon screen” is enabled on-screen server settings of the server, so one can try disabling the same under
Control Panel->Display->ScreenSaver settings
Solution 6:
In case of Windows 2008 R2, this issue is known to be caused by a specific Microsoft update KB 2830477, you can try un-installing it from your server if it’s there.
Solution 7:
I wouldn’t really bet on this one but like we used to disable UAC on Windows 2008R2 server to reduced unexpected issues, I will suggest to disable Network Level Authentication on Windows Server 2012/R2 as its known to cause a lot of RDP issue. Please refer out other article, here, for the steps to disable NLA.
Apart from the above steps which we took on the server to prevent the issue, I did find a lot of work around which people found to get around the issue if you actually see it happening that you do not want to fiddle with server.
Workaround 1:
Changing color depth to 24bit (or less) in rdp file solves the problem, but this is a partial (unwanted) solution.
RDP properties Chaging Color Depth
WorkAround 2:
Disable BitMap Caching in your RDP client (on the EXPERIENCE tab). This solution is also explained in MS fast publish article here
RDP properties Disable Bitmap Caching
PS : The same can also be disabled by editing RDP config file and adding or editing bitmapcachepersistenable:i:0
WorkAround 3:
Edit RDP config file and by adding or editing enablecredsspsupport:i:0
WorkAround 4:
Instead of using standard remote desktop console, try opening it in admin mode. Start->Run->Mstsc /admin
WorkAround 5:
This one has got really positive reviews by alot of users
Click on the black RDP windows (to select it) and press CTRL-ALT-END to bring up the Windows Security screen and select LOG OFF, then log back in. If this fixes the issue than it can be because of Idle connections, in which case set session time out limits as explained above in Solution 1.
Or
Click on the black RDP windows (to select it) and press CTRL-ALT-END to bring up the Windows Security screen, Then I hit cancel, then I closed RDP. Then I re-opened RDP and I had my desktop back.
Above I have tried to explain a variety of solutions and workaround I found for this issue, please try them and do update us in comments about the one which helped you. Also feel free to report any new issue where you seek expert help on fourm.
Update: Though I request you to strictly follow the above logical steps for this issue, however I found another very specific reason for this problem and have written an article about it here, please do check it out if these steps do not resolve your issue.
Latest posts by Shishir Chandrawat (see all)
- Exchange 2010 Std: Mailbox server has reached the maximum database limit of 5 Error RcrExceedDbLimitException - December 12, 2016
- Exchange 2010: Unable to add Mailbox Database copies on DAG member servers, Error: An error occurred while processing a request on server - December 12, 2016
- Unable to Mount Microsoft Exchange DAG Database, Error: Failed to determine the mount status of the active database copy - December 12, 2016
Workaround 5 resolved my issue. Thank you Very Much!!
Thanks a lot for crystal clear explanation, my issue got resolved with workaround:5 first option.
Workaround 1 works for me
Windows 10 —> Server 2008R2
This solved my problem! Not even VMware was aware of this issue.
Million times Thanks!
I have about 30 users regularly logging onto my Win2012/R2 server. Infrequently a few users get the blank screen, all together, and the only solution is to reboot, then everything is fine again. I’ve tried most solutions and they don’t apply or don’t work. I’m not sure what Solution 2 involves and haven’t tried Workaround 4. For Solution 7, is there a way of testing whether this might work, before waiting for a user to get the blank screen problem again? And will this open my server to possibly security problems?
HI Owen
Thanks for reaching out to us. What we provide on grishbi is best of our knowledge so far, if the given information is not enough to solve the issue, I request you to open a paid support incident with us by dropping an email at support@pledgetechnologies.com. We will be more then happy to resolve the issue for you
Regards
shishir
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 a freeze of the existing clients logged in and/or when you would RDP 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 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 the right direction was (A timeout (30000 milliseconds) was reached while waiting for a transaction response from the UmRdpService service.) Thank you
In this trhead I found mi partivual problem:
https://social.technet.microsoft.com/Forums/windowsserver/en-US/16d3e56f-f3fa-45ca-b657-d90c8ac104c4/server-boots-and-runs-but-cant-login-see-notes?forum=winservergen
“•Connect to registry editor remotely: If you are able to do remote registry to the problem machine, take a backup of the following registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole and delete everything except the EnableDCOM value. Restart the server.
•If remote registry doesn’t work follow the below steps:
1.Get a copy of the “C:\Windows\System32\config\SOFTWARE” hive by booting the affected system using Windows 7/2008 R2/WINRE disk.
2.After you have a local copy of the hive, keep a backup copy of the local copy.
3.Load the hive into your local registry editor as TESTHIVE.
4.Delete everything under the HKEY_LOCAL_MACHINE\TESTHIVE\Microsoft\Ole key except the EnableDCOM value and unload the TESTHIVE.
5.Rename the existing “C:\Windows\System32\config\SOFTWARE” hive on the effected system as “C:\Windows\System32config\SOFTWARE.oldfile” and copy the modified SOFTWARE hive to folder “C:\Windows\System32\config\” as SOFTWARE.
6.Let the machine reboot normally
This was the fix. “
If you don’t use Windows Server, and your Windows machine is in domain, then you might have to add “Domain Users” to BUILTIN/USERS restricted group in your AD.
2nd part of Workaround 5 worked for me, it was quick and dirty 🙂 Thanks!
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 🙂
Thank you so much, Solution 7 worked for me without having to reboot the server