The Case of the Mysterious Blank Desktop

The Case of the Mysterious Blank Desktop

  • Comments 8
  • Likes

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.

image

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 :
Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • The answer to this one may be quite simple:  I have an old PC running Win2k Pro. I ran a ultra deep scan over the weekend- found three worms and deleted them. reconnected the cat5e to connect to the web. got the following msg: access to specific drives, paths or files denied when clicking on IE.  

    Then I rebooted and got the same message on rundll.exe and could not boot. REbooted into safe mode, checked the attributes for rundll in systems32 folder. not encrypted.  

    Now what is going on? What steps are needed to restore the system?

    Thanks!

    John Gulka

  • Prab,  How do you go about repairing this status, when the Administrator log in does the same thing.  It went down when the administrator was logged in via remote desktop.... and TS.

    All workstations can access the server fine, it is only a problem at the server console to log-in, or for any and all users via Remote Desktop, including the administrator via both access methods.

    Thank you very, very much.   John

  • Prab,  How do you go about repairing this status, when the Administrator log in does the same thing.  It went down when the administrator was logged in via remote desktop.... and TS.

    All workstations can access the server fine, it is only a problem at the server console to log-in, or for any and all users via Remote Desktop, including the administrator via both access methods.

    The Server is Windows 2003 Enterprise

    Thank you very, very much.   John (running blind)

  • Your explanation was very good on your show on the chart was also great thanks blogger

  • saol

  • I COULD HUG YOU! Thanks so much, I had no idea. This ironically occurred after a power failure, thus I attributed the problem to a corrupt user profile. It so happens I made this (dumb) change before the power failure. Adding Interactive and Authenticated Users via the local admin account worked immediately.

    Good man.

  • Thanks, a ton, Prabhakar Shettigar. You are certainly a life saver for me.

  • Old blog … but it saved me on a Win 7 machine! Thanks!