The Case of the Mysterious Blank Desktop

Hello folks, Prabhakar Shettigar here once more with another odd case from the trenches.  Recently my colleague Sumesh wrote about how Not All Systems Are Truly Equal.  Following on from his post, I thought I’d share some interesting anecdotes about a couple of strange cases I worked involving one of our more common Desktop Shell issues that we see on the Performance team – the dreaded “Blank Desktop”.  I’m sure most of you have run into this at one time or another – you’ve entered your credentials and … nothing but a pretty blue screen.  Now, these issues can be somewhat frustrating to troubleshoot under the best of circumstances, but in this particular instance, the problems began long before the user tried to log on …

Once upon a time there was an Administrator who had to deploy hundreds of desktops to his respective organizations.  He told that the deployed desktops should be running Windows Vista and should have all the common user business applications installed and ready to go when the user received their machine and logged on.  Our administrator duly created a new image and deployed it to his first group of users having first pre-staged the computer accounts in his Active Directory.  All appeared to be going smoothly, until … the first user logged on with their domain credentials.  Nothing.  No icons, no taskbar … nothing.  A beautiful blue background was all that he was presented with.  The system was present on the network, had applied the requisite group policy settings, on the surface – all seemed well.  What happened?

After some fairly straightforward troubleshooting, we discovered that during the build process the administrator had disabled User Account Control (UAC) in the interests of saving time when installing applications.  When the systems were joined to the domain, the domain policy was set to enforce the use of UAC.  In and of itself, this wouldn’t seem to be an insurmountable issue … except that somewhere down the road, there was a second change made to the system – the one that ultimately caused the issue.  Before we get to the real culprit, let’s quickly review some of the architecture pieces of UAC.  The excerpt below is taken from an MSDN Article – Understanding and Configuring User Account Control in Windows Vista.

While the Windows Vista logon process externally appears to be the same as the logon process in Windows XP, the internal mechanics have greatly changed. The following illustration details how the logon process for an administrator differs from the logon process for a standard user.


When an administrator logs on, the user is granted two access tokens: a full administrator access token and a “filtered” standard user access token. By default, when a member of the local Administrators group logs on, the administrative Windows privileges are disabled and elevated user rights are removed, resulting in the standard user access token. The standard user access token is then used to launch the desktop (Explorer.exe). Explorer.exe is the parent process from which all other user-initiated processes inherit their access token. As a result, all applications run as a standard user by default unless a user provides consent or credentials to approve an application to use a full administrative access token. Contrasting with this process, when a standard user logs on, only a standard user access token is created. This standard user access token is then used to launch the desktop.

This all seems fairly straightforward, but what exactly does it have to do with our scenario?  What had happened here was that there was a new policy in place that had modified the Users group on the new systems.  Authenticated Users and the NT AUTHORITY\INTERACTIVE account had been removed from the group.  We discovered this from the output of a GPRESULT scan.  Under the section titled “The User is part of the following security groups”, neither NT AUTHORITY\Authenticated Users, nor NT AUTHORITY\INTERACTIVE was listed.  A comparison of this result to a working system verified that this was the problem.  When a domain user tried to log on,  since they were not directly part of the the Users group had no permissions to … well, anything.  Remember that even for administrative accounts on Windows Vista, a split token is created when UAC is turned on.  If UAC is disabled, an administrative account only has a full privilege access token.

After determining the issue, the resolution itself was relatively straightforward – put Authenticated Users and NT AUTHORITY\INTERACTIVE back into the Users group and all was well.  I know that seems like a bit of an anti-climax, but oftentimes the strangest problems have some fairly simple solutions.  Take care!

– Prabhakar Shettigar

Share this post :