20 Windows Automatic Updates from hell
Fifteen years ago, Microsoft introduced automatic updating to the unwashed
Windows masses. Fifteen years later, it’s hard to find a Windows user who hasn’t
bumped into at least one problem with a Windows update or knows someone who has.
That’s a billion and a half people.
From inscrutable driver problems to bricked machines and everywhere in between,
Automatic Update is a poster child in “what’s wrong with Windows” circles --
rightfully so.
Hope springs eternal that Windows 10 will finally bring relief, but much depends
on the determination and deep pockets of Those in Charge. One thing’s for sure:
In the land of Win10 milk and honey, customers don’t want to be treated like
cannon fodder.
Here’s my take on the 20 worst Microsoft Automatic Update patches of all time.
Based on either the amount of pain inflicted or the number of people afflicted
-- or both -- they deserve their notoriety.
Those who cannot remember the past are condemned to repeat it.
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 Black Tuesday in April 2006, Microsoft released MS06-015, a patch for
Windows Explorer. By the weekend, most Windows users with Automatic Update
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: Windows Genuine Spyware -- er, Advantage
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)
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, but also introduced a security hole
of its very own.
In late August, Microsoft owned up to problems in KB 923762: the part where IE6
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 QuickBooks
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
installed only 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 an 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. #epicfail
May 8, 2012: Duqu patch installation failure
A massive patch known as MS12-034 (with many associated KB numbers) left
some Windows customers who used Automatic Update wondering what had gone wrong.
Some found that the installer failed with an Error Code 0x8007F0F4. When they
checked the KB 2686509 support article, they were instructed to delete a
keyboard log file. Many people couldn't find the file.
The instructions in KB 2686509 go on for pages, explaining how to modify and
move keyboard layout files -- in response to a known, anticipated error thrown
off by the installer. Microsoft finally got around to creating a Fix it that
made the patching easier. But lots of unsuspecting Windows consumers wasted
hours trying to make heads from tails out of this automatically updated
disaster.
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."
August 2013: The biggest, baddest bungled batch ever
Within 48 hours of the month's automatic update, Microsoft publicly admitted
six Windows patches were bad and pulled four of them, all associated with
MS13-066 and Active Directory Federation Services.
As far as I can tell, that's a record. It's not only a record for bad patches.
It's a record for how quickly Microsoft acknowledged, documented, and in some
cases, pulled the offending patches. We’ve seen bad Patch Tuesdays since, but
this one stands out, in both good and bad ways.
November 2013: Outlook 2013 gets special treatment
One of the patches in the November 2013 set caused no end of problems with
Outlook 2013 -- Outlook hangs when trying to sync IMAP accounts; Out of Office
replies on Exchange Server triggered "currently unavailable" messages; Free/Busy
data for the Outlook Calendar didn't download; S/MIME certificates wouldn't
validate; and more.
Unfortunately a second patch released in the November crop made it impossible to
fix all of those Outlook 2013 problems by simply uninstalling the bad patch. In
the end, users in the know discovered they could resuscitate Outlook 2013 by
uninstalling both patches, then deleting and rebuilding the Outlook profile.
Microsoft, which did so well in August -- “well” in the sense it cleaned up
quickly -- really blew it in November.
May 2014: Windows 8.1 Update won’t install, Microsoft backs off its deadline
In a scene straight out of Dante’s "Inferno," Microsoft cracked the whip and
told all Windows 8.1 users that they had to install the KB 2919355 update
(so-called Win8.1 Update 1) by May 13, or they wouldn’t get any new patches.
Predictably and with much wailing, a vocal subset of Windows 8.1 customers
discovered Update 1 wouldn’t install, for love nor money -- or anything
resembling either or both.
Quite dramatically (tell me if you can visualize the seventh ring), Microsoft
finally relented on May 12 and said it would allow the tardy minority to receive
updates -- but only this one last time.
(I think it’s poetic justice that Win 8.1 Update 2 stalled, then fizzled
completely, ultimately leading to a re-release that didn’t do much.)
August 2014: Blue screens all around, Microsoft recommends you manually yank
the patches
Four patches in August were credited with driving blue screens on Windows 7,
8, 8.1, and RT machines. Microsoft pulled the patches on Sunday, then issued a
very unusual notice, buried deep in a Knowledge Base article: Even if you
weren’t having any problem with the patches, you were supposed to manually
uninstall them.
Apparently the patches continue to cause problems, even after they were
installed, in certain unusual circumstances.
It’s a bit much to tell your Aunt Mabel to manually uninstall a handful of
patches, based on a warning in a KB article, but there you have it.
December 2014: Roughly a quarter of all the patches this month generated
problems
With only a few of the bad patches fixed before the end of the year,
December 2014 represents the worst combination of bad patches and lackadaisical
responses I can recall. In response to the unprecedented number of screw-ups,
Microsoft pulled a few patches, released two Fix its, created a Silver Bullet
patch that specifically killed one of the bad patches, and wrote up numerous
manual work-arounds.
Even at this late date, more than two months later, the problems brought down on
Excel macro programmers haven’t been fixed.
Would you say Automatic Update is getting better?
Come out of the Automatic 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 Automatic Update is the way to go, ask them to refrain from dragging
their knuckles on the floor.