These legendary clunkers made Patch Tuesday a living hell for Windows users the world over
17 epic Microsoft Windows Auto Update meltdowns
I still cringe whenever I read the admonition that everyone should turn on Windows Automatic Update.
While it's true that your Great Aunt Mable's PC should be set to update automatically, most experienced Windows users -- certainly, everyone advanced enough to be reading this missive -- should set Windows to "Notify but don't download," and wait until the Black Tuesday wails have passed every month.
November 2001: The UPnP patch debacle
Microsoft introduced Windows automatic updating as one of the great new benefits in Windows Me, around September 2000. A year later, we were treated to a Keystone Kops episode in the guise of MS01-059 -- ostensibly, a patch to the Windows Universal Plug 'n Play subsystem that prevented a buffer overrun. In fact, I think it was the first (though hardly the last) security bulletin conceived and scripted by Comedy Central.
Microsoft patched, repatched, and re-repatched the patch. The FBI's National Infrastructure Protection Center followed along like a kid cleaning up after his dog: NIPC issued a warning about the security hole, an update, another update, and ultimately an advisory that Microsoft had finally solved the problem.
April 2004: Windows 2000 bricked
In April 2004, Microsoft sent a slew of patches down the automatic update chute, one of which (MS04-014) locked up a sizable percentage of all Windows 2000 machines. That patch was supposed to fix a hole in the Jet Database Engine.
Knowledge Base article 841382 tells the tale:
[Y]ou may experience any one of the following symptoms:
• Your computer appears to stop responding at startup.
• You cannot log on to Windows.
• Your CPU usage for the System process approaches 100 percent.
The company sure plugged that one.
April 2006: The pretax predicament
On the April 2006 Black Tuesday, Microsoft released MS06-015, a patch for Windows Explorer. By the weekend, most Windows users with auto updates turned on got it -- right across the face. The weekend before tax day, many Windows customers found they couldn't navigate to the Documents or Pictures folder, couldn't open or save files, had to type http:// into Internet Explorer to keep it from freezing, and much more.
We ultimately discovered that the patch messed up any machine with an older HP scanner program or an older Nvidia video driver.
Microsoft's ultimate workaround (KB 918165) included a manual fix procedure that any computer-science grad would be proud to explain, if they can figure it out.
April 2006: Outlook Express killer
In the same Black Tuesday batch as the preceding screw-up, Microsoft released MS06-016, a patch for Outlook Express.
Unfortunately, many OE users reported that, after installing the patch, they couldn't open their address books; some said they completely lost all their contacts; and still others said they couldn't send or receive any mail.
Knowledge Base article 917288 gives the nine-step manual fix-it procedure: uninstall the patch, copy a WAB file (or files -- it's complicated), go to a command prompt and delete the original file, start OE, and manually import the copied WAB file. All in all, it was a fitting punishment for turning on automatic updates.
April 2006: Windows Genuine Spyware -- er, Advantage
Yep, three stinkers in one month: Microsoft uses the automatic update channel (and permissions) to install Black Tuesday security patches, as well as non-security-related patches. My favorite example came in late April 2006, when somebody at Microsoft decided automatic update would be a great way to install the new Windows Genuine Advantage, uh, feature.
That version of WGA (in addition to throwing off bogus "not genuine" messages) also installed a component called WGA Notification that phoned home -- sent information to Microsoft about the current computer -- with absolutely no notification to or approval from the customer. Lawsuits ensued. I called it Windows Genuine Spyware.
August 2006: The IE patch that created a new buffer overflow hole in IE
Let's hear it for MS06-042, the cumulative security update for Internet Explorer that not only caused IE to crash, it also introduced a security hole of its very own.
In late August, Microsoft owned up to some of the problems in KB 923762: the part where IE 6 crashes while looking at a valid website. Solution? Install the latest, greatest version of MS06-042.
Then in September, Microsoft had to reissue the patch again to "address a vulnerability documented in the Vulnerability Details section as Long URL Buffer Overflow -- CVE-2006-3873."
KB 918899 lists 15 separately identified problems with this patch, from crashes to freezes to inexplicable behavior.
December 2007: Internet Explorer crashes on sites with lots of graphics -- like msn.com
Yet another cumulative security update for IE, MS07-069 patched IE so well that many WinXP SP2 customers reported IE6 freezes on sites with many graphics. If you had automatic updates turned on and were running plain-vanilla WinXP SP2, after the patch was installed, you couldn't let IE go to the default IE6 home page, msn.com.
If you installed the patch for Internet Explorer 7, your (third-party) firewall might not have recognized IE. As a result, it may have kept IE from going out to the Internet. IE produced the marvelously informative error message "Webpage cannot be displayed."
It took weeks, but Microsoft finally acknowledged the problem and posted a downloadable fix program in KB 946627.
April 2008: Quicken suddenly stops working
Nobody seems to know why, but Microsoft suddenly released the .Net 2.0 Service Pack 1 on a Thursday, one week before tax time, via the automatic update chute. The patch itself had been available as an optional, manual download for months, but somebody flipped the auto update switch.
Within minutes, Quicken users were complaining. QuickBooks got hit, as did TurboTax and software from Commerce Clearing House.
How bad was it? If you were bit, uninstalling, then reinstalling Quick Books didn't solve the problem. You had to uninstall, then reinstall .Net 2.0 -- if you could get it to uninstall.
All through 2009, 2010, 2011: Bad .Net patches
Over and over again, we saw botched .Net patches -- some refused to install, others left .Net dead, others clobbered programs that relied on .Net. It started in January 2009 with a patch that claimed to push .Net Framework 3.5 to Service Pack 1, but didn't.
Another patch, in March 2009, also identified as .Net Framework 3.5 SP1, installed .Net Framework 2.0 SP2 and .Net Framework 3.0 SP2 as well. It was an unholy mess that had us going in circles for months.
We saw many more .Net patching problems in 2010 and 2011, all compliments of automatic update.
March 2009: The XP AutoRun blocker that didn’t
It took Microsoft forever to post a patch that disabled AutoRun in Windows XP. AutoRun, indicted as the culprit behind mass Conficker infections, deserved to die, but Microsoft's first and second attempts to talk people through the disabling procedure didn't work.
The final solution is so incredibly convoluted that pages of KB 967715 are devoted to explaining the interactions of all the patches, both delivered via automatic update and manually downloaded. It's complicated. Bottom line: If you only installed one automatic update, you might've thought that you fixed AutoRun, but you didn't. It took several patches over several months to finally get it right.
December 2010: Patch brings down Task Scheduler
MS10-092 was a rather innocuous patch, designed to plug a hole in Windows Task Scheduler.
But shortly after people started installing it, they saw messages saying, "The task image is corrupt or has been tampered with." In some cases, the task was killed. In other cases, the machine froze. Simply uninstalling the patch didn't solve the problem -- great prelude to the holiday season.
KB 2305420 has pages and pages of manual workarounds.
January 2011: A reliability update that wasn’t
On January's Black Tuesday, Microsoft pushed a nonsecurity patch into the automatic update black hole. Known as KB 2454826, Microsoft claimed it was a "performance and functionality update." Details about the patch at the time were sketchy, but the 0x7F blue screen crashes weren't.
Microsoft's advice: Manually uninstall the patch. That's your reward for turning automatic updates on, bucko.
It wasn't until the next month that we discovered the real reason why Microsoft pushed this nonsecurity patch out the Black Tuesday chute: It's a prerequisite for installing the Internet Explorer 9 Release Candidate, which Microsoft was flaunting at the time.
April 2012: TurboTax won’t print
Just before tax day -- tell me if this is starting to sound familiar -- Microsoft released MS12-025, yet another botched .Net patch.
(For the sake of brevity, I didn't bother to list separately MS10-070, MS11-039, MS11-044, MS11-066, or MS11-069, all of which were incredibly botched .Net patches.)
This particular patch kept TurboTax from printing tax forms. On tax day. #fail
February 2013: Blue screens on Internet Explorer 9
Once again, Microsoft threw a bunch of machines into a tizzy by releasing a nonsecurity patch on the fourth Tuesday of the month -- and sending it down the automatic update chute.
This time, KB 2670838, a "Platform Update for Windows 7 x64-Edition" messed with IE9 so badly that it would put a black bar on the right side of the screen. Click on the bar, and your PC died with a blue screen.
Fortunately, the fix is to uninstall the bad patch.
April 2013: More blue screens
This time, MS13-036/KB 2823324 -- a Black Tuesday security patch designed to replace a kernel-mode driver -- triggered all sorts of bogus warnings, and frequently froze machines. Primary suspects include a common IE add-in from Brazil, and Kaspersky Antivirus.
Microsoft pulled the patch, then issued a replacement patch: "Microsoft has released security update 2840149. This security update resolves the issue that was introduced by security update 2823324."
July 2013: Four outstanding, unconfirmed buggy patches
A fitting finale for this presentation: four -- count 'em, four -- automatic updates are all having major problems, and at one point, Microsoft hadn't acknowledged any of them.
The .Net Framework patch MS13-052/KB 2840628 threw out exceptions with many Microsoft programs. Its server-based relative KB 2844286 freezes SharePoint.
The MS13-057/KB 2803821 Media Format runtime patch turned videos half-black.
A Windows 8/Windows RT "servicing stack update" KB 2821895 (June) froze many machines.
Patches seem to be in place now, but it was a very troubling ride, with Microsoft mum for weeks.
August 2013: The biggest, baddest bungled batch ever
That brings us to this month and what a crop of bad patches we saw. Within 48 hours of the month's Automatic Update, Microsoft publicly admitted six Windows patches were bad and pulled four of them. As far as I can tell, that's a record -- and I've been watching Microsoft patches for more than a decade. It's not just a record for bad patches. It's a record for how quickly Microsoft acknowledged, documented, and in some cases, pulled the offending patches.
If Microsoft continues to come clean with its screw-ups -- by no means a given -- those of us who wait for patches will have a much easier job stalling on the stinkers.
Come out of the Auto Update cave and into the light
That's by no means an exhaustive list. Some problems are inevitable when you're dealing with a Windows hardware and software gene pool that looks like the La Brea Tar Pit, but I think you can draw three important conclusions:
First, patching Windows is hard.
Second, Microsoft needs to do a better job of tracking and reporting on problems as they appear.
Third, for Pete's sake, set Automatic Update to Notify but Don't Download on any machine controlled by a reasonably savvy Windows jockey.
If somebody tells you differently, point them to this list. If they're still convinced Auto Update is the way to go, ask them to refrain from dragging their knuckles on the floor.
Don’t have an account? Sign up here
Don't have an account? Sign up now