Often we may attempt to logon to a machine and find no visible shell or Explorer.exe present. On the surface this might appear to look difficult to troubleshoot due to the lack of a shell, however a few steps can help determine possible causes and the data needed to resolve the issue. The information in this topic relates to blank desktop scenarios in non-RDP / Terminal Server sessions. If the problem that you are experiencing occurs in an RDP session, please review the information on
Blank Desktops in RDP Sessions
Scoping the Issue:
For blank desktop issues there are a couple of items we want to verify. Determine if the blank desktop is seen on startup/restart of the machine. Does safe mode or safe mode with networking show any improvements?
Is the Task Manager available and if so can you launch Explorer.exe or any other processes? If so, this will greatly facilitate the collection of data required to troubleshoot. Can MSCONFIG be used to disable third party services and start up items? You can also use the Autoruns tool from Sysinternals to selectively disable startup items.
If we see a flash when you launch explorer.exe via task manager it means that the application is either not functioning properly or it is crashing. Try looking at the Event Logs remotely and check if there are any Application errors in the Application Event Logs like Event ID 1000 and Event ID 26. If so what DLL or process is listed as failing?
Does the desktop load fine on startup only to find that after some time passing, the console/desktop becomes unresponsive and shows a blank screen preventing logon? If so this may suggest that you have a resource issue - more of an problem with the operating system as a whole as opposed to the Shell, or Explorer.exe process.
In all instances, collecting either
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:
If Explorer.exe is crashing, check to see if a crash dump has been created. If using Windows Server 2003 or older, you can open Drwtsn32.exe and check the Crash Dump path for the location. The file should typically be named 'User.dmp'. Any dumps along with the MPS Report or MSDT logs should be uploaded to us for review. For additional details on how to configure / capture application crash dumps, please see our post,
Capturing Application Crash Dumps
Backup and export the following registry key: HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon
Troubleshooting / Resolution:
After you have gathered the data, there are some things to check:
If you have captured Userenv logs, check to see if Explorer.exe is called. If it is not, then the problem may be the result of an incomplete / corrupted profile load
Review the registry key listed above for these values:
SHELL - the value should be a string (REG_SZ) value of Explorer.exe
USERINIT - for Windows 2000 systems, this should be a string (REG_SZ) value of C:\WINNT\System32\Userinit.exe. On Windows XP and Windows Server 2003 systems, the default value for USERINIT should be C:\WINDOWS\System32\Userinit.exe. However, if you have upgraded your system from Windows 2000 to a later OS, your value may still be correct if pointed to C:\WINNT.