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 chip set 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 chip set 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 10MB of RAM, as opposed to the several gigabytes I’m observing under Windows 7. (For the record, Microsoft says it has been unable to duplicate the bug yet on its 40 test PCs. And Microsoft Windows chief Steve Sinofsky says that the memory limits in Windows 7 have been increased, but not to the point that would lead to this massive memory leakage.)
Also worth considering: This command can be executed in a nonelevated context under the looser Windows 7 UAC implementation (Vista requires elevation of this command via the normal user consent dialog before continuing). 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.
Get the independent advice and expertise you need to support a virtual workforce.
The increase in Linux popularity has increased the frequency and sophistication of malware attacks. Read this 2 page white paper now to learn how you can protect your Linux environment with real-time protection that is certified by all major Linux vendors.
Download now »
Ensuring acceptable application delivery will become even more difficult over the next few years. As a result, IT organizations need to ensure that the approach that they take to resolving the current application delivery challenges can scale to support the emerging challenges. This handbook elaborates on the key tasks associated with planning, optimization, management and control and provides decision criteria to help IT organizations choose appropriate solutions.
Download now »
A common misconception is that mid-range storage requirements are dramatically different than that of a larger enterprise. Mid-range storage users may require less capacity, but they have similar functionality and management requirements. This ESG paper examines mid-range storage needs and reviews a new solution that adjusts size while retaining value, performance and functionality.
Download now »Fix it. Re-RTM it. Done.
Better now than later!
As much as I love to bash M$oft this does strike me as the ideal time to find this kind of bug. However, I doubt it is as simple as speedman thinks, M$oft has a habit of building ugly architectures that encourage their coders to rely on external code that is often complex enough that unanticipated side-effects eat their lunch. Or as in this case, left at the mercy of behaviors in code of completely unknown vetting, since a non-M$ofty wrote it.
Still it is just another RTM cycle and they have a huge code-base from which to cobble something together. With a little mid-night oil, I doubt it will even have much schedule impact.
What I do know is that massive resource hogging is fairly typical of Microsoft Windows 64 bit operating systems. A friend of mine has Vista-64 running on a laptop, and the amount of disk usage grew massively for a month or so, then started going down and up in what appeared to be a cycle. In a shorter-term cycle (per session), Physical Memory usage follows a similar pattern, even without the sort of caching several commenters have suggested.
Whether Intel or Microsoft has something to patch, it all can be done in plenty of time for the October release date for Windows 7. For myself, I'd wait a few months and find out who screams the loudest about which "features", aka bugs, in the new OS version. Then I'd buy in the second round of sales promotions.
Of course, that's for consumer-level buyers. A corporate IT Department will have to be more careful and wait longer, perhaps as Randall says, for Service Pack 1 or even SP2.
I saw that post as a link provided by Woody Leonhard in his Askwoody.com Woindows patch watch blog. Yes, Randall has overstated what is really a highly technical aspect of checkdisk /r. Randall says that he runs this command for every drive he is about to commit to any critical task, before actually trying to use the disk. That may be Best Practices for an IT Development Shop, but most business, IT and Home users will never have any reason to use this parameter from the Command Line. The Windows 7 sky is not falling. And the memory usage is not a Memory Leak -- it is deliberate and limited, always designed to leave the System with at least 50 MB of RAM overhead, which usually prevents the BSOD crash.
If you want to experience a true Memory Leak, try running the freeware antispyware product Super Antispyware. Run its updater on a fully-patched Windows XP Pro SP3 computer with limited RAM and a single-core processor, running IE8 fully patched. What results is a kernel driver memory leak and a true BSOD. At least that's what the Microsoft crash report output page says.
IBM i (formerly OS/400) and z/OS for IBM's Power systems and Mainframe. That's two operating systems for you that aren't going to be brought down by renegade apps. They're server-class OSes only, but I point them out to note that the capability of an OS to maintain stability and availability can be achieved.
Even if you run that command, with that option, against a second physical hard drive, you (and your system) will be fine.
chkdsk.exe performs exactly like it is supposed to. While it uses a lot of RAM it does so to speed up the repair. And it has been designed to not use *all* of the RAM, only the available, physical RAM minus some 50MB. It respects already allocated RAM, and the system remains responsive during the operation.
See my comment below for more info.
Please everyone update your info on this issue before commenting.
There is no bug in chkdsk.exe. There is no memory leak. chkdsk.exe does take up a lot of memory when run with the /R option against a non-system partition/drive. This is a deliberate design decision to help speed up the repair process.
Per Microsoft, chkdsk.exe will allocate as much as possible of available physical memory, leaving at least 50MB of physical memory free during the operation with the /R option.
In other words, chkdsk will not allocate memory unbounded. Rather it will measure how much physical memory is available at the time of launch and allocate memory based on that measure. This means that even if the command is invoked on a running server, it will not cause the server to start trashing as it will respect the memory allocations already made - and then some.
I have confirmed this on my own system. It's simple and anyone can make the experiment: First run chkdsk /r on a non-system disk with no other apps started. Use resource monitor to see how RAM allocations ramp up. When leveling out take a note of how much RAM is used by chkdsk.exe. When the process completes you repeat the experiment, but this time you start a lot of memory hungry applications and let them allocate memory before launching chkdsk.exe /r. Note how chkdsk.exe uses less memory during this second run. The memory allocated by chkdsk.exe clearly depends on how much available RAM at the time of launch.
Incidently, my computer remained responsive during both tests. I was able to launch new programs, open Word, take screenshots (many), paste them into word etc. While I could tell that the system was working, it did not feel sluggish at all.
Now, the crash (BSOD) was reported by a single user who mistakenly assumed that it was connected to the operation of chkdsk.exe (because it happened while he was running chkdsk.exe). This has now been determined to be a chipset driver issue. Said user has updated drivers from motherboard manufacturer and has reported back that the crash issue was solved.
In conclusion: There is no bug in chkdsk.exe. There is no bug in the NTFS driver stack. chkdsk.exe has been optimized to finish ASAP by allocating as much memory as possible with as minimal impact as possible on other running processes. There may be a chipset driver issue in an earlier version of a 3rd party driver. This issue is not found in current drivers.
Now, what remains to be asked is this:
Even if there had been a "massive memory leak" as originally reported, how can anyone claim that a memory leak in a rarely used utility (chkdsk.exe), only in a more rarely used option, only in a even more rarely occurring scenario (repairing a non-system volume on a multi-volume system) amounts to a "showstopper" bug which risk derailing the Windows 7 launch? It is hilarious! Look at who made that claim and his posting history. Not to mention his totally unsubstantiated assertion about a bug in the "NTFS driver stack". WTF? Mr. Randal C. Kennedy is either grossly incompetent or an extremely cynical professional troll. Either way, FAIL!
Sign up to receive InfoWorld Resource Alerts
963 Recommendations
