We recently had an issue where out of nowhere, end users started indicating that their logins to our terminal server were just showing a "blank screen." After checking the usual suspects -- profiles, shell=explorer.exe in the registry, userinit.exe, etc. I thought I would pass on the ultimate culprit in hopes of saving time.
But also of note, it was reported that if the user waited long enough (10-20 mins), the desktop would load.
Using a combination of Taadmin.msc (Win 7/Vista) or Terminal Services Manager and PStools, I was able to narrow down and eliminate the problem. -- explorer.exe hung due to gpscript.exe being stuck at login Here is what I did:
1) When a login was stuck after "Preparing Your Desktop," I used Remote Desktop Services Manager to view the current users, sessions, and processes that were running.
But also of note, it was reported that if the user waited long enough (10-20 mins), the desktop would load.
Using a combination of Taadmin.msc (Win 7/Vista) or Terminal Services Manager and PStools, I was able to narrow down and eliminate the problem. -- explorer.exe hung due to gpscript.exe being stuck at login Here is what I did:
1) When a login was stuck after "Preparing Your Desktop," I used Remote Desktop Services Manager to view the current users, sessions, and processes that were running.
2) Using the command from the PS Toos Suite (Which you can download)
pslist \\<name of device stuck user is logging into> <name of process> /<switches> (-s will show real-time)
example: \\terminalserver1 explorer -s
Use escape key to end the command and go back to prompt
I was able to return the number of instances of explorer running and the PIDs associated with them. I was then able to match the PID against those sessions of explorer seen -- I had 6 users in and only 5 instances of exolorer.exe
3) Noted that the user with the hung desktop was seen as an "active" user but did not have an instance of exlorer.exe tied to their session.
4) Reviewed the processes running tied to the stuck user, and noted that the following were the only processes running: rdpclip.exe, taskeng.exe, net.exe, and gpscript.exe -- which turned out to be the culprit.
5) Using another PS Tool (part of the suite) PSKill I was able to then kill the gpscript.exe instance
Syntax: pskill <UNC of server running process> <PID of process to kill>
Example: pskill \\terminalserver1 13224
This would kill the explorer.exe instance with PID 13224 from the screenshot in Step 2
This immediately ended the hung desktop and displayed the users desktop and icons for them.
NEXT STEP – DETERMINED WHAT GPSCRIPT.EXE was attempting to do when it hung –
- GPScript.exe is most commonly responsible for executing logon scripts
- Mapped Drives
- Personal Drives
- Printers
Going to Group Policy Management Console – I edited the Policies that would apply scripting to my terminal server users – I wanted to make the scripts visible at login so I could see what was potentially hanging up – Set this to enabled
Upon Logging into the terminal server again (after applying the policy – I noted that the script had run but was waiting for a response to a prompt –
- This was caused by an error in the previous admin’s code – there was a double delete essentially and the second delete was displaying a “there is nothing here to delete – continue? “ type prompt –
- This is key to the blank desktop because the users are not going to see this prompt normally because login scripts run invisible – this would mean that the prompt would have to “timeout” essentially before gpscript.exe would quit and then allow explorer.exe to load – presenting the logged in user with their desktop.
- After correcting the root cause – the error in the admin script – the issue ultimately was resolved – however it is my hope to save others time and frustration by some helpful hints in the event this happens to you.