Windows 7 Memory Bug Could be a 'Feature'

No matter how ready for primetime any operating system may be, it's never impervious to bugs. This applies to Windows 7, which is now in the can and released to manufacturing.

Apparently, a critical bug has been found in Windows 7 that could crash the computer when running Windows Chkdsk. According to reports, the crash occurs when chkdsk is ran with the /r switch, which is used to locate and repair bad sectors. When ran, the system reportedly consumes memory to 90 percent or more, eventually crashing the computer.

ZDNet blogger Ed Bott ran some tests and concluded that the bug, isn't completely reproducible or as critical as some make it out to be.

Microsoft Windows president Steven Sinofsky replied to the original report detailing the bug with a response that points out that maximum memory usage is actually a "feature" to speed up the chkdsk process. Here's an excerpt from his reply:

"In this case, we haven’t reproduced the crash and we’re not seeing any crashes with chkdsk on teh 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 requset 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.

"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. 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."

Sinosky added that the Windows team is running an overnight stress test with 40 machines. Read his full reply here.

Marcus Yam
Marcus Yam served as Tom's Hardware News Director during 2008-2014. He entered tech media in the late 90s and fondly remembers the days when an overclocked Celeron 300A and Voodoo2 SLI comprised a gaming rig with the ultimate street cred.
  • jerther
    hence the old joke
    Reply
  • dman3k
    "teh stack"

    I bet he thinks he's so 1337...
    Reply
  • Bullheaded67
    There may actually be a bug but I suspect it is in reality systems that are unstable for one reason or another (drivers, heat, unstable overclocks, etc). Some sites used extremely poor journalism to report this issue. I am glad to see this site giving a fair report.
    Reply
  • doomtomb
    UPDATE:

    After emailing back and forth with the VP Sinofsky, it was found that the chkdsk /r tool is not at fault here. It was simply a chipset controller issue. Please update you chipset drivers to the current driver from your motherboard manufacturer. I did mine, and this fixed the issue. Yes it still uses alot of physical memory, because your checking for physical damage, and errors on the Harddrive your testing. I’m currently completed the chkdsk scan with no BSOD’s or computer sluggishness. Feel free to do this and try it for yourselves. Again, there is no Bug.

    Thanks all.
    http://www.chris123nt.com/2009/08/03/critical-bug-in-windows-7-rtm#comment-11466
    Reply
  • dman3k"teh stack"I bet he thinks he's so 1337...
    LOL! My first reaction too.
    Reply
  • stradric
    Not to mention that chkdsk is hardly critical to normal everyday activity on one's computer.
    Reply
  • megamanx00
    Bug, oh no my friend. It's a feature that lets you quickly and conveniently restart your computer ^_^
    Reply
  • "is ran" "when ran". Head...Exploding...
    Reply
  • Netherscourge
    They set us up teh CHKDSK bomb!
    Reply
  • hellwig
    I don't know about CHKDSK (Wikipedia says '/r' requires a disk-level lock, so yeah), but whenever I ran ScanDisk and tried to use my computer, any disk access would reset ScanDisk. I quickly learned to NOT run other things while scanning/repairing a disk. Since CHKDSK /r is not able to run with other things writing to the drive, this means CHKDSK can use as much memory as it needs, what else would be running that needs that memory?
    Reply