I've seen plenty of Microsoft patching cluster-flubs, but this one takes the cake.
On this month's Patch Tuesday, Aug. 9, Microsoft released a couple of security patches for a hole in kernel-mode drivers. Dubbed MS16-098, the patch came in two flavors. KB 3177725 patched the security hole in Windows Vista, 7, 8.1, Server 2008 R2, 2012, 2012 R2, and RT 8.1. In addition, KB 3176492, 493, and 495 fixed the same hole in various versions of Windows 10.
Unfortunately, as I pointed out two weeks ago, the patches all have the same bug: They break certain print routines that involve printing multiple times. The details are a bit thick, but if you run the BarTender bar code/label printing product from Seagull Scientific, for example, you'll find that the patches make the program unusable after printing two labels. Ditto with combit's List & Label. Many homebrewed line-of-business apps don't work. The patch killed many different approaches to bundling multiple print jobs.
The first public warning about the bug appears to have been posted by Kristan G on the Microsoft Answers forum on Aug. 12. The Microsoft employee who first responded blamed the printer manufacturers for bad drivers. Shortly afterward, a second Microsoft employee stepped in with a "we're working on it" response, and the KB articles were all updated with this Known Issue:
After you apply this security update and you print multiple documents in succession, the first two documents may print successfully. However, the third and subsequent documents may not print.
That's where things turned all Rube Goldberg.
Microsoft released a fix for Windows 10 on Aug. 19. The patch -- KB 3186987, called the "Cumulative update for Windows 10: August 19, 2016" -- is an odd bird. Its KB article claims the patch supersedes the cumulative update that contained the bad patch, KB 3176492. But if you look at the Windows 10 update history page, there's no mention of an Aug. 19 patch. There's no change in the update numbers or in the OS build version numbers. There's only been one cumulative update issued since Aug. 19 -- the Aug. 23 cumulative update for Win10 version 1607 -- and the description there doesn't mention print fixes.
If there's been a change to the cumulative update for Win10 version 1511 since the Aug. 9 printer-busting patch, I haven't seen it.
I have no idea what's going on, and the KB articles for this security patch provide no clue. Perhaps Microsoft slipstreamed the fix into the current cumulative updates for Win10 1507, 1511, and 1607. Perhaps 1607 has been fixed, but the fix has not been documented. Perhaps KB 3186987 has been blowing smoke for the past 10 days.
Over on the other side of the fence, Microsoft released a fix for Windows 7, 8.1, and the Servers (but not Vista) on Aug. 23. It's called KB 3187022 -- but as of early Monday morning, you won't find it on your Windows Update listing. This isn't a hotfix, it's a bona fide Windows Update patch. I know because it's listed as an Aug. 24 release on the official Windows Update list. But as of early this morning, none of my Win7 or 8.1 PCs show the patch as available for download. Sure, I can go to the Windows Update Catalog and apply the patch manually, but then what happens when it's released "for real"?
If we were talking about a fix for Azerbaijani Manat currency support, we could laugh and forget about it. But this goes right to the core of cumulative updating and how Microsoft recovers from a botched patch. Heaven knows we've had a lot of them. Office Click-to-Run is plagued by problems, with significant bugs in December, two in February, one in April, one in June, and another in August. Cumulative updating may have its benefits, but it's strictly a one-way street.
It's time for Microsoft to provide answers about its patching policy. The question is straightforward: When Microsoft releases a security patch that contains a significant bug, how will Microsoft fix the problem?
It's the same question I've been asking for the past 18 months, and it's time we got some answers.
The next patching problem may not be so benign.