Whenever someone starts dissecting problems with Microsoft updates, people always want to point fingers: Microsoft did this wrong, software manufacturers did that wrong, and IT departments and/or users obviously screwed up something in the middle.

The problems were so pervasive and inscrutable that a week later I issued a call to help Microsoft fix the patch. Dozens of you responded, and several of you worked with Microsoft to try to identify the source of the problem.

Turns out, there were several sources of problems.

The easiest ones were bugs in games (Rift, Defiance) that somehow hooked into the Windows kernel. The game developers produced a fix shortly after the problem appeared -- and apparently they've learned it isn't nice to hook straight into the kernel. Imagine that.

The second set of problems cropped up when Windows tried to execute certain 32-bit programs on some machines. As I explained in August, the programs triggered an Error 0xc0000005. One Answers forum poster said, "it's not possible to run almost all applications include IE, Personalize screen, components from control panel and many other 'native windows features and applications."

The KB 2859537 article now says, "This problem can occur when the system has an instrumented version of 'ntoskrnl.exe' installed. We do not support this scenario."

Certainly Microsoft isn't responsible for checking every detail of every copy of ntoskrnl.exe that it tries to replace. Still, I bet we'll see more effort made in the future -- especially with kernel replacements -- to identify pirate versions of Windows and bail before the installer munges the system.

The most perplexing, elusive problem with KB 2859537 triggered a STOP 0x6B blue screen. The KB article talks through a complex scenario, but the problem seems to boil down to missing Registry keys -- or as Bradley says, "by some Registry corruption that already existed in Windows." Three specific keys are identified in the HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\SideBySide\Winners node: two for x64 systems, one for x86 systems. If any of those keys are missing when the patch is installed, all hell breaks loose. "Be aware that the corruption would have existed before the security update was installed. The corruption is not caused by the security update."

I can only think of three ways those keys could be missing. Perhaps you were running through your Registry and decided to delete a few keys. Maybe you installed a rogue program that somehow managed to clobber the keys. Or maybe -- just maybe -- you ran a Registry cleaner that decided the keys weren't worth keeping. Kerplop.

Again, you can point fingers at Microsoft for not having the installer die gracefully when the keys are missing, but I'd be willing to bet that the BSOD is actually caused by a complex series of interactions that only tangentially involve the keys.

No matter whom you blame for the incidents, there's no question that Microsoft could've done a better job of preventing them, in some cases -- and that some third-party system level software can have far-reaching, deleterious consequences.