Print 31 comment(s) - last by SiliconDoc.. on Aug 14 at 7:11 AM

Much ado about nothing?

My first reaction to the stories about an alleged bug in Windows 7 CHKDSK utility that might "derail" the launch of Windows 7 was that it is probably just another mountain being made of a molehill.  After doing a little reading and research, I am beginning to doubt if the bug is even worth calling a molehill.  That's because all the "research" that had supposedly replicated the bug didn't actually replicate the bug and all they did was verify CHKDSK's normal behavior.

Randall C. Kennedy who supposedly replicated the bug admitted that he wasn't actually able to get any of his test systems to crash yet he still called for a halt to the launch of Windows 7 in his InfoWorld blog.  Others like Jason Mick who accepted Kennedy's analysis as gospel concluded that Microsoft was trying to pass the buck and that this "underlying file system issue" would likely delay Windows 7.  But it is clear that Kennedy and others citing him haven't really thought it out nor are they qualified to determine what constitutes a bug.

To get to the bottom of this, we first need to understand what CHKDSK is and what role it plays.  CHKDSK is a Windows disk checking utility that repairs hard drive errors.  Even if the tool has some incompatibilities with a small percentage of hardware, that should hardly derail the launch of the much awaited Windows 7 operating system.  CHKDSK using the /r switch looks for bad hard drive sectors and tries to salvage any good data that it can.  Most people don't even run CHKDSK much less with the /r switch because they simply don't get hard drive errors.  Even when they do have hard drive errors, they probably don't even notice unless it is something severe.  But even if there is a bug in the way the CHKDSK utility, it is not a flaw in the underlying file system.

But as the president of the Microsoft Windows Division Steven Sinosky pointed out, the mere fact that people are replicating the heavy memory consumption behavior of CHKDSK when using the /r switch doesn't prove a thing.  That's because CHKDSK is supposed to use maximum resources to repair a corrupted hard drive as soon as possible and that users shouldn't be doing anything else on the system while they wait for this to complete.  This makes a lot of sense because you certainly wouldn't expect to drive your car while someone is changing out the oil.  The priority here is to complete the repairs as soon as possible and this is precisely what CHKDSK does so it consumes all but 50 megabytes of available memory to finish repairs as soon as possible.  Then when it completes, it releases the memory so that the user gets the system resources back.  Since there was no crash replicated, it was silly for Randall Kennedy and everyone else to call this a bug much less a critical bug that would halt the launch of Windows 7.

Now for the very few people who actually get their Windows 7 machines to crash, there is a very likely possibility that the underlying firmware, drivers, or hardware isn't completely stable.  I know this first hand because one of my computers and a friend's computer that used to run fine on Windows XP refused to run on Windows Vista due to some memory problems.  Because the bad memory was near the end of the addressable memory space and Windows XP never used that much memory, the problem never materialized in XP until we used an OS that consumed more resources.  I had to download MemTest86+ and burn a bootable CD using ISO Recorder 3.1 which I booted to inspect my memory.  In both cases, my friend and I had to get Corsair and Kingston to send us new memory at no cost.  Anyone who owns a computer should be running this test anyways just to validate their own hardware.  MemTest86+ also managed to fail when my friend had a faulty CPU so it indirectly detects some CPU problems as well.

Another lesson I've learned in the past is that it is always a good idea to update motherboard firmware when you want to install a new Operating System.  It is simply a fact of life that older motherboard firmwares may not handle newer CPUs or newer Operating Systems very well.  Even if you're not going to install a new Operating System, it's a good idea to inspect your hardware and update the firmware to make sure your hardware is completely stable so that there is less possibility of silently corrupting data.

So can we conclude that there is no bug in CHKDSK?  We can't say for sure but we should definitely not conclude that there is a bug.  Microsoft has been testing 40 machines over night since yesterday and they haven't replicated the problem yet so it's starting to look like a hardware, firmware, or driver issue in some rare configurations.  We can conclude for certain is that this issue if there even is an issue will not derail Windows 7 launch.

Comments     Threshold

This article is over a month old, voting and posting comments is disabled

RE: OUch George, I thought we were buddies
By JasonMick on 8/7/2009 4:57:11 PM , Rating: 0
Jason, the fact that CHKDSK stresses your systems and exposes problems is a BONUS as far as I'm concerned. I would rather expose these problems and deal with the underlying hardware or firmware issue than a "see no evil" philosophy.

For enthusiasts its a bonus, certainly. But for average users (the majority), its not a major issue if their hardware has some minor driver inefficiencies or could break when fully stressed (which is almost never). It is an issue though if their computer becomes non-responsive for reasons they don't understand.

Running CHKDSK on a secondary disk is less common usage. It argues that Microsoft might offer a command line switch that tells CHKDSK to only use no more than X amount of memory.

That sounds like a reasonable suggestion. There is a GUI-driven user prompt that pops up sometimes when you insert suspect USB-sticks or hard drives that calls chkdsk with the /R switch, depending which box you check. That's the one I was referring should be limited.

Really as a command line tool the memory usage is fine, as I would assume system admins would be able to plan for it. I'm just saying that for the average user, it'd be unfortunate if they accidentally came across it.

Differentiating between command line runs and GUI-driven runs would be easily. Just memory limit the GUI-launched scans, and leave the command line ones as is, would be my suggestion.

By adiposity on 8/7/2009 5:35:52 PM , Rating: 3
Differentiating between command line runs and GUI-driven runs would be easily. Just memory limit the GUI-launched scans, and leave the command line ones as is, would be my suggestion.

In case you didn't know, this is already the case, and has been since Windows 95. Chkdsk is not the same as scandisk. They are different programs. That you don't seem to understand this might explain why you overreacted the way you did.

Go ahead, do a disk check in windows (drive/properties/tools/check now). Does the process chkdsk.exe spawn anywhere? No, it doesn't. Does it use up all your memory? No, it doesn't. Hmmm...

So really, unless you go to the command prompt, and do a chkdsk /r, this won't happen. Oh, and you'd need admin access to do that, by the way, so any old command prompt won't work. And you can't just click on chkdsk.exe, because that won't set the "/r" switch.


"You can bet that Sony built a long-term business plan about being successful in Japan and that business plan is crumbling." -- Peter Moore, 24 hours before his Microsoft resignation
Related Articles

Most Popular ArticlesSmartphone Screen Protectors – What To Look For
September 21, 2016, 9:33 AM
UN Meeting to Tackle Antimicrobial Resistance
September 21, 2016, 9:52 AM
Walmart may get "Robot Shopping Carts?"
September 17, 2016, 6:01 AM
5 Cases for iPhone 7 and 7 iPhone Plus
September 18, 2016, 10:08 AM
Update: Problem-Free Galaxy Note7s CPSC Approved
September 22, 2016, 5:30 AM

Copyright 2016 DailyTech LLC. - RSS Feed | Advertise | About Us | Ethics | FAQ | Terms, Conditions & Privacy Information | Kristopher Kubicki