Slashdot Mirror
Microsoft Black Tuesday Patches Bring Blue Screens of Death
snydeq (1272828) writes "Two of Microsoft's kernel-mode driver updates — which often cause problems — are triggering a BSOD error message on some Windows systems, InfoWorld reports. 'Details at this point are sparse, but it looks like three different patches from this week's Black Tuesday crop are causing Blue Screens with a Stop 0x50 error on some systems. If you're hitting a BSOD, you can help diagnose the problem (and perhaps prod Microsoft to find a solution) by adding your voice to the Microsoft Answers Forum thread on the subject.'"
Someone right now is looking at that error and figuring out how to exploit it.
"If any question why we died, Tell them because our fathers lied."
I work in schools, preparing for a huge summer deployment, just re-imaged every PC on-site.
Fortunately, although I pushed the updates out over WSUS, my image was taken BEFORE patch Tuesday. Anything that hasn't been out for a least a month is in beta testing, as far as I'm concerned, and after a month it either "works" (for some definition) or something like this will come to my attention.
Have all the PC's imaged in my rooms, but only have a handful actually deployed at the moment while I test. The very first blue-screen I see, any kernel-mode patch this month will be changed to "Declined" so no further PC's get it.
Yet again, those people who get all stroppy about "you should install updates the SECOND they come out".... real life hits you again. And the downtime from a potential "zero-day" that I'll probably never witeness is nothing compared to potentially rolling out faulty updates to hundreds of PC's that would then have to be re-imaged, and/or having a faulty update inside your images forcing you to reverse changes (in my case, to pre-summer images which is a HUGE step backwards) and re-deploy.
So it looks like certain video drivers are barfing the system (itching the gdi32.dll the wrong way). If you can, roll back to an earlier system restore point, update the video drivers, then re-apply the updates again.
Life is not for the lazy.
Gee, I don't like Micro$oft as much as the next Linux Zealot, but let's be fair here...
M$ is darned if they do and darned if they don't. When they hold up patching stuff they get pillaged in the press for not getting the gaping security holes in their OS fixed soon enough. When they release stuff too soon and stuff like this happens, they get racked over the coals for not knowing what they are doing, cannot develop/test/integrate their software. M$ has ebbed and flowed on the quality of their patches in the past, they've been slow, they've released some really disruptive software. Being fair, they don't do too bad on either responsiveness or on the introduction of new bugs.
So lighten up on Micro$oft, at least on this front. Now Windows 8 metro and removing the 'start' button? Fire away at that garbage....
"File to fit, pound to insert, paint to match" - Aircraft Maintenance 101
This rollback procedure got my Win7 x64 system booting again:
From another system with the same bit width and service pack level, grab the files C:\Windows\System32\gdi32.dll and C:\Windows\System32\Win32k.sys.
Using HBCD or a similar boot disc, boot your defunct system. You can also snag the hard drive and plug it into another working computer.
BACK UP the gdi32.dll and win32k.sys files from System32 to another location just in case. Overwrite those two files in System32 with the ones you grabbed from the other system.
Your system is now bootable, having effectively rolled back the KB2982791 update. This is a quick and dirty procedure and leaves the update itself in an indeterminate state.
So happy I'm running XP right now. No patch for me.
I think the criticism isn't so much that they're too responsive to consumers or not -- they obviously listen. The criticism is that there are so many holes to begin with and that their attempts to fix things that are obviously broken -- things that their competitors seem to be able to make work just fine -- often don't work or cause other problems. Knowing the Microsoft engineering culture, their stuff is mostly a patchwork of different groups not talking to each other. In the Windows API, there are something like 17 different representations of strings depending on which engineer/department wrote the code!
When you're disorganized like that in a giant company with a giant piece of software, it's easy to see how bugs can get out of hand.
Oh, and if you are allowed a 15 round magazine, 3 out of 15 is even better!
"File to fit, pound to insert, paint to match" - Aircraft Maintenance 101
Android Linux moved a billion hardware units last year and this year surpassed the Windows all-time installed base. It is selling above 6x Windows. People using Android have never seen an update mangling this severe, but on Windows it seems a quarterly thing. This whole "Windows rules the world" thing is becoming absurd. Windows rules a small and shrinking backwater - the realm where people are willing to tolerate stuff like this.
Help stamp out iliturcy.
Yes, but that is because the developers are now required to test their own code before it goes to testing,
Well that explains things. Apparently prior to this, developers would just deploy their code without ever testing it. No wonder they had so many bugs!
Out in the real world, developers test their code before submitting it to source control. They write unit tests to verify the functionality. QA verifies that the functionality works after that, still finding bugs that weren't obvious to the developers. For example, what happens when you run code on a variety of chipsets. If you're really lucky, a SDE-T might write some of the unit tests for you.
A BSOD that only happens to some people is a great example of something that rigorous QA should catch but that developers are likely to miss. Developer testing is not a replacement for QA. They should be doing both.
The way to fix this is to delete \Windows\System32\FNTCACHE.DAT. The file will automatically be regenerated on the next boot.
(Information found on Microsoft Support Forum and used to successfully fix my own system.)
How do you delete the file if you can't boot?
(1) Press F8 during boot to get to the Windows boot manager advanced options screen.
(2) Select "Repair".
(3) Provide password for a local account that's a member of the Administrator group.
(4) Select "Command Prompt".
(5) Find drive letter assigned to Windows partition (may not be C: in the repair environment!).
(6) Delete \Windows\System32\FNTCACHE.DAT.
(7) Exit command prompt and reboot system.
(8) Fixed!
----------
And now, since this is /., here is the required Windows bashing...
This bug demonstrates the danger of running your GUI in kernel mode (win32k.sys). One stray pointer can ruin your whole day. In this case the pointer was sufficiently invalid to cause a bugcheck. A stray pointer that silently scribbles on other kernel data structures is even worse.
"Those who would give up essential Safety, to purchase a little temporary Performance, deserve neither Performance nor Safety."
The key sequence to access my Slashdot bookmark in Firefox is Alt-B-S. I don't believe this is a coincidence.