BLANK DESKTOP IN RDP SESSION
Description: A Terminal Server session can also be defined as remote access to a desktop. When creating a session to a Terminal Server/Remote Desktop Server there are a several stages of the connection process that must be successful before the user can interact with the session:
- Initial connect on port 3389 and negotiation of the session
- Licensing
- Logon/authentication
- Loading the user profile
- Loading the shell (desktop) or application that will be run as the shell
This document will discuss scoping, data gathering, and common troubleshooting for problems with the 5th step in the session creation process, otherwise known as a Blank Desktop in a Session or a failure to load the shell. The description also comes from what the user sees on their screen, which is normally a blank desktop background.
Scoping the Issue: There are normally 2 ways to scope this kind of issue based on whether the user is running a standard full desktop session, a published application (Windows Server 2003), or a RemoteApp (Windows Server 2008).
Full Desktop Session: In this scenario the blank desktop is normally caused by a failure to start the shell (explorer.exe), which means the session is created but something happened when trying to load explorer.exe. Focus the troubleshooting on the shell itself and why it would not be starting for the user.
Published Application or RemoteApp: In Windows Server 2003, the shell could be replaced with an application such as outlook.exe and there is no desktop loaded in the session. This is accomplished by using the “Start the following program on connection” setting in the RDP client, the user properties, or by setting a group policy. Windows Server 2008 added the ability to run RemoteApps, where the shell (explorer) is replaced with rdpshell.exe and the application is remoted back to the RDP client so that it appears to be running on the local desktop.
The appearance of a blank desktop is more rare in this scenario but it is possible that an application could hang or fail to start and leave the session in a state where a blank desktop is seen. The main difference here is that with published applications and RemoteApp the user is not supposed to see a desktop so if the application that is being published does not run then the issue is likely with the application itself and not the shell.
Data Gathering: In all instances, collecting either MPS Reports with the General, Internet and Networking, Business Networks and Server Components diagnostics, or a Performance-oriented MSDT manifest must be done. Additional data required may include the following:
- A USERENV log (Windows Server 2003) or a GPSVC log (Windows Server 2008)
- A list of running processes for the session when the problem occurs. The easiest way to do this is to run Terminal Server Manager and look at the session ID for that user and list the processes using the Processes tab.
Troubleshooting / Resolution: Troubleshooting will depend on which problem you are experiencing:
Blank desktop with a full desktop session
- Look at the processes running in the session and determine if explorer.exe is running or not. If it is running but the user still does not see a desktop, it is likely hung or cannot initialize. To narrow the problem down a little more, try logging on an administrator or logon to the local console of the Terminal Server and see if explorer.exe loads and the desktop is displayed.
- If any patches or updates were applied recently, try removing them one by one and testing the logon again to see if removing a specific patch resolves the problem.
- Boot the server without non-essential services using msconfig and test the logon again.
Blank desktop with a published application or a RemoteApp
- In this scenario, troubleshooting is the same as the full desktop session, except you would focus on the application itself and not explorer as the application is replacing explorer.exe as the shell.
- Contact the vendor for the application and determine supportability of the application in a Terminal Server environment and ask specifically if the application is supported as a published application or a RemoteApp.
- If the application is a Microsoft supported application, your support engineer will assist you in contacting the correct support team.
Additional Resources:
Microsoft