I recently had this issue with a client. Where as the Workstation is running Windows 7 Pro/Ultimate. (64-bit), 4GB RAM, and is typically used as a File Server and IP Camera Monitor. Once in awhile this workstation would be used for Printing Services, so in a nut shell, this machine has its daily use in a office environment. Over the past four months, I’ve been given the scare of a dead or dying machine because of this Black Screen.
Upon first encounter, there was in fact a malware/scareware application installed that imitated the suspicions of the Black Screen. Analysis did prove the problems the workstation encountered (Pop-ups, ads, and hijacked web browsers) a toolbar, and associations with My PCBackup cloud app. After running Anti-MalwareBytes (Malwarebytes.org) most registry entries were cleared up, and reboot resulted in the Black Screen.
The malware was activated after a reboot from Windows Update. This resulted in the workstation no longer fully booting to a desktop, but network file shares, and printing were still functional. After a clean up and multiple Safe Mode attempts to repair the Blank Screen problem didn’t do any good. The End Result required a System Restore point.
Problem here is, when a workstation only reboots/shutsdown, once in awhile. So it could be months/weeks when a malware injects itself into a Start Up Entry in the Registry. In my client’s case, it was only two weeks. Now at this point, once a System Restore successfully gets our desktop back, and all applications are now running normally. We re-encounter the problem, the following month. The second month I had to deal with this same issue, however this time, with the less fear of an actual infection, but more of a Windows Update problem. This time, in less than 35 minutes, a System Restore to the day prior to the “Patch Tuesday” Windows Update, we are back online. However this time, I’m guessing as to which patches are the culprit of the Blank Screen issue. The Events Viewer doesn’t show anything other than a reboot and some updates successfully installing, then a reboot, and now we have a Blank Screen. I disable various patches, and fingers crossed.
Third month in a row, Patch Tuesday happens, and yet here we are again. However, this time I have a “Agent” that runs on my client’s workstations I support, that gives me telemetry on the health/settings of the machines the Agent is online with. This time, I’m greeted with a clue to my problems.
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:
Note 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?):
My 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).
This did in fact work.
However the Official answer Microsoft will have is,
1) Reboot and press F8
2) Select “Repair my computer”
3) Select the keyboard layout and lanugage
4) When you reach system recovery tools, select System restore.
5) Select the restore point when it was working fine and restart the computer.
If you do not have the system restore points, try startup repair.