Critical Windows 7 bug risks derailing product launch

It appears that Microsoft’s glowing track record with Windows 7 is about to come to an abrupt and unceremonious end. According to various Web sources, the RTM build 7600.16385 includes a potentially fatal bug that, once triggered, could bring down the entire OS in a matter of seconds.

Windows president tries to calm fears of Win 7 critical bug

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.

I tested for the bug against three different Windows 7 OS configurations on two different hardware platforms: an Intel Atom-based netbook running the 32-bit version, an Intel Core 2 Duo notebook running the 64-bit version, and a VMware Workstation 6.5.2 virtual machine running the 32-bit version.

In each case, the utility executed the first three stages of the test correctly using modest amounts of memory (several hundred megabytes). Then, when it entered the fourth stage (a read test), the chkdsk.exe utility’s memory consumption started to climb rapidly until several gigabytes had been allocated to its process and the test systems in question began to run out of memory.

Note: I did not succeed in causing the systems to “blue screen” as others have reported. However, I did observe chkdsk.exe consume up to 90 percent of the available physical memory on a 2GB VMware virtual machine. After that, the utility appeared to hang while all other operations in the OS slowed to a crawl for lack of RAM.

I also verified that the problem exists with the integrated disk check utility in Windows Explorer. When you use this function, explorer.exe starts consuming RAM like it's going out of style, pushing my test system to 98 percent memory utilization in just a few seconds. Worse still, explorer.exe failed to release the RAM when I canceled the disk check, and grew even more despite the fact that the check was now deliberately aborted. My only recourse was to either reboot the system or try to manually kill and restart explorer.exe.

According to some sources, Microsoft is passing the buck on this one by claiming it’s a chipset driver issue and that users should update their PCs. However, in my own tests I’m using the very latest versions (9.1.1.1015) of the Intel INF Update Utility driver set. And this also doesn’t explain why the bug exists in VMware, which uses its own, virtualized chipset drivers.

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. It’s worth noting that this same command, executed under Windows Vista with Service Pack 2, consumes less than 10 megabytes of RAM, as opposed to the several gigabytes I’m observing under Windows 7.

Also worth considering: This command can be executed in a non-elevated context under the looser Windows 7 UAC implementation (Vista requires elevation of this command via the normal user consent dialog before continuing). So not only is this a potentially catastrophic bug from a functional standpoint, it also opens up a new attack vector for malicious code. Hackers may be able to use this unprotected command to destabilize a system (by consuming almost all available RAM), and in extreme cases, cause it to fail altogether.

The bottom line: A file system-level bug, at this late stage in the development cycle, should be considered a showstopper by most IT organizations. Worse still, user comments suggest that Windows Server 2008 R2 suffers from the same flaw. So while the act of running chkdsk.exe under Windows 7 might not be a common occurrence for most users, it is in fact something that server administrators do quite regularly to ensure volume integrity.

Microsoft has so far gotten a pass with Windows 7. The strength of the beta and release candidates, as well as the generally accepted belief that Windows 7 is essentially Vista R2 (and thus less prone to catastrophic bugs of this nature), has caused many in the IT community to lower their guards a bit. I myself am guilty of a bit too much Windows 7 boosterism in the weeks leading up to RTM. What this latest episode has taught me is that no major release of Windows –- not even one that is more or less a supersized patch of the previous version –- deserves a pass, and that the old wisdom of “wait for the first service pack” still applies with Windows 7.

This is, after all, a Microsoft product.