Perhaps I should’ve used a different headline for this post. Something like “InfoWorld’s conspiracy to derail the Windows 7 product launch”. But that would be giving in to exactly the temptation I want to highlight— the one many bloggers, writers, and editors fall victim to, or otherwise find hard to resist in the quest for more pageviews.
Somewhere in the blogosphere, someone reports a “critical Windows 7 bug“. One tech writer sees it as a “catastrophic bug” in Windows 7 which could “derail the Windows 7 launch”.
Although the writer didn’t discover the bug, and I’m not quite sure if the headlines are the writer’s own or the handiwork of an over-zealous editor, but the outcome is an article with a sensational headline that screams for attention— Critical Windows 7 bug risks derailing product launch.
The sub-headline is equally interesting: An apparent fatal flaw in the NTFS driver stack may bring Microsoft’s Windows 7 impending victory parade to a grinding halt.
What’s wrong with Windows 7? In the writer’s words:
The bug in question — a massive memory leak involving the chkdsk.exe utility — appears when you attempt to run the program against a secondary (that is, not the boot partition) hard disk using the “/r” (read and verify all file data) parameter. The problem affects both 32- and 64-bit versions of Windows 7 and is classified as a “showstopper” in that it can cause the OS to crash (Blue Screen of Death) as it runs out of physical memory.
Sounds like a serious security vulnerability, and the writer suggests it is exactly that.
Also worth considering: This command can be executed in a nonelevated context under the looser Windows 7 UAC implementation (Vista requires elevation of this command via the normal user consent dialog before continuing). Not only is this a potentially catastrophic bug from a functional standpoint, it also opens up a new attack vector for malicious code. Hackers may be able to use this unprotected command to destabilize a system (by consuming almost all available RAM), and in extreme cases, cause it to fail altogether.
As reported, Microsoft has not been able to reproduce the bug.
I waited till I actually had the RTM code, and had the time to install and try this out on a couple of computers. Not only have I not been able to reproduce the blue screen, but as you can see in the following screenshot, UAC actually does prevent you from running chkdsk! And this is plain vanilla Windows 7 RTM with no updates, hotfixes, or changes to UAC settings.
The writer’s implication of this being a catastrophic bug that opens up a new attack vector is not true. The command is not “unprotected”— Windows requires an elevated prompt to run chkdsk.
I also ran the command with an elevated prompt, and failed again! Chkdsk did consume a fair amount of available memory, but nowhere close to the “massive amounts of memory” reported by the writer. Needless to say, the much feared blue screen of death (BSOD) was never encountered. (As a sidenote, I’ve not seen a blue screen in a long time. The last time I saw it was when I knowingly installed an unsigned driver, bypassing Windows’ warnings urging me not to do so! When was the last time you saw one?)
On further testing, I also noticed that chkdsk graciously released memory when the system required it for other tasks, such as running other programs [see screenshot]. This is not very different from how Exchange Server has historically behaved as far as memory consumption goes. Some tasks require more memory, and if more memory is available, perhaps it’s intended to be used at some point?
As a more-than-reasonably-technically-savvy user, I do not recollect running chkdsk more than once or twice in almost a decade. Yet, a so-called bug that can’t really be reproduced easily— or reproduced at all, somehow becomes a catastrophic bug that “risks derailing product launch”. Noted author and ZDNet columnist Ed Bott responds with A killer Windows 7 bug? Sorry, no. Ed explains further why this is not at all what it’s made out to be.
In an unusual response, Windows division president Steven Sinofsky left a comment on the blog that reported this issue. Says Sinofsky:
While we appreciate the drama of ‘critical bug’ and then the pickup of ‘showstopper’ that I’ve seen, we might take a step back and realize that this might not have that defcon level.
And as you may have guessed, that got faithfully reported by InfoWorld in Windows president tries to calm fears of critical Windows 7 bug. Yet another headline for InfoWorld, and no questions asked about who stoked the fear to begin with.
[Update: Steven Sinofsky explains how Microsoft deals with bug reports, partially in response to this issue. Read What we do with a bug report? on the Engineering Windows 7 blog.]
Having had my own brush with InfoWorld editors and writers in the past (Details in “Save XP” Campaign: InfoWorld responds, and the facts about downgrade rights), all I can say is— it saddens me to see what used to be a well-regarded technical journal for geeks (and still has some excellent experts and writers I admire) accelerate its pace towards becoming the MAD magazine of tech journalism.