This isn't an authoritative answer - I've just had this problem, sifted through the initial bogus media coverage, found a solution, and started speculating on the real cause.
Here's a workaround for the problem, though this company mis-diagnosed the problem (it wasn't an ACL problem). This fix is opaque and comes from a third party, but it fixed the problem for me:
http://www.prevx.com/blog/140/Black-Screen-woes-could-affect-millions-on-Windows--Vista-and-XP.htmlNote their fix is an exe and they don't tell you what it does. I appreciate that they are helping, but they should fully disclose their fix so at least advanced users can have confidence in their good intentions.
Here's a better possible reason for why the problem occurred (a registry key telling
Windows which shell to run on login was corrupted - a REG_SZ key was missing a '\0'. Sounds somewhat plausible, but the fishy part is what caused that?):
http://www.prevx.com/blog/141/Windows-Black-Screen-Root-Cause.htmlMy symptoms & observations:I ran into this problem on a Win7 laptop that was upgraded from
Windows Vista Ultimate. I log in, get a black screen, and
Windows never proceeds to setting up my desktop, etc (ie,
Windows never launches explorer). Running the fixing tool from Prevx did solve the problem, however their diagnosis for the cause of the problem was wrong (their initial hypothesis was the ACL's were incorrect and implied
Windows Update patches broke it, but that was wrong. They followed up with the non-null-terminated string hypothesis). Before running Prevx's tool, the registry key existed, RegEdit visually displayed the expected value (explorer.exe), and the ACL's were fine. Yet, of course, I couldn't successfully log in.
My pure speculation about the cause:So if the missing '\0' hypothesis is correct, and if the Prevx tool deletes & recreates the value in the registry key, obviously that should fix the problem. (FYI - look at the MSDN docs for RegSetValueEx for a note about the lpData parameter needing a '\0'.) But that doesn't explain how the value got messed up in the first place - I don't go around removing terminating zeros from REG_SZ values for fun nor profit. Sounds like either random corruption, or more likely, something wanted to run something when Windows boots then incorrectly undid their change to the registry.
I saw that some MS security folks suggested this could be caused by malware (
http://blogs.technet.com/msrc/archive/2009/12/01/reports-of-issues-with-november-security-updates.aspx). Operating under that hypothesis, I ran Forefront on Wednesday using the current signatures, but it didn't report anything. That may not spot a novel virus or rootkit, of course.
Another wild guess - perhaps the act of installing certain classes of patches could cause the problem, due to a (hypothetical) bug in
Windows Update.
Windows Update does something on boot up to configure patches, and it looks like this happens after login but before Explorer is running. Perhaps
Windows Update itself could be editing this registry key to replace the shell with another program that configures patches (or options to explorer.exe?), then replaces the registry key again to point back to explorer after patches have been installed? If that's how it works (which is a big guess), then maybe when WU restores the registry key value to explorer.exe, it doesn't reset this reg key appropriately on Win7. Of course, I would have expect to see a bad value for this reg key in RegEdit if this were the case. I didn't - perhaps there were some unprintable characters in the string, or I've empirically shot down my own wild guess.
Note - my problem occurred on a
Windows 7 Ultimate machine that was upgraded from Vista Ultimate. Perhaps something during upgrade may have introduced some registry corruption that didn't show up until another value in the registry was changed later?
BTW, to confirm the fix & narrow down this fix, perhaps someone w/ a broken machine can reboot into Safe Mode, run RegEdit, delete HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell then recreate the Shell key as a REG_SZ key, with the value explorer.exe. If that works, that could help confirm the cause and allow us to give standalone instructions for a fix that we can have more confidence in (as opposed to telling people to run an exe from a third party).
