Earlier this week, we had a page 2 item about a possible showstopper bug in Windows 7 and Windows Server 2008 R2, but as I could’ve probably guessed by taking my time before posting said item, this bug has been way overblown and is anything but a showstopper. Steven Sinofisky himself responded to the bug by commenting on the blog.
The Chris123NT blog thought it had found a critical bug in Windows 7’s chkdsk utility. Run the tool with the /r switch (locate and repair bad sectors), and you should see memory usage for chkdsk eat up all your memory, or it crashes your machine with a blue screen of death. The original report only called it “critical”, but people like Randall Kennedy (who else) labelled it as a “showstopper”. As it turns out, this was all way overblown.
First of all, this bug will not be seen when running chkdsk on your system drive, because Windows will offer to run chkdsk before booting the system. If you run it on a non-system drive, Windows will ask to unmount it and continue the check, or do it during the next boot. The bug will not appear in any of these cases.
When running chkdsk on an external drive, for instance, memory usage can indeed spike, but an actual blue screen of death is very hard to reproduce. There are indications that certain outdated drivers may cause a BSOD to appear, and that updating said drivers to the latest versions fixes this behaviour.
The eating of RAM is actually by design, as Sinofsky has explained:
We haven’t reproduced the crash and we’re not seeing any crashes with chkdsk on the 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 request the available memory and operate within that leaving at least 50M [reading other people’s reports, this should most likely be 500MB] 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.
Despite the heavy memory usage, it seems as if systems remain responsive throughout the ordeal. I can kind of see where Sinofsky is coming from: if you are running chkdsk with the /r switch, you most likely think there’s an error somewhere, and I would rather want the fixing to be done quickly instead of continuing to work.
Sinofsky wasn’t pleased with the sensationalist nature of the reports on the web about this possible bug. “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,” he writes, “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.”
Microsoft is currently doing some heavy stress testing regarding this possible bug, just in case there really is some flaw in Microsoft’s code. And yes, it took me a while to get this item up on OSNews to rectify the issue, so my apologies for that one.
Nice to see the corrections posted over the past few days too…
/R Locates bad sectors and recovers readable information (implies /F).
But an unsuspecting technician can run chkdsk with this option. Has anyone tried if this produces a similar effect when you run it of the Windows CD when you boot from it as a recovery tool?
Edited 2009-08-08 03:17 UTC
As I indicated in the previous story, the bug here is a bugcheck, not memory consumption. Upon further investigation, we have identified multiple chipset drivers that can cause bugchecks, but this is rare (affecting around 1% of the install base of drivers.)
This may affect a WinPE boot if the driver is installed in WinPE (which it probably isn’t.) If it is, you may need to generate a patched WinPE with a patched driver in order to run chkdsk /r on an affected machine.
But the point to stress is the probability of having bad chipset drivers is still quite low. Hopefully one outcome of this debacle will be manufacturers testing the error paths of chipset drivers more thoroughly.
(Another outcome may be to remove/disable/hide/scale back caching to satisfy some of the less educated elements of the Internet by ensuring memory consumption is not overly visible. This will hurt the majority of users who currently benefit from the aforementioned caches. It is sad that such engineering tradeoffs are being made/influenced by uneducated opinions.)
In Linux (actually KDE3), if you open the system monitor, you get a memory usage graph which shows how much memory is in use by the system (in red), undiscardable user memory (in blue) and cache memory (in yellow).
On low-memory machines (500 MB RAM) you can see the memory being utilized fully after some time of usage, most of it being cached.
In this way the user gets the feedback “all is well”, the memory monitor not lying to the user (by displaying only system + user memory), and the system taking full usage of the memory.
On windows XP it always made me nervous, when I saw Windows starting to swap out memory when the physical memory was not yet full.
Memory should be used, that is what it’s here for, Microsoft should NOT slow down the machine to needlessly save memory.
Should be the problem with sound.
I don’t know if it’s the way the sound initializes and de-initializes, but I never had this issue before Windows 7.
Basically when you first load up Windows 7, then you try to play a game in 5.1 sound, the center and surround channels have no output.
So every time I boot up, I have to go into the sound hardware configuration, change it back to Stereo, run the test, then change it back to 5.1 and then run the test again. Then it works properly (well most of the time).
But then the other day, the exact same thing happened to Linux, though at first I thought it was because I still have two sound cards in my computer (I have an Audigy 2 Platinum and the onboard sound) only because of having these weird sound issues in Windows 7.
I can only think that it somehow is initializing the sound wrongly when it first loads up, but then it does that same initializing when it is rebooted.
This SHOULD be a show stopper, especially since it affects the multimedia capabilities of the OS.
Granted I’ve only tested it why my hardware, but it does do it with both sound cards.
The only other issue I’ve had with it, is that I have it installed on my Touchsmart with the multi-touch. For whatever reason it keeps randomly making the sound of hardware being removed. The only thing I can think of is that somehow the touchscreen is being initialized differently than it expects. The reason I am thinking that, is because depending on if you run Vista or Windows 7, the pci bus location of the touchscreen is different! (2:1:0 if I recall for vista, and 2:1:1 for 7) Only know this because I dual-boot Ubuntu on it.
These are things that people will notice. I don’t know who would be running Chkdsk from within Windows anyhow, I always run it from a boot disk.
I don’t know who would be running Chkdsk from within Windows anyhow, I always run it from a boot disk.
Yeah same, hence my question above. Will that not explain than if it is a chipset incompatibility issue? If it is than we should get the same issue even when running it of the boot CD. This means it would be wise to keep your old Vista CD since it would be the only way to run chkdsk properly. Well you can do it with XP too but with Vista you get full NTFS support through the command shell + utilities such as bootrec that would fix your booting should a foreign boot loader corrupt your Windows boot loader. I used bootrec /rebuild (I think) or something like that to fix my laptop’s Vista/7 loader.
Edited 2009-08-09 00:59 UTC
Sigh did you guys read the article? They improved chkdsk to USE memory to gain SPEED. Only bug is in those rare cases where this causes BSOD, AGAIN in all cases highly increased memory usage is INTENDED behavior.
And yes it happens in recorvery mode also because it’s the same chkdsk.
Why would you want to run older tools that are slower if you wont be using machine anyway since you are suspecting it has HDD failure, there is no other reason to run chkdsk with /r.
If you have ever run chkdsk in server you know how much time it takes (days not hours) so I cheer Microsoft for improving such a rarely used tool.
Leech: OMG someone call Randall Kennedy there is another bug! And it’s infesting like 0,1% users, call the Obama, call the Greenpeace. Also Puppet Walt Mossberg is reporting some other problems. http://www.youtube.com/watch?v=Xdn0AmdXsGg
Yeah, and I’m sure that there is only .1% of all people that use more than just stereo speakers….
Or for that matter there is only .1% people that use their computers as media centers. If that were the case, then I’m sure Microsoft would have never bothered developing the Windows Media Center.
http://blogs.msdn.com/e7/archive/2009/08/10/what-we-do-with-a-bug-r…
He talks about the process of bug tracking and how surprised he was at the reaction to his comments on a blog being news.