Contest: Why Is This Desktop Empty?
I just had a situation where I was facing an empty desktop with no way to logoff, start a program or do anything else. The only thing left to do was to log the session off from an admin session. This got me thinking: how many ways are there to create such a situation? I am writing down all the ways I know of and ask everybody to contribute. Can you come up with a way to end up with a completely empty desktop I and no one else thought of before?
This is what I am talking about:
My Solutions
Explorer Killed
If you kill Explorer and have no other graphical application running, you are left with a blank screen.
Please note that if the shell is not stopped manually but crashes instead, it is restarted by default. This is governed by the registry value AutoRestartShell.
Custom Shell Closed
You can specify a custom shell through the Group Policy setting Custom User Interface. Such a shell is run on top of the default background – and can be closed by pressing ALT+F4 or by clicking the red cross in the application’s upper right corner (if available). After closing the custom shell application all that remains is the background.
Nice Try, But Does Not Work
Configuring an Invalid Custom Shell
This is tempting, but the developers at Microsoft are not stupid enough to fall for this one: specifying a custom shell through group policy that does not exist; in other words, specifying something like kasjdfljskdf. If you do that, the regular shell (Explorer.exe, of course) will come up.
6 Comments
Hide desktop shortcuts, no wallpaper, make all of the UI elements the same colour (Windows classic required, of course).
Folder redirection gone bad? If I remember correctly I saw this issue when the Desktop folder is redirected to a non-existing folder.
This is a fun one, I’m sure there are lots of options here!
Of course, there are the custom Shell values for the Current User, the equivalent in HKLM, as well as both of their equivalents via Group Policy. Then there are also the UserInit values in the same HKCU/HKLM spots that can hijack things as well. I’m not sure if you can Group Policy the UserInit values.
And then I suppose instead of those values directly you can always sneak in via Image File Execution Options.
UserInit is otherwise also fun because you can trip things up a myriad of ways with the logon scripts it processes.
You can hijack things with RunOnce\Setup as well. If I recall correctly, it halts the boot process when processing those.
I’d also bet that you can interrupt things with ActiveSetup values, though I’m not sure if you could hide the ActiveSetup processing dialog.. Would be fun to see!
I’ve certainly seen that issue when there were mapped drives or scripts trying to hit a network share that was slow or otherwise couldn’t be reached. I’ve also seen that issue when the machine was set up to output to multiple monitors with the actual monitor configured as the secondary display. Ah, the days before Aero Snap.
Then there are other more ridiculous options.. With XP you could corrupt the activation data and hijack msoobe.exe. XP tries to launch it to fix things but will launch whatever’s there. You can hijack the .exe // exefile values in HKCU or HKLM to interrupt there. You could certainly interrupt things with an Explorer shell extension and/or a DLL lodged in AppInit.
Dunno… There are tons of possibilities!
replace userinit with a custom executable that crashes.
hidden log in script with a pause in it.
place an entry in userinit that doesnt close.
oh and a custom shell that closes (return 0) will not relaunch even with the registry key applied.
A
Too easy ;-)
Set rundll32.exe as shell…