Windows 7 RTM Build 7600.16385 includes a potentially fatal bug that, once triggered, could bring down the entire OS in a matter of seconds: "The bug in question - a massive memory leak involving the chkdsk.exe utility - appears when you attempt to run the program against a secondary (i.e. not the boot partition) hard disk using the "/r" (read and verify all file data) parameter. The problem affects both 32-bit 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," reports InfoWorld's Randall Kennedy. Microsoft is claiming the bug is a chipset driver issue, but Kennedy's testing of the latest Intel INF Update Utility driver set and VMware virtualized chipset drivers suggests otherwise. "This is clearly a Microsoft bug - and the fact that it manifests itself via the chkdsk.exe utility makes me wonder if it isn't something intrinsic to the Windows 7 version of the New Technology File System (NTFS) driver stack." Worse still, user comments suggest that Windows Server 2008 R2 suffers from the same flaw.
Post a Comment
Member since:
2005-07-06
...but it should literally take the engineers one day to find and fix the bug. It's probably something relatively simple, possibly an optimization that they did not think through.
I say this having had experience maintaining operating system and file system utilities for a major OS/company.
LOL! Now I feel like I can't post sentences like the previous one because of the "10 most annoying" thread.
Member since:2008-04-18
Member since:2005-07-06
Member since:2008-08-19
Member since:2005-07-06
Member since:2005-07-06
Allow me to elaborate... two "showstopper" bugs I have fixed that caused OS crashes where simple initialization issues. Shared memory variables were initialized, then cleared (accidentally) but another section of code, then referenced.
In these two cases it literally came down to moving two lines of code and documenting that certain things need to happen in a certain order.
Member since:2005-07-06
Member since:
2006-01-12
Member since:2007-09-22
Member since:2009-08-05
Member since:2006-01-12
How does this rule out driver bug? You are aware that VMs lie guest OS what driver to use, most likely it is some generic all purpose driver. Again my point is based on 2 facts: 1) Few people confirmed that using chipset drivers from manufacturers fix this (Hotfix forum user), 2) Bug doesn't happen on every machine.
Member since:
2006-11-19
Member since:
2009-08-05
I ran into the problem on 64bit build 7127. Dunno if URLs are allowed on first post; there's a DonationCoder thread on "Windows 7 evaluation" where I briefly mention the issue May 31st.
BSOD confirmed after running out of physical memory (no pagefile). Although the memory growth is visible in chkdsk.exe, I'd guess there's some other factors involved as well - I've never seen a usermode memory exhaustion cause BSOD before.
Should mention that this is a vLited Win7 install, and that I do run intel chipset drivers.
Edited 2009-08-06 00:34 UTC
Member since:
2005-12-04
Disclaimer: I work for Microsoft, and I work on NTFS.
Chkdsk intentionally uses lots of RAM to cache information in order to make the process complete as quickly as possible. The fact that this is using RAM is not, in itself, a problem.
The original report was of a bugcheck during this process. That really would be a problem. The original reporter upgraded drivers and no longer saw the bugcheck.
We have, in the last 30 or so hours, run chkdsk on hundreds of machines to see if we can find the cause of the crash. As of this writing, we have been unable to reproduce the crash condition; and since the original reporter can no longer generate the crash, we are left with one crash on one machine that no longer occurs. We have not been able to examine what caused any machine to crash in this process.
At this point, there's nothing to indicate that it's a bug users will frequently encounter, that it's a showstopper, or anything else.
There is a good chance that the original issue occurred presicely because the disk device was making mistakes (why does one run 'chkdsk /r'?)
A better blog post describing this bug can be found at http://blogs.zdnet.com/Bott/?p=1235 . See also Steven Sinofsky's response to the original reporter at http://www.chris123nt.com/2009/08/03/critical-bug-in-windows-7-rtm#... .
If anyone out there is encountering crashes when running chkdsk, please let me know. I'll make sure it gets investigated promptly.
Since I'm a regular OSNews reader, when there is a nasty bug in the "NTFS driver stack", OSnews readers will be amongst the first to know. For better or worse (depending on your intentions) today is not that day.
Member since:2009-08-05
I've just ran chkdsk on my system, but terminated when I hit 7GB commit, with chkdsk consuming 5.3GB - didn't feel like going higher and risking a BSOD right now.
EDIT: happens on both my 140gig windows-stripe and my 36gig regular partition that's on the same disk as the system partition.
Edited 2009-08-06 00:45 UTC
Member since:2005-12-04
Member since:2009-08-05
Such high memory usage sounds very wrong to me, though - I can see the point in caching data structures during the FS integrity checks to speed up things, but why (try to) cache all the data sectors? Isn't the logic of the surface scan to attempt-read, mark-bad + relocate on error?
BSOD or not, there's definitely something to fix 
Member since:2009-08-05
Member since:2006-10-10
Member since:2008-07-15
If this is triggered by a chipset driver, as Microsoft claims, then your USB drives are not likely to exhibit this behavior at all as they do not pass through the hard drive controller chipset (IDE or SATA) on your motherboard. It depends on which "chipset" they are referring to however and also depends on which particular driver is affected.
Member since:
2009-04-24
Member since:2005-04-01
Member since:
2005-08-18
Member since:2008-07-15
Member since:2006-01-02
