Score:1

Windows Server 2022 RDP / RDS Black Screen When Connecting

ru flag

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!

Swisstone avatar
cn flag
How are User Profiles managed on this RDS environment?
Novox avatar
ru flag
all local on a D: REFS drive. No User Profile Disks (UPD) and no FSLogix.
cn flag
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.
Novox avatar
ru flag
The black screen occurs after the client has authenticated, but before the desktop displays.
Kamil avatar
it flag
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?
Score:0
cn flag

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.

Novox avatar
ru flag
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?
Swisstone avatar
cn flag
@Novox The "ProfilesDirectory" setting shown in the documentation I linked comes from the ["Unattended Windows Setup Reference"](https://learn.microsoft.com/en-us/windows-hardware/customize/desktop/unattend) _"[...]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 avatar
cn flag
@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.
Novox avatar
ru flag
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 avatar
ru flag
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 avatar
ru flag
Is Windows Store even installed on Windows Server 2022? What if I wipe all user profiles from D:, deleted partition D: and moved folks back to C:\Users
Swisstone avatar
cn flag
@Novox "do you have other references that say ReFS" => No. If it's not documented then it's not supported. They won't document every unsupported combinations. About Windows Store: Store apps are in fact Appx Packages: I don't think Windows Store is available on Windows Server 2022, however, built-in system apps are Appx Packages ("Store apps").
Novox avatar
ru flag
I never got this resolved. Like numerous others on the Interwebs, I had to rebuild the whole RDS server with Windows Server 2016.
Score:0
bo flag

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.

Novox avatar
ru flag
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.
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.