Chkdsk Bug in Windows 7 Could Cause BSOD?

Rob Williams

Editor-in-Chief
Staff member
Moderator
From our front-page news:
Yesterday, a fierce storm blew through the Internet targeting Windows 7, and the reports weren't good. It's been discovered that there is a severe enough issue that many are believing could result in a delayed Windows 7 release, although that would be tough to believe, since the RTM has just been released to MSDN subscribers today. According to Microsoft though, they see no issue, and if there is one, it's not their fault.

The problem lies with the built-in disk-checker, "chkdsk". When run with the /r switch, on a secondary drive, the program suffers from a major memory leak that effectively hogs all of your system RAM, and ultimately, gives you the infamous Blue Screen of Death. While many people have verified that this issue exists, Microsoft is adamant in stating that they've yet to experience the issue, and they believe if anything, it would be caused by hardware, not their software.

"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." is what Microsoft's Steven Sinofsky, president of the Windows Division, said, so it appears that they don't believe it to be a major issue at this point. It's also unknown whether or not this bug only exists in the RTM or not, because you'd imagine that if it has always existed, people would have discovered it long ago.

If anyone out there happens to be running any build of Windows 7, and you have a two-disk setup, and you are feeling a little brave, try out the chkdsk command, and see if the bug exists on your system. If your secondary drive is "E:", then the proper command would be, "chkdsk /r e:", without quotes.

windows_7_official_box_art_060809.jpg

On the Chris123NT's blog, a user name FireRX, who appears to be a Microsoft MVP, said, "the chkdsk /r tool is not at fault here. It was simply a chipset controller issue. Please update [your] chipset drivers to the current driver from your motherboard manufacturer. I did mine, and this fixed the issue. Yes, it still uses a lot of physical memory, because [you're] checking for physical damage, and errors on the Harddrive [you're] testing... Again, there is no Bug." FireRX also said he was sure a hotfix would be issued today.


<table border="0" width="100%"><tbody><tr><td>Source: Network World</td> <td>
</td></tr></tbody></table>​
 

Kougar

Techgage Staff
Staff member
I'll just chip in here. Steven Sinofsky himself states the program is designed to use all available system RAM short of 50MB in order to speed up the chkdisk /r process. From the first half of the same quote Rob used:

In this case, we haven’t reproduced the crash…. [T]he design was to use more memory on purpose to speed things up, but never unbounded — we requset [sic] the available memory and operate within that leaving at least 50M 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.

Since the RAM usage is by design, that means the only issue here is the purported crashes. This article (And one at THG) makes it sound like the initial whistleblower simply had out of date drivers. http://blogs.zdnet.com/Bott/?p=1235

Also its worth noting around six different places have tried to reproduce the crashing, including MS, and none of them could. Rob, if you know of a site that reproduced the crashes I'd like to know! ;)
 

Rob Williams

Editor-in-Chief
Staff member
Moderator
Also its worth noting around six different places have tried to reproduce the crashing, including MS, and none of them could. Rob, if you know of a site that reproduced the crashes I'd like to know! ;)

I'm curious as to how out-of-date these drivers would have had to have been. We're dealing with Windows 7, after all... they would have been semi-recent. Either way, I'd love to try to re-produce this, but I don't have the RTM at the moment. I'm waiting for Microsoft to get back to me on it... could take upwards of a few more weeks.

That aside, another article I read (can't remember where), noted that the issue is reproducible in VMware, but that doesn't help us out much. If that is indeed the case, though, then the driver issue does seem reasonable. But even so, an out-of-date driver shouldn't crash the PC, especially with an application like Chkdsk. If it does, then chances are it would crash in other uses also, not just that one application.
 

Kougar

Techgage Staff
Staff member
I mention the drivers because one of the people claiming their system BSOD'd was actually testing for the bug inside of a virtual machine. I typed that before reading the second half of your post... that is exactly my point. VMWare uses a driver layer to interface with the system hardware, and that is where I presume some were saying the issue was.

I'm not sure VMWare can handle the RAM demands of such a task anyway, that may simply be enough to crash the virtual machine by itself. Either way, I don't subscribe to errors reproducible in virtual machines, I want to see someone able to reproduce this "BSOD" crash in native W7 before I give this story any credence. :)

Edit: I am 1337! :D
 
Top