Windows 7 chkdsk memory leak?
I was wondering if anyone else has noticed extremely high RAM usage when using windows 7's chkdsk. I've used chkdsk on the same USB flash drive on my XP, vista, and 7 machines, and the memory usage is as follows:xp : 20 - 30 MB (Depending on stage)vista : 2.5MB7 : about 25MB per second running (e.g. after chkdsk has been running for 10 seconds it will be using 250MB, after 2 minutes it will be using 3.0GB)I am monitoring memory usage using task manager. I actually have two machines running windows 7 7100 release candidate (x64) and the I noticed the problem on both.The problem is easiest to duplicate if you run chkdsk on a drive other than your OS drive (so you can actually have task manager open while it runs as opposed to running after a reboot), and if you run a check that will take a long time. chkdsk /f on a large hard drive works fine, or chkdsk /r on a smaller hard drive will work as well. It doesn't seem to depend on which stage it is in - the memory usage balloons during stage 2 of a chkdsk /f on a (full) 1TB hard drive I have, and it happens during stage 4 of chkdsk /r on a half-full 32GB USB flash drive as well.I would be interested to see if anyone else can duplicate this.
June 2nd, 2009 7:26pm

yup mines doing the same, even on local disks....climbs at an alarming speed
Free Windows Admin Tool Kit Click here and download it now
June 2nd, 2009 8:49pm

Hmm, too bad I didn't notice this during the beta so I could push the "submit feedback" button. This seems like a pretty serious problem, I wonder if there is a way to report it to Microsoft.I wonder if it could be driver related? I noticed it on the following:Win7 7100 x64 - AMD SB750 southbridge w/ Catalyst driver suite 8.612 (WHQL) - happens both on the main SATA controller in AHCI mode and on USB devices as wellWin7 7100 x64 - AMD SB600 southbridge w/ Catalyst driver suite 8.612 (WHQL) - only tested on a USB deviceMaybe it's AMD chipset related?
June 2nd, 2009 10:06pm

You're right there, they probably want to fix this one!Im using an intel chipset so not an AMD only problem. I also have windows 7 running in a virtual machine and running CHKDSK there yields the same problem...you would have thought something so obvious would have been picked up in alpha testing....let alone beta and even the Release candidate...That aside...great impression so far of windows 7 :)
Free Windows Admin Tool Kit Click here and download it now
June 2nd, 2009 10:35pm

Well, I did a little more testing and this is what I found: (tests are all done on the same 32GB USB flash drive I have been using throughout)Filesystem - disk space used - chkdsk memory usage (maximum level reached during chkdsk /r)--exfat - 0 - 5408kexfat - 1.42GB - 5416kfat32 - 0 - 10,284kfat32 - 1.42GB - 10,336kntfs - 0 - 23,712kntfs - 1.42GB - 1,431,192kntfs - 2.54GB - 2,610,344k(if anyone is wondering what kind of files make up the 1.42GB they are a bunch of savegames at about 1 - 2 MB each)From my tests it looks like the problem is limited to NTFS, and seems to be closely related to the amount of files on the disk. Could chkdsk possibly be trying to load all the files on the disk into memory and then failing to unload them? The memory usage hits its peak once stage 4 completes, and it does not increase at all during stage 5.After I did this I was thinking maybe the issue was limited to stage 4 of chkdsk, but I took a 500GB drive I have that is about half full and ran chkdsk /f, and the memory usage got to 1.7GB before it completed.
June 3rd, 2009 3:38am

What happens when other programs are using a lot of memory? In other words if the computer is just running chkdsk it would make sense for it to grab as much RAM as it can to get the job done quickly. To find out what's really happening you'd have to run a very large series of different tests. Some with only chdsk running. Some with a lot of programs running at the same time. Some with various programs starting and ending while chkdsk is running. It may be that chkdsk is optimized to use as much memory as possible without impacting system performance. Kerry Brown MS-MVP - Windows Desktop Experience
Free Windows Admin Tool Kit Click here and download it now
June 3rd, 2009 8:20am

i can understand tha completely but i have tested the speed on an external drive in both vista and windows 7, speed of the check is almost identical.Secondly in vista memory usage is really minimal. I just tried running a CHKDSK ona local disk and at the same time in a virtual machine on the same PC. Both fighting for the memory and disk check was then SLOWER on the disk than the first time....STRANGE
June 3rd, 2009 10:34am

I thought the behaviour might be by design at first too, but I don't think it is because:1. chkdsk does not do this on filesystems other than NTFS2. chkdsk does not seem to be any faster than in vista, and to be honest I don't think chkdsk really needs those resources. I would say chkdsk's speed is definitely determined by the speed of the hard disk on any modern computer (with the exception of maybe SSDs in RAID?)3. the high memory usage of chkdsk -does- impact system performance. If I run chkdsk /f on a full 1TB disk it consumes all available system memory (I have 4GB and physical memory usage pegs at 99%), and the system slows to a crawl. If I run chkdsk /r on a disk with more than about 5GB of data on it the same thing happens. Also (this is how I discovered the behaviour initially) I used to be able to run 4 instances of chkdsk at the same time on 4 hard drives (since chkdsk is so easy on system resources... normally) without any issues, but now if I do that you can see all 4 instances fighting for RAM (and the system is very slow once again). I have a screenshot of task manager where the 4 instances are using 1.7GB, 1.2GB, 340MB, and 161MB of RAM. Once system memory gets full like this even chkdsk itself seems to get slower, although by this time it is usually on stage 4 where it is hard to tell.Lately I've been wondering if I could copy the chkdsk.exe from my vista machine to my win7 machine and see if that improves the situation. Would I have to copy autochk.exe over as well, I wonder?
Free Windows Admin Tool Kit Click here and download it now
June 3rd, 2009 4:52pm

Lately I've been wondering if I could copy the chkdsk.exe from my vista machine to my win7 machine and see if that improves the situation. Would I have to copy autochk.exe over as well, I wonder? For anyone who is wondering if the above is possible, the answer is no. I copied chkdsk.exe and autochk.exe over from an install of Vista x64 (no service packs) and it crashes ("chkdsk.exe has stopped working..."). I guess anyone who wants to run chkdsk in Win7 is going to have to wait for Microsoft to fix this first (hopefully they know about it)
June 7th, 2009 11:42pm

Any info about this? Is it present in RTM ? I have 8GB of ram and page file turned off. CHKDSK runs for a few minutes leaking memory, and then after leaking about 7GB of RAM windows shuts it down because of low memory situation. This is definitely not by design ;)
Free Windows Admin Tool Kit Click here and download it now
July 22nd, 2009 12:38pm

Could this leak cause my issue: My laptop with win7 RC needs to have its HD checked. However, the boot time scan is hanging at 1 second on the countdown and the keyboard is non-responsive. Anyone else have an issue like this? It took me a couple of reboots to get past it by typing on the keyboard right away.
July 22nd, 2009 1:10pm

I have the same "1 second" countdown hang as well. I just upgraded RC to RTM last night. This morning I did a reboot and got the chkdsk notice and hang. It did the same thing during the next two attempts to run chkdsk. I have yet to get past that prompt. Ideas?
Free Windows Admin Tool Kit Click here and download it now
August 22nd, 2009 6:43pm

Hi, everyone.I upgraded from Vista Business x64 SP2 to 7 Enterprise RTM and I'm having the same problem described here. Task Manager shows the chkdsk.exe process consuming 2.5 GB of my 4 GB system and performance is considerably degraded. Hope someone at MS will fix this soon...Regards.
September 26th, 2009 11:30pm

Not a memory leak. It is chkdsk getting as much memory as it can to start the scan and keep it somewhat fast. From personal experiences though, it doesn't actually speed it up *that* much, as there is a cutoff point (epicallythose with 8+ gigs of ram). A small workaround that I have found works is to start up a Virtual Machine, and let itacquireits normal amount of memory. (mine is set to 3 gigs of my total 8 gigs). (can probably use a free ramdisk software to do somethingsimilar) After the VM/Ramdisk has aquired the ram, start a chkdsk /r. once the checkdsk gets to stage 4 of 5 ( the long parts), kill the VM or Ramdrive. The ram will befreed, and chkdsk will not consume more than it has already done. Presto, chkdsk runs fine and doesn't bog down your system any as you will have (in my case) 3+ gigs free.
Free Windows Admin Tool Kit Click here and download it now
November 23rd, 2009 3:40am

I've had the 1-second countdown problem as well. It's been extremely frustrating. I finally found that Microsoft released a hotfix for it about a week ago. The link is: http://support.microsoft.com/kb/975778 Make sure to use internet explorer when requesting the hotfix, as it incorrectly detected my system as 32-bit when using Firefox. It'll e-mail you a link to download the hotfix with a unique password, which you have to insert when extracting, after which everything will be solved when you execute the extracted file! Hope this helps to solve this problem.
November 26th, 2009 10:15am

I found this blog post: http://blogs.msdn.com/e7/archive/2009/08/10/what-we-do-with-a-bug-report.aspxIt's from August. Unfortunately it seems they're not planning to further address the memory consumption issue.I suggest you consider the fact that we users usually have many activities underway in our computer. Surely checking and fixing a hard disk is important and we would the process to complete as fast as possible. However, not in a way that degrades overall system performance so severly that affects our ability to be productive in other tasks while a disk is being checked. I hope you'll consider adding some switch to specify what percentage of system resources should be allocated for the chkdsk process, or perhaps a way for chkdsk to release some memory when not being the active window or when overall memory utilization is over some threshold.Robotsrock, did the hotfix change anything about memory allocated to the chkdsk process?Thanks
Free Windows Admin Tool Kit Click here and download it now
November 26th, 2009 2:10pm

Not a memory leak. It is chkdsk getting as much memory as it can to start the scan and keep it somewhat fast. From personal experiences though, it doesn't actually speed it up *that* much, as there is a cutoff point (epicallythose with 8+ gigs of ram). A small workaround that I have found works is to start up a Virtual Machine, and let itacquireits normal amount of memory. (mine is set to 3 gigs of my total 8 gigs). (can probably use a free ramdisk software to do somethingsimilar) After the VM/Ramdisk has aquired the ram, start a chkdsk /r. once the checkdsk gets to stage 4 of 5 ( the long parts), kill the VM or Ramdrive. The ram will befreed, and chkdsk will not consume more than it has already done. Presto, chkdsk runs fine and doesn't bog down your system any as you will have (in my case) 3+ gigs free. I think it is pretty much by definition a memory leak (http://en.wikipedia.org/wiki/Memory_leak) although as the article says you would need to see the source code to know for sure, and I don't think MS either has any plans to release it or to admit the existence of a leak if there is one. The chkdsk application seems (in my experience) to be limited by the speed of the hard disk and not the amount of available memory. Maybe it's time for me to stop being lazy and do a timed run of chkdsk /r on my xp 32-bit machine and my 7 64-bit machine and see which finishes it faster. I'm confident that the xp machine will be done sooner while only using about 20MB of RAM as opposed to all available system memory. I think it's maybe wishful thinking when people say "it uses more memory in order to improve its speed". I don't think MS would ever intentionally design a program to use all available system memory at the expense of other running applications. They could have designed it to use even 75% of the free system memory, performance would be similar (if not identical) and the system would still be usable for other tasks while the check is running.I like your idea of using a VM as a memory "spacer" of sorts to keep chkdsk out of your memory, though we shouldn't have to.
November 26th, 2009 11:40pm

I'm not sure how this affects memory allocation. According to the article, computers with infrared devices seem to be more likely to incur this problem. I had a HP dv7t with an infrared receiver that always used to pause on the countdown at 1-second and then totally freeze. Then chkdsk would attempt to re-run every time the computer booted up until disabled from the command prompt, causing a lot of problems as I couldn't get to the login page! That hotfix solved the problem. after months of issues. I was always able to run chkdsk within windows7, but couldn't fix issues there as it had to be run during a restart/start-up. Hope this helps.
Free Windows Admin Tool Kit Click here and download it now
November 28th, 2009 9:14am

Just confirming: CHKDSK (no /r) on retail Windows 7 Ultimate running in a VMware virtual machine consumes an ever increasing amount of memory while running, though in my case it finished checking the 64 GB C: drive before even half the available memory is used.-Noel
November 29th, 2009 4:46am

This is with the final Windows 7 x64 Ultimate the same - and well, it consumes as much memory as possible, on my PCs (12GB / 24GB RAM) it consumes as much RAM as up to nearly 1GB left...Parameters seems not make the difference as well, and in terms of speed - it does not differ in any way from a parallel installed Vista x64 Ultimate... Well, maybe there is a fix or tip on how to handle this, since it is really annoying.Doing something right does mean noone takes notice.
Free Windows Admin Tool Kit Click here and download it now
March 17th, 2010 10:26pm

It sure would be nice to get an indication from Microsoft on whether this is intended behavior; perhaps the increased memory usage is an enhancement to CHKDSK to make it more capable or robust in the new OS...If is using the memory on purpose, and is the most capable CHKDSK yet, then that would be okay. If I'm running CHKDSK I am willing to have it use any and all resources in my computer to get the job done in the best way possible.If it's because of a leak/bug, and it's doing no better a job than its predecessor from Vista that doesn't use huge resources, that's NOT okay. We DO have other uses for the computer resources (e.g., getting work done).-Noel
March 18th, 2010 5:55pm

I believe this issue will be addressed according to MS internally assigned priority. I believe it does help, though, to let MS know we're still waiting for an answer, by posting on this thread :)Regards,Mario
Free Windows Admin Tool Kit Click here and download it now
March 18th, 2010 6:35pm

im running chkdsk /r on a internal sata 250gb. its taking about 7gb of ram O_O (actually 6.815gb to be precise) but yeah.. lol i havent tried the "fix" yet cuz.. well it is not related to the issue . i hope M$ pay us some attentionuh.. none
April 5th, 2010 5:47pm

Interesting that the blog article linked-to above yields this insight from Microsoft: The file system team immediately began to look into the issue. They too were unable to reproduce the crash and from their perspective the memory usage was by design and was a specific Windows 7 change for this scenario (the /r flag grabs an exclusive lock and repairs a disk and so our assumption is you’d really like the disk to be fixed before you do more stuff on the machine, an assumption validated by several subsequent third party blog posts on this topic). So it IS by design that CHKDSK /r uses all the memory it can find. Any subsequent crashes because of the memory being used up, or possibly because of the use of memory in a way different than typical (e.g., a bad location high up that's not usually used) are a separate issue, and may simply be uncovering some latent instability in the computer system. -Noel
Free Windows Admin Tool Kit Click here and download it now
April 6th, 2010 5:06pm

I would REALLY like to do more stuff on the machine before the disk is fixed, especially if it isn't the system disk the one being checked. Regards
April 6th, 2010 9:18pm

I would REALLY like to do more stuff on the machine before the disk is fixed, especially if it isn't the system disk the one being checked. Given that file systems shouldn't need fixing very often if at all, what is it you're doing that's causing the need for CHKDSK /r? -Noel
Free Windows Admin Tool Kit Click here and download it now
April 6th, 2010 9:27pm

Hi, Noel. Thanks for your reply. External hard disks are sometimes not removed correctly and thus the file system gets corrupted. Ocasionally they may also suffer physical damage. I understand that in those situations it is strongly recommended to run chkdsk /r in order not to risk an unexpected failure in the future. I agree it is not a very frequent operation, but when required, it is quite a nuisance that system resources are so dramatically drained, especially considering it might take several minutes for the operation to complete. Hope you consider adding some switch to limit resources the command allocates. Best regards, Mario
April 7th, 2010 4:14am

Hope you consider adding some switch to limit resources the command allocates. Just to be clear, I'm not Microsoft and do not represent them. Your wording implies that you think I may. I'm thinking you're speaking more hypothetically than from experience here... Please correct me if I'm wrong. In real practice (based on my own experience managing many computers) one only VERY rarely has to do a CHKDSK /r to repair the file system on a disk. Windows simply doesn't shut down dirty very easily, even with external drives. Not only that, but the likelihood that you'll 1. need to fix a corrupted drive and 2. be able to use the system otherwise more or less normally seems small. That said, with a particular configuration, such as you've noted, one can easily imagine a scenario that goes against these assumptions. But would having recovery algorithms that work two different ways be a good idea? Wouldn't you want the very best possible algorithm (and not, say, a "second best" algorithm that saves memory) put to the task of restoring your corrupted file system? You'd be WAY ahead to put more energy into developing practices that prevent the corruption in the first place and not worrying about the resources CHKDSK has to use to fix corruption. -Noel
Free Windows Admin Tool Kit Click here and download it now
April 7th, 2010 5:13pm

Hi, Noel. Thanks for your reply. I'm sorry if my wording led to think you work for MS. As for the algorithm effectiveness, I agree I wouldn't want to sacrifice effectiveness. However, I think it's not effectiveness, but efficiency we're talking about here, and personally I prefer to wait longer for the disk being fixed, if that allows me to perform other tasks without affecting my system performance. If effectiveness was at risk, then I think system requirements for CHKDSK would have to be specified apart from Windows 7. Otherwise, one would expect CHKDSK to work just as effectivelly with, say 2 GB or 8 GB, it'll just take longer. Regards, Mario
April 11th, 2010 11:42pm

Very good point about it being able to run in 2 GB. This is what bothers me... If CHKDSK wants to use a huge memory allocation to get its job done, is it actually WRITING files to the disk when there's not enough memory to cache all its data? Or is it just less efficiently regenerating the same data by re-reading the disk? It's not hard to see how writing to the disk could complicate matters, when it's a bad file system we're repairing here. Even re-reading gets complicated when we're fixing the very things we're reading. As none of us can see inside CHKDSK to see what it actually does, we may not know whether we're talking effectiveness or just efficiency here. -Noel
Free Windows Admin Tool Kit Click here and download it now
April 12th, 2010 1:33am

Interesting that the blog article linked-to above yields this insight from Microsoft: The file system team immediately began to look into the issue. They too were unable to reproduce the crash and from their perspective the memory usage was by design and was a specific Windows 7 change for this scenario (the /r flag grabs an exclusive lock and repairs a disk and so our assumption is you’d really like the disk to be fixed before you do more stuff on the machine, an assumption validated by several subsequent third party blog posts on this topic). So it IS by design that CHKDSK /r uses all the memory it can find. Any subsequent crashes because of the memory being used up, or possibly because of the use of memory in a way different than typical (e.g., a bad location high up that's not usually used) are a separate issue, and may simply be uncovering some latent instability in the computer system. -Noel noel - Oh geeze... Randall C. Kennedy's FUD pile STILL has traction!??!? GAH! For the record, Randall C. Kennedy has been exposed for what he is - a fraud who has an Anti Microsoft bias. ZDNet has an expose on his latest attempt at spreading nonsense about Windows 7. He was the one who originally dug up this "bug" back about the time Windows 7 was supposed to be RTM'ed. It was immediately shot down as being nothing but FUD. Of course it's by design. Would you rather sit there for 3 hours while Chkdsk ran in 640 KB or would you rather zip through the process as quickly as possible by using as much RAM as the system has available? Honestly, I vote get it over with ASAP, myself.
April 12th, 2010 4:50pm

Well, A) I fully agree that it's really a non-problem (you can see that plainly in all my posts above); but B) I have never heard the name Randall C. Kennedy nor have any of his biases influenced my responses here - as far as I know; and C) I have no idea what the acronym FUD means, though I can guess. My own computers don't crash on CHKDSK operations, though I can easily believe that there are machines with combinations of hardware and software that do under a full-memory condition. -Noel
Free Windows Admin Tool Kit Click here and download it now
April 12th, 2010 6:08pm

Noel - It's not you... Sorry if I made it sound like you're the one I was skewering. Randall C. Kennedy is a guy who used to blog for infoworld.com. And by 'used to' - he got fired after it was found that his alter ego - "Craig Barth" reported some nonsense about most Windows 7 machines are constantly using 86% of their RAM. He used the alias to run a company - Devil Mountain Software that did 'metrics' of Windows based systems. Read the link above in my previous post. It's quite amusing. The thing I was upset about is the fact that this non-issue is still being bounced around the Internet. It's like once you start a ball of FUD rolling, it never seems to stop.
April 13th, 2010 1:32am

I've run chkdsk in a few different scenarios on my vista and 7 machines and maybe I'm not encountering the right conditions but I haven't seen anything to back up the "7's chkdsk is faster because it uses more RAM" claim. Has anyone found a situation where it was actually faster? All my runs were very close. Also I think there's a bit of a misconception about it being limited to chkdsk /r - with either the /r or /f switch chkdsk reserves 20 - 25MB of RAM for every second that passes. It's easier to see with the /r switch because the check takes so long, but if you have a large, slow hard drive with a lot of small files on it the /f switch can easily reserve 1GB of memory or more. I think we can all agree that chkdsk isn't a tool that needs to be used on a regular basis but I don't think that should be an excuse for not fixing (what I believe to be) a legitimate problem with it. I could be wrong and there could be a scenario where the new chkdsk is significantly faster than the old one and it warrants the extra memory usage, but I just haven't been able to find it.
Free Windows Admin Tool Kit Click here and download it now
April 25th, 2010 8:51pm

Maybe it's not faster but somehow more accurate or more likely to correct problems successfully? Without looking into the implementation, it's impossible to know what's better, or really even if anything's better, but it's been stated it's allocating this memory by design. We have no choice but to live with it. There are a LOT more important glaring problems in Windows 7. -Noel
April 25th, 2010 9:38pm

There are a LOT more important glaring problems in Windows 7. -Noel maybe. but they are not the subject of this thread.
Free Windows Admin Tool Kit Click here and download it now
April 25th, 2010 10:54pm

There are a LOT more important glaring problems in Windows 7. -Noel maybe. but they are not the subject of this thread.
April 25th, 2010 10:54pm

Do you honestly think that, assuming the memory usage by CHKDSK is not an out and out bug, but actually represents an intentional design change, that you will influence Microsoft to return CHKDSK to the prior implementation just so it's not as intensively using the memory? If this is the biggest problem you are facing, you live a charmed life. I should hope Microsoft spends every waking minute cleaning up the mega problems in Explorer and Windows Search before spending even a second on this "issue" with CHKDSK. -Noel
Free Windows Admin Tool Kit Click here and download it now
April 25th, 2010 11:13pm

Maybe it's not faster but somehow more accurate or more likely to correct problems successfully? Without looking into the implementation, it's impossible to know what's better, or really even if anything's better, but it's been stated it's allocating this memory by design. We have no choice but to live with it. There are a LOT more important glaring problems in Windows 7. -Noel When you say "it's been stated it's allocating this memory by design" are you referring to the following quote from http://blogs.msdn.com/e7/archive/2009/08/10/what-we-do-with-a-bug-report.aspx "from their perspective the memory usage was by design and was a specific Windows 7 change for this scenario (the /r flag grabs an exclusive lock and repairs a disk and so our assumption is you’d really like the disk to be fixed before you do more stuff on the machine, an assumption validated by several subsequent third party blog posts on this topic)." He states that the behavior is limited to the /r switch but I've seen it with the /f switch - the memory usage increases just as quickly, the only reason it doesn't get as high is because chkdsk /f doesn't take as long. It might be nice to get a little more information from someone on the "file system team", but if they truly have looked at the issue as he stated in the blog, then it either isn't a bug or it is but it would be too much work to fix when weighed against the small number of complaints. Anyway, I don't want to get off topic, and I think it's fine if you disagree with me, but I just genuinely want to hear from other people that are facing the same "issue" that we are (if you can call it that). Who knows - maybe there is someone out there with a specific configuration whose chkdsk only uses the good old 30MB or so of RAM and he can give us all a little advice.
May 11th, 2010 2:08am

"the /r flag grabs an exclusive lock and repairs a disk and so our assumption is you’d really like the disk to be fixed before you do more stuff on the machine, an assumption validated by several subsequent third party blog posts on this topic" This could be true when checking the system disk, but not when the disk being checked is a removable/external hard drive. Having the system grind to a halt with 85% memory usage (8GB RAM) while checking an external drive is a bit excessive in my opinion. Especially considering the time it takes to check a large drive. Perhaps the "bug" is in failing to distinguish between such use cases.
Free Windows Admin Tool Kit Click here and download it now
June 27th, 2010 8:16am

I fully agree with Paul. Repairing a disk is usually considered of the utmost importance. However, that is not always the case, and one may want to perform other tasks with higher priority on the system while an external drive is being repaired with less priority. Unfortunately that is not possible if memory resources are almost fully allocated to reparing the disk. Glad to see others share my point. Regards
June 27th, 2010 8:21am

I suggest using the reboot chkdsk mode so that maximum resources are available for it. Vote if answered or helpful, I am running for Office (joke)! IT/Developer, Windows/Linux/Mainframe Need a some parts finish the new server, see the site for remaining items needed
Free Windows Admin Tool Kit Click here and download it now
June 27th, 2010 5:47pm

I suggest using the reboot chkdsk mode so that maximum resources are available for it. Vote if answered or helpful, I am running for Office (joke)! IT/Developer, Windows/Linux/Mainframe Need a some parts finish the new server, see the site for remaining items needed
June 27th, 2010 5:47pm

"the /r flag grabs an exclusive lock and repairs a disk and so our assumption is you’d really like the disk to be fixed before you do more stuff on the machine, an assumption validated by several subsequent third party blog posts on this topic" This could be true when checking the system disk, but not when the disk being checked is a removable/external hard drive. Having the system grind to a halt with 85% memory usage (8GB RAM) while checking an external drive is a bit excessive in my opinion. Especially considering the time it takes to check a large drive. Perhaps the "bug" is in failing to distinguish between such use cases. As I mentioned earlier in the thread, I think the "/r flag grabs an exclusive lock" is a misconception. Chkdsk with either the /r or /f flag will reserve about 30MB of memory for every second it runs - the only difference is that it runs for a lot longer with the /r flag.
Free Windows Admin Tool Kit Click here and download it now
June 27th, 2010 8:57pm

I suggest using the reboot chkdsk mode so that maximum resources are available for it. Is there a way how to apply the /r switch with "reboot chkdsk"? For what I know, you can only do reboot check by marking the disk dirty. And then, it will do the normal file system check, no check for bad sectors. I also noticed that I don't have the memory leak if I don't have any files on the disk. This I find a bit weird.
September 27th, 2010 4:09pm

you can do that from the command prompt chkdsk /r that is the only way to use command line options conveniently, otherwise you would need to make a special shortcut with the specific command line options needed. Vote if answered or helpful, I am running for Office (joke)! IT/Developer, Windows/Linux/Mainframe I also am a true vegan and I am very good with economics and I used to play chess at 2400++ I have lots of papers on my site for power supplies and video card problems, see the resources section
Free Windows Admin Tool Kit Click here and download it now
September 27th, 2010 4:45pm

you can do that from the command prompt chkdsk /r that is the only way to use command line options conveniently, otherwise you would need to make a special shortcut with the specific command line options needed. Vote if answered or helpful, I am running for Office (joke)! IT/Developer, Windows/Linux/Mainframe I also am a true vegan and I am very good with economics and I used to play chess at 2400++ I have lots of papers on my site for power supplies and video card problems, see the resources section
September 27th, 2010 11:43pm

Thanks Jarno for your response "I also noticed that I don't have the memory leak if I don't have any files on the disk. This I find a bit weird." I formatted the drives I was checking and voila no problem. While this may not be an "issue" for most consumers, Microsoft may want to help out their IT crowd a bit with this one. I have used "chkdsk /r" forever with a USB HD drive adapter to check laptop or desktop hard drives that I am not sure of, which assist me in troubleshooting problems with people machines, especially when they won't boot. Furthermore, when we retire machines we use a program to "kill" the disks random 0 and 1, several passes, then we pop the HD back into the machine. These machines are donated to local charities, people we work with, etc. True our "kill" program will tell us if there is an error with the hard drive, but that can take a while as the passes take hours to complete. Running "chkdsk /r" used to be a quick way for me to see if a drive was worth donating or if it should be headed for physical destruction instead. While it does still work, it does seem very strange to me that by design it is supposed to use that much memory, but if you format the drive before running it, it only uses 26MB of Ram to complete the same command. This leads me to believe that it actually is not a feature and is a bug. That and the fact that it used all of my memory and then started using Virtual Memory, I was showing that it was using 6.6GB of RAM and I only have 4 GB of Physical RAM. Granted I want "chkdsk /r" to run fast and I now have a workaround for those drives that are ready to be wiped, but how about the ones I am testing for live machines that cannot boot...I don't want to format them before running "Chkdsk /r" and I want to do it from my machine to see if I can get the data from them afterward if needed. But I can't do normal activities on my machine, like check email, respond to our Helpdesk tickets through our Web Page. By the way, I have had my machine become almost unresponsive several times while running "chkdsk /r" in Windows 7.
Free Windows Admin Tool Kit Click here and download it now
November 12th, 2010 9:46am

I suggest checking all system files. in the command prompt run sfc /scannow and use you Windows disk if its requersted Elected! Your votes and support have got me my 2010 MVP! Developer | Windows IT | Chess | Economics | Hardcore Games | Vegan Advocate | PC Reviews
November 12th, 2010 2:12pm

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics