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.'"
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.
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
Oh wait, I'm on Linux.
Which distribution? I have had issues with Linux patches too.. Not as often as with Microsoft patches, but problems none the less.
"File to fit, pound to insert, paint to match" - Aircraft Maintenance 101
That's because it broke through normal wear and tear. If someone from Ford came out to your house one night and swapped parts and as a result your formerly running car wouldn't start in the morning, you would certainly be entitled to compensation for your time and trouble as well as a fix fro your car.
If it doesn't work right because of something MS did and they then leave him to fix it, why not?
I'm pretty sure MS insists on being paid for each and every install of Windows.
Since you were perfectly free to not reply at all, you're an unpaid volunteer.
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.