Chkdsk Bug Anything But a Showstopper

Earlier this week, we had a page 2 item about a possible showstopper bug in Windows 7 and Windows Server 2008 R2, but as I could’ve probably guessed by taking my time before posting said item, this bug has been way overblown and is anything but a showstopper. Steven Sinofisky himself responded to the bug by commenting on the blog.

The Chris123NT blog thought it had found a critical bug in Windows 7’s chkdsk utility. Run the tool with the /r switch (locate and repair bad sectors), and you should see memory usage for chkdsk eat up all your memory, or it crashes your machine with a blue screen of death. The original report only called it “critical”, but people like Randall Kennedy (who else) labelled it as a “showstopper”. As it turns out, this was all way overblown.

First of all, this bug will not be seen when running chkdsk on your system drive, because Windows will offer to run chkdsk before booting the system. If you run it on a non-system drive, Windows will ask to unmount it and continue the check, or do it during the next boot. The bug will not appear in any of these cases.

When running chkdsk on an external drive, for instance, memory usage can indeed spike, but an actual blue screen of death is very hard to reproduce. There are indications that certain outdated drivers may cause a BSOD to appear, and that updating said drivers to the latest versions fixes this behaviour.

The eating of RAM is actually by design, as Sinofsky has explained:

We haven’t reproduced the crash and we’re not seeing any crashes with chkdsk on the stack reported in any measurable number that we could find. We had one beta report on the memory usage, but that was resolved by design since we actually did design it to use more memory. But the design was to use more memory on purpose to speed things up, but never unbounded — we request the available memory and operate within that leaving at least 50M [reading other people’s reports, this should most likely be 500MB] of physical memory. Our assumption was that using /r means your disk is such that you would prefer to get the repair done and over with rather than keep working.

Despite the heavy memory usage, it seems as if systems remain responsive throughout the ordeal. I can kind of see where Sinofsky is coming from: if you are running chkdsk with the /r switch, you most likely think there’s an error somewhere, and I would rather want the fixing to be done quickly instead of continuing to work.

Sinofsky wasn’t pleased with the sensationalist nature of the reports on the web about this possible bug. “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,” he writes, “Bugs that are so severe as to require immediate patches and attention would have to have no workarounds and would generally be such that a large set of people would run across them in the normal course of using their PC.”

Microsoft is currently doing some heavy stress testing regarding this possible bug, just in case there really is some flaw in Microsoft’s code. And yes, it took me a while to get this item up on OSNews to rectify the issue, so my apologies for that one.


  1. 2009-08-07 10:06 pm
  2. 2009-08-08 3:11 am
    • 2009-08-09 2:12 am
      • 2009-08-09 5:49 pm
  3. 2009-08-08 11:20 pm
    • 2009-08-09 12:52 am
      • 2009-08-09 8:23 am
    • 2009-08-09 6:36 pm
      • 2009-08-10 2:20 am
  4. 2009-08-10 5:41 pm