Windows 7 RTM, which will be distributed to MSDN/TechNet and technical beta testers tomorrow, contains a nasty memory leak when the chkdsk command is initiated.The bug occurs when the CHKDSK /R command is initiated on a non-system volume. Memory usage of the chkdsk.exe process soars until the system is using over 90% physical memory. In some cases this will cause the system to become unresponsive and unstable.
Some are calling the bug a "show stopper", whilst others (Randall Kennedy) claim it could derail the Windows 7 launch. It's worth noting that Kennedy claimed in November 2008 that Microsoft had delayed the Windows 7 beta to early 2009, even though company officials always stated this was the case. In other words, take his words with a pinch of salt.
Is this a show stopper? No not really. Yes the memory leak is bad but it's a process that is used so rarely that Microsoft would mark this as minor in terms of bugs. There are unconfirmed reports that Windows VP Steven Sinofsky has claimed this is a controller issue and can be fixed with updated drivers, something that Microsoft can push out with Windows Update. In an unverified blog posting, Sinofsky states "In this case, we haven't reproduced the crash and we're not seeing any crashes with chkdsk on teh (sic) 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 (sic) the available memory and operate within that leaving at least 50M of physical memory."
It's worth noting that this bug also affects Windows Server 2008 R2, an operating system that potential customers would be more likely to use the chkdsk tool on. We have asked Microsoft officials for an official statement on the issue and are awaiting their reply.
Beta testers beta tester beta testers
</beat dead horse>
I so hate you for that. lol
Ballmer is nucking futs. I think he's smoking crack.
http://www.youtube.com/watch?v=FncILxajmlw
Ballmer has always been going strong of crack. Here's a video of him selling Windows 1.0 back then:
http://www.youtube.com/watch?v=tGvHNNOLnCk
"Just $99, it's Windows from Microsoft!"
I mean, forget about chkdsk.exe /r for a while, and see this:
Not only is the GUI disk scanner affected too (which is accessed far more easily), but with an even worse aftermath as well...?
Sure, we thankfully don't run disk checkers as much as before during the FAT32 days that wasn't a journalling file system, but this is still unacceptable in especially corporate environments, and where Windows Server 2008 R2 seem to be affected. The default disk scanner causing a server OS to become unstable...
I first thought that this was understandable if the testers had missed it -- after all, chkdsk /r, that's not all too common... But it seems to be in the integrated disk check utility too!? Wat.
They are one just has a GUI front-end but it still calls chkdsk.exe.
To be honest I don't think I have ever used chkdsk on a server install and this could probably be fixed by having OEMs slipstream a hotfix in to their installs -- then upload the slipstreamed to TechNet/etc tomorrow.
So every peice of software ever released is "a disgrace" too huh?
Every software I can think of has contained major bugs that have only been discovered days/weeks/months after release. Windows 7 is/will be no different.
Yes it's unfortunately that this bug was not detected during the beta, but as others have posted, there are certain sets of circumstances involved here. I tried to duplicate it myself last night on 7100 (the most recent build we testers had access to) and I could not duplicate it. Others suspect it's related to specific types of drive too and could even be a driver issue. So it either appeared in later builds (in which case the beta testers could not have helped) or no tester with the required set of circumstances ever tried to do a chkdsk or disk check.
Every software I can think of has contained major bugs that have only been discovered days/weeks/months after release. Windows 7 is/will be no different.
Yes it's unfortunately that this bug was not detected during the beta, but as others have posted, there are certain sets of circumstances involved here. I tried to duplicate it myself last night on 7100 (the most recent build we testers had access to) and I could not duplicate it. Others suspect it's related to specific types of drive too and could even be a driver issue. So it either appeared in later builds (in which case the beta testers could not have helped) or no tester with the required set of circumstances ever tried to do a chkdsk or disk check.
Umm ever heard of OSX, it's perfect.
Take your comments elsewhere fanboy they aren't helpful nor true. I experienced this the other day and think it's more in depth then reported on officially. My reason being is I assumed that as I hadn't turned my system off in 6 weeks, I was bound to be bogged by now, so I rebooted and it worked fine, must try it later to see if it reproduces, anyone else experienced it???
Don't worry, at least I appreciated your sarcasm.
I got a BSOD 2x last night. Was just looking at Meme database and youtube videoes and had this error occur. I never asked chkdsk to run either and afterwards I ran a utility from BIOS to check the status of my RAM so it appears this is the error reported here. Must have been caused by a recent update as I have been using W7 since Jan and this has not happened before. Really annoying too.
Oooh that is nasty I didn;t get BSOD this time but it did hog resources until ended process tree, got the RTM going on a Dell laptop tomorrow for testing so hopefully will be fine, fingers crossed
Before you run chkdsk /r , use another program (ramdisk/vmware that you specify the amount of ram) to use up most of the available memory. Run chkdsk /r, then turn off the ramdisk/vmware instance. Boom, chkdsk will continue to run with the memory it allocated leaving the newly released memory alone.
I don't think I've used chkdsk since Windows 98/2000 lol.
Especially stuff like dataloss is a pretty automatic critical bug, and if this can invoke BSOD's on some machines (and thereby cause data loss), or "just" slow it to a crawl on others, I think it would normally have held the RTM back. But now that it's out, well it becomes a different matter of course. But it is a critical bug, of course.
Especially stuff like dataloss is a pretty automatic critical bug, and if this can invoke BSOD's on some machines (and thereby cause data loss), or "just" slow it to a crawl on others, I think it would normally have held the RTM back. But now that it's out, well it becomes a different matter of course. But it is a critical bug, of course.
Mozilla != Microsoft and Firefox != Windows
Still don't think this a end-all-be-all shut down the presses and halt everything bug. Anyways it's easily taken care of with a Windows Update. At this point it's too costly to re-build the OS.
At the same time though, this isn't front page ZOMG news...
Yeah, neowin has a Back Page News section for a reason.
I know, another bug in Windows. Sheesh, if we started reported all of these, we would be here every few minutes. I mean, Windows is a huge project, with a huge code base, and lots of components inter-operating. On top of that, Microsoft keep making changes to the way things work, bugs are something you have got to expect from something this big. Of course, if they cut it down a bit, that would help, make it more like linux with its small kernel. But you are always going to get bugs.
If you had "bothered reading the article" you could come to no other conclusion than this is being way blown out of proportion by Randal Kennedy and his ilk. To even be able to use the CHKDSK /R command you will need at least two partitions or drives, one for the system which this command can not be used on because the partition is in use and can only be CHKDSk during a reboot. The second partition or drive must either be unmounted for the command to work or CHKDSK will ask you to unmount the partition first.
In any case this command would only be used if a system drive is in a horrible state of disrepair so the person invoking the command is hardly likely to be using the PC during the CHKDSK repair and the drive is confirmed safe to use again. I would not even call the memory leak a minor bug because hardly any one will ever run into it except the occasional power user or IT person who will probably not even use the PC until the operation is finished.
Last edited by soonerproud on 06 Aug 2009 - 00:26
Since when do admins run chkdsk on a production server while in use?
+1
Oh thank god my faith in Neowin sysops is being restored...
Also, since when does a memory leak cause CPU usage to spike. And, if I read the article correctly, the OS is requesting the memory, and it is being released if it is available, so it wouldn't actually affect any processes currently running on the box. I can't wait to verify this when I finally get the RTM tomorrow.
You might run it at 4 in the morning, for a small server. You might take the services offline, run it, and then bring them back online. You shouldn't need to reboot for this.
Do these guys at Microsoft actually test this stuff?
My faith in Neowin sysops imagination is all lost...
There's no reason for this to call for a resolution more extreme than a Windows Update.
Do these guys at Microsoft actually test this stuff?
My faith in Neowin sysops imagination is all lost...
A small server running on what hardware? Some box you built with $300 spare and threw it in a small business?
Even the lowest end of Dell hardware has hardware raid controllers that render chkdsk /r basically useless in comparison. There's no reason to run a /r in a server environment, on a production server, while it is operational.
I found if you do an install on windows 7 x64, where you can select where you are in stalling to . disk0 , or disk21 etc. If you create a partition (not just click next) but actually click create and then install it to that. It will go through the install but on reboot it doesn't set the partition as active.
I have yet to try this on a 32bit version but i suspect it will do the same.
2) I am running 7 RC x64, I installed a newly created partition, and I had no troubles.
I know, each business should have a fully staff department of about 20-30 people (maybe more if the business is bigger), just to keep track of the bugs with Windows 7. Microsoft recommends this in its update manual. They should work around the clock, in shifts of 16 hours at a time, and only drink iron bru.
Seriously though, what a great excuse for any bug ever. I haven't heard that one before, remember to use it for every bug from now one. Shouldn't you guys have people to stay informed about our bugs? What, do you want them to lose their job?
I had no idea that it was above and beyond the expectations we should have for IT staff to keep up with Windows Updates.
It's not a show-stopper bug because it can be patched with an update on Windows Update, or, Microsoft could apply the patch during the install of Windows 7 on the DVD (they include the patch on the actually DVD).
Also, VP Sinofsky has said this is a chipset driver issue and not an issue with Windows. But we'll have to see what happens.
It's not a show-stopper bug because it can be patched with an update on Windows Update, or, Microsoft could apply the patch during the install of Windows 7 on the DVD (they include the patch on the actually DVD).
Also, VP Sinofsky has said this is a chipset driver issue and not an issue with Windows. But we'll have to see what happens.
I severely doubt this is a 'chipset' issue (and Sinofsky didn't claim so). I'm not debating that it isn't an easy WU but if you think this isn't a Windows issue then you're out of your mind - a Windows application misbehaving on a Windows operating system operating on hardware that could previously run chkdsk fine...
NB: I don't think this is anything close to a showstopper, just clarifying.
Chkdsk is a recovery option only, designed to NOT be used in regular day to day processing. If you're running it, you ABSOLUTELY want it to run as fast and as well as possible.
Chkdsk is a recovery option only, designed to NOT be used in regular day to day processing. If you're running it, you ABSOLUTELY want it to run as fast and as well as possible.
The problem isn't that it is using the RAM it needs. The problem is that it can friggin lock up your PC. Did you not read the article, and just see "RAM" so decided to post?
I've reproduced the steps on both my desktop (7100) and my laptop (7600). Both exhibited the intended behavior as Steven Sinofsky noted on Chris123NT's blog with no side-effects. The memory is released once chkdsk is done, and the system is also still responsive during and after the operation.
Chkdsk is a recovery option only, designed to NOT be used in regular day to day processing. If you're running it, you ABSOLUTELY want it to run as fast and as well as possible.
The problem isn't that it is using the RAM it needs. The problem is that it can friggin lock up your PC. Did you not read the article, and just see "RAM" so decided to post?
yeah except that it doesn't cause the system to become unresponsive and unstable. Hundreds of people have tried since yesterday, none has experienced crashes. And what would you be doing during a chckdsk /r anyway? you only run that command after a severe hard drive fault, do you want to play crysis while running the command?
http://www.neowin.net/news/main/09/08/05/w...y-from-tomorrow
Well deserved !
found on zdnet
please update your news accordingly
Also, what's with TweetDeck using 115MB? Nobody cares that a dinky little desktop app monitoring a website takes that much? Where's the uTorrent crowd?
It's a minor bug that can easily be fixed and won't even be noticed by most people.
In fact this has been a bug since the beta days and you can see that on the many forum posts on the net and it's took 8 months for most people to notice it. What's that tell you?
And you people talking about how admins may routinely run chkdsk on servers: They don't routinely run it with /r. At worst, they may use /f but often they will use no switches at all (read-only mode, just to check for possible problems).
As for the fact that the Disk Check tool in the GUI is also affected, it's only affected if you check the checkbox which is equivalent to the /r switch. The default options do NOT have this checkbox checked.
I'd say that the only people likely to be affected are the type of people who will have already heard about this bug by the end of the week, and therefore they will already know how to avoid it until a patch is available.
Totally agree with you.
Or you could just back up your data. I used to run multiple partitions until I got a home server. Don't really see the need now.
Yeah, I have seen this as well. Microsoft actually have a simple bug fix for this one. Stop running explorer.exe
or, at the very least,
The start of SP-1.
While it may not be a very frequently used command, the problem IS a bug, and needs to be fixed. The last thing MS needs is the reputation that Win-7 is buggy!
I don't think there is much debate on whether or not this is a bug. The big debate is whether or not this is a "showstopper" bug bad enough to cause MS to stop the distribution of the RTM starting tomorrow to all the MSDN/Technet/freeloading-beta-tester (j/k on that last part!!) peoples and to make them fix it before then. It's not a showstopper bug first of all and it would cost MS way too time/money to have to rebuild the code this late in the game (IMHO). Heaven forbid they bump up the build # simply to fix this and delay it from the people salivating to get their paws on it tomorrow!
Lots of people just have C: and nothing else.
BTW the chkdsk /r utility memory usage was changed in the Beta versions to utilize more ram, to help complete the task quicker....
Last edited by xendrome on 05 Aug 2009 - 22:30
It has been confirmed that it is a chipset issue. Update the drivers on your chipset and problem fixed.
It is caused by the driver, not by a "call to the driver's functions"
There I feel better.
Now ... I would be a lot more concerned about something called "TWEETDECK" using up over 100MB.
I think I might be embarassed to admit I used such a thing.
It's by design. It's a feature. It's not a bug. It's supposed to use your RAM. It does not cause a crash.
It's by design. It's a feature. It's not a bug. It's supposed to use your RAM. It does not cause a crash.
The red box flickers. Not sure if it's simply constantly refreshing info or what, but it's darn annoying. And I encounter it more than chkdsk.
Applies to:
Windows 7 (all editions)."
Haven't you seen similar bugs in RTM Windows releases that get fixed by a hotfix or service pack? What's the big deal about this one, does it corrupt your data? Then it's not a show stopper. There was worse issues with Windows Explorer which MS hasn't fixed in RTM.
Everyone else (myself included) that wrote their results in the forum thread got the RAM released without any problem.
However, only time will tell as Microsoft addresses this "issue" and make an official statement or something.
Don't listen to RCK. He's a douche.
Also, this article, still, not a legitimate bug. See istartedsomething: http://www.istartedsomething.com/20090806/...he-digital-age/
What 'issue' is present? RAM Usage? This is by design, when using the /R (which means something is really wrong) it uses as much RAM as it needs depending on your volume size and the amount of files on your computer.
As for the 'crash' that resulted from running chkdsk (a different issue) - it is directly related to a couple of chipset drivers.
1) Chkdsk with /r assumes the user knows there is an emergency and will use as much RAM as needed to get the process completed and not 'shift' data back and forth in virtual memory or other things that could further compromise a failing hard drive.
2) Chkdsk CRASHING is a freaking chipset issue that is a side effect and has NOTHING to do with the RAM usage.
There is a bug here, it is in a few chipset drivers, that are fixed. As for the high RAM usage, this is normal, and WANTED if you have any clue about why the /R option is used and why people would want the process to work.
This whole 'show stopper bug' has become the most insane thing if you step back with some perspective.
1) The original people noticing this have NO FREAKING clue that chkdsk /r is using a lot of RAM for a REASON. so they first think memory leak or problem or bug and then when they find a few chipsets that fail with chkdsk, they assume it is a Win7 problem that is related, when it is just a chipset driver. PERIOD.
Get it YET or do we need to get crayons out for people and some charts?
Commenting has either been disabled on this article or you are not logged in. Click here to login or register, its free!
Note: Anonymous commenting is disabled in order to keep the quality of responses to a high standard.