2

I've recently setup RDS on Windows Server 2022 Standard Edition.

Users frequently report that when they connect, they will see a black screen and the mouse cursor, but nothing else.

enter image description here

This occurs with the standard windows client, "Remote Desktop Connection" (mstsc.exe) in addition to "Remote Desktop Connection Manager" (rdcman.exe, from SysInternals) and even FreeRDP.

Most users are able to login without issue, but seemingly random users at seemingly random times will experience the issue and retry ~2-6 times, getting black screens from the RDS client until eventually the session starts normally (with graphics and not a black screen).

There appears to be no correlation with any specific users. Some users experience it, but then the issue goes away. Some users don't experience the issue for days, but then suddenly get a black screen (myself included). There is also no correlation with the number of users connected. It can happen for the first person to connect or the 30th to connect simultaneously.

There appears to be no correlation with any time of day.

There doesn't appear to be any resource contention, the server has 40 cores/80 threads, and 512GB memory and is not virtualized (Windows Server 2022 is running on bare metal).

Windows Event Logs indicate nothing unusual in either "Application" or "System." The specific Operational log for "RemoteDesktopServices-RdpCoreTS" (found under "Applications and Services Logs" / Microsoft / Windows) is referenced in numerous Internet articles, but all I can find in here are a few instances of the following which do not seem to correlate with the black screens:

  • Warning: TCP socket READ operation failed, error 64
  • Warning: RDP_TCP: An error was encountered when transitioning from StateUnknown in response to Event_Disconnect (error code 0x80070040).
  • Warning: TCP socket WRITE operation failed, error 64
  • Warning: TCP socket was gracefully terminated

There appear to be numerous mentions of this issue on the Internet...

https://learn.microsoft.com/en-us/troubleshoot/windows-server/remote/a-black-screen-appears-while-sign

https://www.makeuseof.com/fix-remote-desktop-black-screen-windows/

https://woshub.com/rdp-black-screen-windows-remote-desktop/

https://learn.microsoft.com/en-us/answers/questions/843933/windows-server-2022-remote-desktop-black-screen?page=2#answers

https://learn.microsoft.com/en-us/answers/questions/1036988/server-2022-rds-disconnected-user-reconnect-to-bla

...

Things I've tried:

  1. Disabled RemoteFX
  2. Disabled UDP protocol (via both "Turn Off UDP On Client" and "Select RDP transport protocols")
  3. Disabled WDDM driver
  4. Disabled the URCP (Universal Rate Control Protocol)
  5. Reduced color-bit depth
  6. Updated graphics drivers to current
  7. Set physical graphics adapter to use "Microsoft Basic Display Adapter"
  8. Disabled Windows Firewall

Nothing seems to resolve the situation.

I've opened a ticket with our managed IT service provider who is at a loss. I've opened a ticket with Microsoft who is having a difficult time getting back to us.

Any help would be greatly appreciated!

Improve this question
5
  • How are User Profiles managed on this RDS environment?
    – Swisstone
    May 30 at 21:03
  • all local on a D: REFS drive. No User Profile Disks (UPD) and no FSLogix.
    – Novox
    Jun 5 at 13:57
  • If it is a black screen only on "connecting" (not after logging on) it probably is not related to profiles. I would check MTU first. A correlated packet capture on both ends would be a quick way to check.
    – Greg Askew
    Jun 5 at 22:35
  • The black screen occurs after the client has authenticated, but before the desktop displays.
    – Novox
    Jun 6 at 12:35
  • I would focus on these TCP socket errors. What kind of network connection you have there? Are there any VPN tunnels between the server and users?
    – Kamil
    Jun 12 at 12:25

2 Answers 2

Reset to default
0

Weird things will happen because you moved the User profiles folder, this is not recommended anymore on a production environment:

Important usage notes
We don’t recommend using this setting, except perhaps in a test environment.

When this setting is changed, Microsoft Store apps are not supported.

Nowadays, Windows uses Store apps as part of the system and has to provision them while loading/creating the user profile. Moving the user profile folder may prevent this step from running properly.

To overcome this situation, you may test the following steps:

  • Delete the user profiles from the User Profile control panel (do not fiddle with registry values or user profiles folders manually).
  • Move the user profiles folder back to the original location.
  • Log on to create the user profiles again. If multiple users are creating a profile at the same time, black screen may occur during a few minutes but they will eventually reach the desktop, once the profiles are created this is not something to expect anymore.

However, I'd recommend reinstalling the server and starting from scratch to avoid any leftovers/side effects.

Improve this answer
8
  • Not sure what "ProfilesDirectory" setting it's referring to, I assume GPO. What I did was manually change %SYSTEMDRIVE%\Users to D:\Users in the Registry at HKEY_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\ProfileList\ProfilesDirectory. This is concerning, "We don’t recommend using this setting, except perhaps in a test environment," but even more concerning is this on the same page, "Using drives other than the system drive:" ... "It must be on an NTFS volume." User Profiles can't reside on a ReFS drive?
    – Novox
    Jun 5 at 21:03
  • @Novox The "ProfilesDirectory" setting shown in the documentation I linked comes from the "Unattended Windows Setup Reference" "[...]provides a complete listing of all the settings that you can use to automate the configuration and the deployment of Windows" (by creating an unattended-installation answer file). I wasn't able to find any Microsoft documentation stating that you can edit the registry value you indicated. I wouldn't recommend editing this manually.
    – Swisstone
    Jun 5 at 21:29
  • @Novox About this: "User Profiles can't reside on a ReFS drive?" No, they can't. But keep in mind that user profiles can ONLY reside in C:\Users in a production environment.
    – Swisstone
    Jun 5 at 21:29
  • Most of the time, my users don't have issues with User Profiles on ReFS drive D, but they sometimes get black screens after login and need to retry login a number of times to get RDS to wake up. If there were an issue with non-systemdrive and ReFS, shouldn't I have issues all the time? Rebuilding the RDS host to move profiles back to systemdrive C: would be a nightmare.
    – Novox
    Jun 5 at 22:17
  • Swisstone, do you have other references that say ReFS is not supported for user profiles? Or are we both going off what this page says? I'm trying to make the case that a complete rebuild may be necessary
    – Novox
    Jun 5 at 22:30
0

Looks as though you got this resolved by going back to Server 2016. We had a very similar issue with 2016 RDS farm and black screens at logon - seemingly randomly. What seemed to resolve it in the end for us was to disable these 2 services.

  • AppReadiness
  • AppXSvc

We do not use metro apps only locally installed software packages.

Improve this answer
1
  • Thank you. We haven't had an issue since switching back to 2016... it's rather unfortunate we need to revert to a six year older OS to get this fixed :/ I did read about AppReadiness in my hours long scouring of the Internet for a solution, however, in those same posts, people seemed to indicate that disabling AppReadiness would eventually break windows updates. Thanks again.
    – Novox
    Jun 23 at 17:25

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .