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.
Figure 1: UAC prevents running chkdsk /r on a computer with Windows 7 RTM.
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?)
Figure 2: Chkdsk consumes a fair amount of memory, but nowhere close to 90%. It graciously releases memory when required for other tasks.
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.
{ 11 comments… read them below or add one }
Hey Bharat, last time I saw a blue screen? Same as you – messing about with graphics card drivers on the Win 7 RC!
But on a more serious note, your article highlights something I've found is sadly creeping over from mainstream "journalism" into the tech news space. Case in point, another non-story that appeared here in Australia yesterday morning: http://www.itnews.com.au/News/152480,windows-7-upgrade-path-looks-rocky.aspx. As the commenters rightly point out, it's unlikely that any corporate environments will perform an in-place upgrade, so the story, with its tilt at enterprise news, becomes another piece of sensationlist fluff. You'd think there'd be better things to fill up a webpage with, but I guess the alarmist tack must sell. (Well it got me to open it, didn't it?!)
Cheers
Dan
I stopped reading InfoWorld when they went digital-only over 2 years ago after being a longtime subscriber.
Was the author able to reproduce this 'bug' on multiple systems?
Oh ya, and BSOD yesterday on Vista on an eMachine.
@Dan: Thanks for pointing out – similar articles have been carried in many tech publications.
@William: On 3 systems, including 1 VM.
FWIW, UAC *doesn't* prevent you running chkdsk on a vanilla Windows 7 install. Type chkdsk /r into this proof-of-concept app and click the button to see it launch chkdsk elevated without a UAC prompt (if you're using the default Win7 UAC settings + account):
http://www.pretentiousname.com/misc/win7_uac_whitelist2.html
Still doesn't mean there is a problem in chkdsk, of course.
@Leo: I haven't looked at the UAC debate since I wrote about it earlier on in the release cycle. Regarding the chkdsk issue– if it requires running untrusted 3rd-party code, would it still be a vulnerability?
@Leo: There's enough discussion about the purpose and merits of UAC elsewhere, including input by Chris Corio. I don't have anything to say that'll add more value to these discussions.
However, what I do want to point out is— if our basic premise is that users will always click Yes on every prompt they see – that does not translate into a software flaw, nor does it mean one shouldn't be prompting at all. On a related note, a similar concern was raised at the just concluded Black Hat conference about users always choosing Yes when prompted with SSL certificate validation errors. Does that mean we stop validating certificates, stop prompting users, or stop using PKI?
As one MVP likes to say: There are seldom good technological solutions to behavioral problems.
UAC seems to be doing very well for the purpose stated by Chris in the discussions linked above, imo. I also agree with Chris that comments on blog posts aren'the right medium to have a meaningful discussion about this. :)
Am I the only one who thinks 800MB of ram for chkdsk is a little steep? I'm not saying there's anything wrong, but I need a better explanation. Further, we differ on the use of the word "fair". 80MB might be fair for chkdsk….but 800MB? I just ran chkdsk on XP and it was 11MB.
@Dustin: As I started responding to your comment, it turned into what is more appropriate for another article on the subject. Will post it soon.
Meanwhile, you can find some of the answers in Steven Sinofsky's response. The chkdsk behavior you see is by design.
I was just pointing out the UAC thing because of this part of the article (which is highlighted in yellow so I assume it's considered important):
"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."
I assume the point of that part was to say that, even if there is a BSOD issue (which it appears there isn't anyway), UAC protects people's machines from being BSOD'd by non-admin processes even under the default settings. If that was the intended meaning then IMO it's false (for medium IL processes; protected mode IE is still good).
If you just meant that UAC protects the user from accidentally running something that requires admin via a non-admin command prompt then that is true, of course, but also seems like an odd thing to highlight.
@Leo (#2, from Aug 12): This is in response to the InfoWorld article. In particular:
"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."
Highlighting what the user will experience when running chkdsk without elevation, in response to the writer's assertion to the contrary, isn't an odd thing.
Again, this post is not a comment on or debate about UAC in general, to which Chris Corio has indeed provided an excellent and satisfactory response, imo.
I would like to say Bug is a bug however no reason why Microsoft can't fix it sooner or later via Windows Updates ,hopefully fixed by Oct,also remember Win7 is a brand new OS so we expect there to be a few issues/bugs in the early days.
cd