Users find fix for botched KB 2982791 and KB 2970228 Windows update

Microsoft has yet to pull the bad patch, respond to support cases, offer an explanation -- or even acknowledge the BSOD Stop 0x050 problem

Seems like business as usual in the Microsoft Black Tuesday support arena. Windows customers -- not Microsoft -- have found a solution to the Blue Screen of Death/Stop 0x50 error I talked about yesterday. Microsoft, as usual, has been totally AWOL.

The bad patch went down the Automatic Update chute on Black Tuesday, and the first report of a BSOD appeared on the Microsoft Answers forum on Wednesday. The report correctly identified one of the botched patches as KB 2982791. It isn't clear how many people are affected, but reports are springing up all over the Web. As of 1:30 a.m. Friday, Redmond time, it doesn't look like Microsoft has done a darn thing.

According to forum moderator and Microsoft MVP Susan Bradley (who, like all MVPs, is a volunteer) the problem has shown up on 64-bit Windows 7 systems and possibly 64-bit Windows Server 2008 R2 systems ("possibly" because there aren't enough reports as yet to corroborate). The first bad patch, KB 2982791, is part of the "important" MS14-045 security bulletin. The second bad patch, KB 2970228, is a nonsecurity patch, part of the "Update 2" debacle, that adds the ruble glyph to the list of valid currency symbols in Windows 7 and Windows 8.1 Update.

As of this morning, Microsoft has not acknowledged the problem on the Microsoft Answers forum. I've seen no communication from Microsoft about the problem. All of the submitted Microsoft support tickets that I know about have yet to be acknowledged. There's no mention of the bug in either KB article. On all of my Windows 7 x64 machines, KB2982791 continues to be offered as a "checked" Important update through Windows Update, and KB 2970228 remains an "unchecked" Optional update.

Windows sleuth and first-time Microsoft Answers forum poster rvuerinckx found the magic combination:

I had the same problem on two computers, both win7 64bits.

I could solve it by booting from a DVD and removing the following file:

c:\Windows\System32\FNTCACHE.DAT

Based on his post, it looks like rvuerinckx took a brute-force approach, deleting font caches until he obliterated one that sprouted the Blue Screen.  I have no idea if his hack works in all cases, but every report I've seen so far says it works like a champ.

What's happening? Nobody knows. Microsoft has had about 60 hours to respond, and we've heard nothing. Poster PortSix adds a tantalizing clue:

For us, it appears that the blue screen crash is related to GDI calls to SaveDC() and RestoreDC() to preserve and restore a path.

FNTCACHE.DAT, as its name implies, is a font cache. A quick trip through Google reveals all sorts of problems with the file over the course of many years. In all cases, as best I can tell, Windows is smart enough to rebuild the cache if it gets deleted -- but it isn't smart enough to reconstruct the cache if there's some sort of internal problem. You might reasonably wonder why/how a font cache, of all things, could freeze Windows on boot after a 100 percent genuine automatic update patch.

I continue to stump for my Patch Monday proposal, first put forth last September. Microsoft should invite anybody and everybody to participate in a voluntary day of testing for new patches before they're released through Windows Update and WSUS. This is yet another example of a bad patch -- or two -- that could've been caught with enough outside testing.

How can Microsoft ask us to buy into the idea of "more nimble" monthly updates to Windows, when it can't nimbly respond to system-crashing screwups in its own automatic patches?

This story, "Users find fix for botched KB 2982791 and KB 2970228 Windows update," was originally published at InfoWorld.com. Get the first word on what the important tech news really means with the InfoWorld Tech Watch blog. For the latest developments in business technology news, follow InfoWorld.com on Twitter.

Recommended
Join the discussion
Be the first to comment on this article. Our Commenting Policies