none
Windows 7 chkdsk memory leak?

    Question

  • 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.5MB
    7 : 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.
    Tuesday, June 02, 2009 4:26 PM

Answers

  • 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.

    Monday, May 10, 2010 11:08 PM

All replies

  • yup mines doing the same, even on local disks....climbs at an alarming speed
    Tuesday, June 02, 2009 5:49 PM
  • 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 well
    Win7 7100 x64 - AMD SB600 southbridge w/ Catalyst driver suite 8.612 (WHQL) - only tested on a USB device

    Maybe it's AMD chipset related?
    Tuesday, June 02, 2009 7:06 PM
  • 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 :)
    Tuesday, June 02, 2009 7:35 PM
  • 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 - 5408k
    exfat - 1.42GB - 5416k
    fat32 - 0 - 10,284k
    fat32 - 1.42GB - 10,336k
    ntfs - 0 - 23,712k
    ntfs - 1.42GB - 1,431,192k
    ntfs - 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.
    Wednesday, June 03, 2009 12:38 AM
  • 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
    Wednesday, June 03, 2009 5:20 AM
  • 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 on a 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
    Wednesday, June 03, 2009 7:34 AM
  • 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 NTFS
    2. 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?
    Wednesday, June 03, 2009 1:52 PM
  • 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)
    Sunday, June 07, 2009 8:42 PM
  • 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 ;)
    Wednesday, July 22, 2009 9:38 AM
  • 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.
    Wednesday, July 22, 2009 10:10 AM
  • 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?

    Saturday, August 22, 2009 3:43 PM
  • 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.

    Saturday, September 26, 2009 8:30 PM
  • 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 (epically those with 8+ gigs of ram).

    A small workaround that I have found works is to start up a Virtual Machine, and let it acquire its normal amount of memory. (mine is set to 3 gigs of my total 8 gigs).
    (can probably use a free ramdisk software to do something similar) 

    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 be freed, 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.

    Monday, November 23, 2009 12:40 AM
  • 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.
    • Proposed as answer by robotsrock Thursday, November 26, 2009 7:15 AM
    Thursday, November 26, 2009 7:15 AM
  • I found this blog post:  http://blogs.msdn.com/e7/archive/2009/08/10/what-we-do-with-a-bug-report.aspx

    It'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
    Thursday, November 26, 2009 11:10 AM
  • 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 (epically those with 8+ gigs of ram).

    A small workaround that I have found works is to start up a Virtual Machine, and let it acquire its normal amount of memory. (mine is set to 3 gigs of my total 8 gigs).
    (can probably use a free ramdisk software to do something similar) 

    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 be freed, 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.
    Thursday, November 26, 2009 8:40 PM
  • 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.
    Saturday, November 28, 2009 6:14 AM
  • 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

    Sunday, November 29, 2009 1:46 AM
  • 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.
    Wednesday, March 17, 2010 7:26 PM
  • 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
    Thursday, March 18, 2010 2:55 PM
  • 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

    Thursday, March 18, 2010 3:35 PM
  • 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 attention


    uh.. none
    Monday, April 05, 2010 2:47 PM
  • 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

    Tuesday, April 06, 2010 2:06 PM
  • 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

    Tuesday, April 06, 2010 6:18 PM
  • 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

    Tuesday, April 06, 2010 6:27 PM
  • 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

    Wednesday, April 07, 2010 1:14 AM
  • 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

    Wednesday, April 07, 2010 2:13 PM
  • 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

    Sunday, April 11, 2010 8:42 PM
  • 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

    Sunday, April 11, 2010 10:33 PM
  • 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.

    Monday, April 12, 2010 1:50 PM
  • 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

     

    Monday, April 12, 2010 3:08 PM
  • 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.

    Monday, April 12, 2010 10:32 PM
  • 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.

    Sunday, April 25, 2010 5:51 PM
  • 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

    Sunday, April 25, 2010 6:38 PM
  • There are a LOT more important glaring problems in Windows 7.

    -Noel


    maybe.  but they are not the subject of this thread.
    Sunday, April 25, 2010 7:54 PM
  • 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

    Sunday, April 25, 2010 8:13 PM
  • 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.

    Monday, May 10, 2010 11:08 PM
  • "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.

    Sunday, June 27, 2010 5:16 AM
  • 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

    Sunday, June 27, 2010 5:21 AM
  • "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.
    Sunday, June 27, 2010 5:57 PM
  • 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.

    Monday, September 27, 2010 8:07 PM
  • 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.


    Friday, November 12, 2010 2:44 PM
  • Suffering with this problem also.

    I have 6.3gb of available memory (8gb, Win7-64) and doing a chkdsk is using ALL available memory, what's going on with this bug?

    Sunday, July 17, 2011 1:04 PM
  • what's going on with this bug?


    Why do you think it's a bug?  I don't see a lot of reports that CHKDSK doesn't deliver proper results.

    You asked your system to do the best job it possibly can in checking the disks.  It has all that memory, which it uses if it can to make the process work more efficiently.

    Beyond that...  Why are you having to run CHKDSK?  I haven't found a reason to run that in months.  Are you seeing disk corruption?  That should be exceedingly rare.

    -Noel


    Sunday, July 17, 2011 11:37 PM
  • Disks have issues, I need to run CHKDSK to perform a diagnosis on a serious issue with the workstation.

    This is a bug (or fault with my install of Windows 7) this is not something where more resources are being allocated because they are available, it's a DOS level application chewing not only 6gb of ram but ending up failing out with out of memory Windows errors.
    Something is clearly going wrong, this is not standard behaviour

    Monday, July 18, 2011 11:52 AM
  • Are you seeing out-of-memory failures on a CHKDSK scheduled to run at bootup?

    -Noel

    Monday, July 18, 2011 12:35 PM
  • May I recommend an enterprise class drive, such as a Western Digital RE4.  Got 'em in a RAID and love 'em!  High reliability, low noise, low heat, low vibration, fast controllers, and not even altogether too expensive...  Nothing not to like!

    -Noel


    Monday, July 18, 2011 1:49 PM
  • Some of the comments here are embarassing for any hardware gurus to endure.  I'm sure I'm not the only one cringing here.

     

    I do not magically have 3 faulty SATA disks out of the blue.  I have a software issue on my PC.  It may not be a bug, it may be something is broken due to software installed but I in no way have a physical hardware issue.

    I will say I haven't done a boot level chkdsk but I can't - /R is no longer prompting for some weird reason, it's very odd behaviour all round.

    To 100% clarify my hardware theory, I'm running a DOS / BIOS level bootable disk check this evening.  I expect to find nothing wrong tomorrow.

    Monday, July 18, 2011 3:55 PM
  • Embarrassing?  Is there something wrong with the statement that CHKDSK should not normally be needed?  Software doesn't normally corrupt disks either.  Don't forget that you didn't say the issue was on 3 different disks until your last post.

    That said, I do know of one OLD software issue that could cause the appearance of a corrupted drive, but in reality the disk is fine...  I would have thought it should be fixed by now, though, since it was pre-SP1...

    The "Atomic Oplock" facility used by the Indexer can cause a failure when using certain applications (e.g., Subversion), resulting in a disk that informs you it's corrupted and that CHKDSK needs to be run.  Check out this thread:  http://social.technet.microsoft.com/Forums/en/w7itprogeneral/thread/df935a52-a0a9-4f67-ac82-bc39e0585148

    Could this be similar to what's happening to you?

    The workaround is to disable Indexing.

    -Noel


    Monday, July 18, 2011 6:31 PM
  • what's going on with this bug?


    Why do you think it's a bug?  I don't see a lot of reports that CHKDSK doesn't deliver proper results.

    You asked your system to do the best job it possibly can in checking the disks.  It has all that memory, which it uses if it can to make the process work more efficiently.

    Beyond that...  Why are you having to run CHKDSK?  I haven't found a reason to run that in months.  Are you seeing disk corruption?  That should be exceedingly rare.

    -Noel


    I have an answer to all your questions, including my opinion about why it is a bug:

    Let's say i have an external HDD in an enclosure which i accidentaly knock down. I naturally want to check if bad sectors appeared. So I run chkdsk /r on a drive that is anything but huge: 180GB. In a few minutes, all my 7GB+1GB swap are eaten (i have noticed before that either explorer if you run the check using the drive Tools or chkdsk eat up memory).

    After a bit, the Low Virtual Memory window appears. Then programs start to hang and some even crash (i was running just Winamp and Skype and other background services that always run). Event viewer says:

    "Windows successfully diagnosed a low virtual memory condition. The following programs consumed the most virtual memory: chkdsk.exe (6608) consumed 5715902464 bytes, "
    then
    "The program winamp.exe version 5.6.2.3173 stopped interacting with Windows and was closed."
    then skype, then... everything. I event tried to reboot and, surprise, it asked me if i want to forcibly terminate.. explorer.exe which was playing the logout song :)) "The program explorer.exe version 6.1.7601.17567 stopped interacting with Windows and was closed. "

    Basically, my computer became unusable because i ran chkdsk /r on an 180GB drive after a fresh reboot with 2-3 programs running and 8GB of ram. Yes Microsoft, very well designed, indeed.

    When the system tries to do "the best job" in recovering some bad sectors, should NOT under any circumnstances eat up that amount of memory. It can be scanned/processed/fixed by chunks. If the old Norton Disk Doctor running on a 4x86 with 1MB of memory would have behaved the same, what then? There are tens of disk scanners, on all platforms, NONE behaves like this. It should be about blocks, not the whole file system, but what do I know?

    "allocates/consumes memory by design" is, and I'm sorry, a stupidity and and insult for people like me which use and program computers for some time now. It is just a political answer, but obviously they are "looking into the matter" :). It looks like a memory leak and it behaves like one.

    It is common knowledge that harddrives appeared because RAM is limited in size and expensive and volatile while drives offer permanent storage and in great quantities and cheap while remaining the slowest component in a computer, but trying to put all or as much as possible data from a drive into memory it will NEVER EVER WORK as long as memory is what it is today.

    Microsoft, can you hire me as a designer, I think I can do better :)

    In conclusion, I see that no fixes are provided.

    I wonder if this is just because the issue is rare in one's Windows 7 based PC lifetime, so in this case... the solution is the well-known with Windows:  reboot, because... don't we all know, nothing can be done without reboot :)))



    Thursday, July 28, 2011 9:52 PM
  • I am sorry, i just don't buy that. I just said that there were actually no programs opened, Winamp and Skype is nothing. What do you suggest, to run chkdsk in safe mode? :))) It will still Not be enough, i have drives of 1TB, what then? :) How do you actually determine if there is or not a defect to this program? If there is no defect reported does not mean that it's flawless.

    I understand it is very resource (err.. memory) intensive, but this is just plain ridiculuous. It just eats up ALL the available memory, be it 1GB or 10GB of ram.

    1MB of RAM will never be cheaper than 1MB of disk. Still, since when is a good idea to buy some more ram or additional hardware just because a rather unused program is malfunctioning or poorly designed?

    This issue - afaik - was not (and please correct me if I'm wrong) present in XP. Has NTFS for Win7 changed so much that requires this new "design" for the check utility? I seriously doubt it.

     



    Thursday, July 28, 2011 10:53 PM
  • Don't worry about these guys.  I'm going to do some testing this weekend to figure out the problem, some of these guys have a complete lack of memory when it comes to chkdsk.

     

    Friday, July 29, 2011 12:10 AM
  • are you one of the developers that worked on Win7 chkdsk?

    @Vegan Fanatic: I have been using XP until Win7 was released with > 500GB drives, this issue was not there.

    Friday, July 29, 2011 12:51 AM
  • Sorry to reply to such an old topic but I might have something to lend to this as well. I ran chkdsk /r on an external disk today and found similar occurrances to what's described in this topic. My system has a lot of memory (16 GB) and chkdsk ran it the whole way up to 14.9 GB. Perhaps chkdsk is designed to use memory until there's only a certain percentage available? I'm not sure how this would affect performance but it was processing files much faster than my other computers (my CPU is also much faster, so my test would have to be refined to say for sure).
    Thursday, August 25, 2011 1:37 PM
  • Is this ever going to be fixed or classified as a bug, or at least changed in the way this operation is performed?

     

    I'm getting CRC error's when trying to copy/delete/access a file on my 2TB external drive.

    I would like to run scandisk/chkdsk but it keeps using all my available memory.

    I enabled virtual memory and set a max page file of 200GB, this helped avoid the "Close programs, out of memory" dialog box. 

    Chkdsk is running right now, using 3208512MB of memory (Physical Memory: 94-95%)

    Stage 4 of 5, 600/123,888 files checked, half hour elapsed, files as large as 6GB and as small as 1KB, any guess on how long this will take?

     

    Thursday, September 08, 2011 5:22 PM
  • Is this ever going to be fixed or classified as a bug, or at least changed in the way this operation is performed?

     

    I'm getting CRC error's when trying to copy/delete/access a file on my 2TB external drive.

    I would like to run scandisk/chkdsk but it keeps using all my available memory.

     


    Having used all the available memory, is it still running and making progress?  Or did it fail?

    If it's still running, why do you feel it's a bug?  Because you can't use anything else while it's running? 

    Ask yourself:  Why would you WANT to use anything else while your hard drive is being repaired?

    -Noel

    Thursday, September 08, 2011 6:27 PM
  • Is this ever going to be fixed or classified as a bug, or at least changed in the way this operation is performed? 

    This is not a bug, this is by design behavior.
    Thursday, September 08, 2011 6:44 PM
  • Then it's a flawed design. If I want chkdsk to eat up all my system memory, there should be an option to run it in "exclusive mode" or something, but by default it should run exactly as it does in Vista.

    assimilator of code
    Friday, September 09, 2011 5:09 PM
  • Could it be that the Windows 7 CHKDSK is more capable than Vista's version?

    Can those contributing to this thread PLEASE stop to think for a minute about why under any condition it would be reasonable to run other stuff when your computer is repairing your file system structure? 

    If you have file system problems you need to leave your computer alone until they're fixed!

    Not only that, but you really, REALLY need to get to the bottom of why you're having file system problems and fix the root cause of that!  It's not normal nor typical to have to run CHKDSK!

    -Noel

    Friday, September 09, 2011 5:34 PM
  • Then it's a flawed design.

    It is a reasonable design. If someone has hard drive troubles with a possible data loss isn't it better to run disk check as quickly as possible? Isn't this check the most important task?

    If there is no bad sectors on hard drive, there is no reason to start chkdsk /r at all. Simple file system check may be started without /r as chkdsk /f.


    Friday, September 09, 2011 5:58 PM
  • I hope it's buggy and not a normal behavior (or we should pay some serious coding course to some microsoft engineers)...

    I have 8gb of memory on my main pc (quad core) with 8gb swap and when i'm checking an external drive (some random usb storage drive and not my system disk!!) it consume all available memory (0 under free memory in the taskmgr and only 2% cpu usage) and then my high end pc behaves like an old timer pc (so slow i cannot use it normaly). On every other windows version before, i could do the same without any trouble at all!!

    And if it's not proof enough, i have a laptop with 8gb too and an ssd disk (with the swap file deactivated). When i do the same i have a very nice blue screen!!! WTF it's not a bug ###???!!! The microsoft way of thinking: buy more memory ...

    Wednesday, October 19, 2011 6:54 PM
  • Glad to see this old thread is still alive and kicking...

    For those who continue to say that chkdsk's extremely high memory usage in Windows 7 is a "feature", I can only reference my post from earlier in the thread:

    "2. 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."

    Also cr1cr1's experience with low virtual memory errors is a little alarming.

    On the plus side Microsoft appears to have fixed the bug in the Windows [8] Developer Preview.  I ran the test (chkdsk /r) on an 8GB USB drive formatted with NTFS containing about 1300 files, total size used 1.25GB

    run time: 1:05, CPU usage average 4%, Memory usage MAX 3.0 MB

    I ran the same test on my Windows 7 system:

    run time: 1:33, CPU usage average 2%, Memory usage MAX 1349.4 MB

    The systems are fairly similar, the first with a Phenom 2 1100T, Gigabyte 990FXA-UD3 (SB950), 4GB DDR3, and the second with a Phenom 2 940, Gigabyte 890GX-UD4P (SB750), 4GB DDR2.

    I wasn't surprised by the memory usage (well maybe pleasantly surprised) but I was surprised to see the Windows 8 system complete the check so much faster.  Maybe the SB950's USB controller is much faster for small random accesses, or maybe the drivers in Windows 8 are much better.  Windows 8's chkdsk did use significantly more CPU power (4% of a 6-core 3.3GHz vs. 2% of a 4-core 3.0GHz = about 3x the CPU usage) so maybe that's the answer.

    Anyway, the developer preview is currently a free download open to the public, so if you're a desperate chkdsk-a-holic then come on down:

    http://msdn.microsoft.com/en-us/windows/apps/br229516

    Saturday, October 29, 2011 6:15 AM
  • All indications are that Microsoft has continued their relatively new practice of optimizing the OS, so Windows 8 should be more efficient than Windows 7.

    By the way, it's not a given that the CHKDSK algorithm remains constant throughout all this.  It might just be that a Windows 7 CHKDSK /R repairs a corrupted disk more thoroughly/accurately/completely than a CHKDSK from Vista or XP.

    -Noel

    Saturday, October 29, 2011 10:46 PM
  • Here we are in May 2012, and chkdsk under Windows 7 (all updated and patched) is now using 29GB!!! of my 32GB to chkdsk/r a 1TB USB drive.
    Tuesday, May 15, 2012 8:37 PM
  • This is by design.

    BTW why do you _need_ to run chkdsk /r?

    Tuesday, May 15, 2012 8:51 PM
  • Yeah if you have a need to run chkdsk /r I would recommend running it in a system that is not doing anything else (remove the drive and use an enclosure with your laptop maybe?) or use a system running either Windows Vista or Windows 8 Consumer Preview (both of these OSes end up using a few orders of magnitude less memory for this function).  Scroll up in the thread to my post from October 2011 or to the first post of the thread if you want to see the results of my tests.

    Another good recommendation if neither of those options works was posted earlier by Adam, he advises you to start a Virtual Machine and allocate it a fair chunk of RAM, and once chkdsk has used up all the other available system memory if you close the VM chkdsk will not go after the memory that the VM previously occupied.



    • Edited by poisonsnak Thursday, May 24, 2012 9:57 PM fix wording of last paragraph
    Thursday, May 24, 2012 9:56 PM
  • This is by design.

    BTW why do you _need_ to run chkdsk /r?

    Trying to fix a friends HDD. It's a 1TB drive I have plugged into my cases external SATA dock taken from her laptop. My PC is i7 2600k @ 3.4Ghz and 16GB of RAM. I have to keep restarting the damn thing because it uses ALL available memory and it's getting warning messages that the system is out of RAM and to end the process. Nothing else is running, all programs are closed and no one was using the computer.

    Yes, this is clearly by design.

    No.

    And why does it matter why someone is running chkdsk /r? If someone is doing it, they obviously have a reason. The HDD I'm trying to recover has important data and it definitely has some dodgy sectors on it judging by frequent I/O errors when trying to transfer the data to my computer before trying a disk check.

    Monday, June 04, 2012 12:15 AM
  • And why does it matter why someone is running chkdsk /r? If someone is doing it, they obviously have a reason. The HDD I'm trying to recover has important data and it definitely has some dodgy sectors on it

    Sure, and this was a reason for building such chkdsk' behavior: to make such check as fast as possible. 
    Monday, June 04, 2012 6:03 AM
  • That is simply not logical. Sure, I could write a program to get something done very effectively by consuming 99% of system memory - my program would get stuff done fast, but to the detriment of the system as a whole. If it renders the Operating System incapable of responding to simple interrupts, what is the point?

    I run a "chkdsk /r" on an non-OS drive (E:) and step away to get some coffee. I come back to my machine which is now locked. So I attempt to log back in and the machine is unresponsive?

    With all due respect to everyone on this thread, there is no way around it - that is a bug. If it is not the system (typically "C:") drive, then it should not consume so much resources as to render the Operating System unresponsive.
    Saturday, June 09, 2012 4:10 AM

  • With all due respect to everyone on this thread, there is no way around it - that is a bug.
    This. Is. Not. A. Bug. Point. This is by design decision. Is it good or not, do you like it or not, such chkdsk behavior was created intentionally. So it cannot be a bug.
    Saturday, June 09, 2012 5:37 AM
  • http://en.wikipedia.org/wiki/Software_bug

    Whether it is intentional is irrelevant. A design flaw does not simply cease to be a flaw because it is intentional.

    Saturday, June 09, 2012 11:37 AM
  • Do you trust Wikipedia? Oh, my God, why???

    Look at http://en.wikipedia.org/wiki/Wikipedia:General_disclaimer please.

    Saturday, June 09, 2012 11:45 AM
  • There is no need to waste time. The developers very clearly stated this is by design behavior.

    Saturday, June 09, 2012 12:22 PM
  • Vegan Fanatic - Yes it does. On a Dell laptop running Windows 7 Professional x64 (i5 Processor, 8GB Memory) - it just keeps growing. Per my earlier post, I start a "chkdsk /r" and then go to sleep (it is going to take a while after all). The next morning, I cannot even log into my laptop - it is simply stuck on the Welcome screen with a spinning circle. Lights do not change on the laptop to denote when I disconnect external power or LAN - the only way to get the laptop to start responding again is to unplug the disk that I am performing "chkdsk" upon.

    I am attempting the same procedure again, this time on a Windows 7 Home x64 desktop (i7, 16GB memory), with monitor timeout and screen lock disabled - I hope that makes a difference. It's a clean desktop that I just built (it has 32GB memory, but Windows 7 Home will only use 16GB).

    But this is pretty crazy stuff. It seems inconceivable to me that the developers really want you to have to unplug the Disk you're chkdsk'ing, simply so the computer responds and you can see the progress of the chkdsk.

    Saturday, June 09, 2012 12:41 PM
  • It is not a "waste of time" if they end up re-thinking the behavior. I love Windows and have been using the various incarnations since Win3.1 - I am one of the group who normally wouldn't consider leaving Windows. But people on the fence or knowledge of numerous operating systems - most of them wouldn't put up too well with a System Diagnosis and Repair Utility which, by design or not (flaw or bug or whatever you want to call it), leaves the computer inaccessible.

    Saturday, June 09, 2012 12:49 PM
  • My laptop is issued to me by my Employer, and thus is pre-imaged by the IT Department (they wipe out the Dell installation with all of its bloatware). It does have a bunch of stuff on it like a Firewall, Anti-Virus and a whole-disk encryption suite.

    Saturday, June 09, 2012 12:57 PM
  • People in this thread really need to put aside their concerns about why CHKDSK uses a lot of memory, and instead work on the root cause(s) of why they are having to run CHKDSK to recover information.

    In all my years of running NTFS, going back to NT4.0 and comprising experience with lots of machines (sometimes whole engineering divisions of them), I have only had to run CHKDSK to fix bona fide file system problems a couple of times.

     

    If you are having to run CHKDSK regularly, something's wrong with your system, or with the way you do computing.

    The file system does not and should not normally become corrupted!

     

    Fix that, and stop wasting your time worrying about how much RAM the program to uses to try fix your file system problems after the fact!

     

    -Noel


    Detailed how-to in my eBooks:  

    Configure The Windows 7 "To Work" Options
    Configure The Windows 8 "To Work" Options



    Saturday, June 09, 2012 1:01 PM
  • Noel,

    chkdsk /f does not "eat" memory. Only chkdsk /r uses all available memory.  So you may make your nice words stronger.

    Saturday, June 09, 2012 1:20 PM
  • Noel,

    My brother dropped his laptop, and it crashed upon the tile floor. It won't boot up, he has exams this coming Monday evening, and I'm attempting to retrieve all of his previously-not-backed-up data (I know - in his defense I'm the computer guy, he's not). I took out his laptop HD, and connected it to my machine to run a "chkdsk /r" on it and see if I can recover anything....

    As Igor said, "chkdsk" is fine - "chkdsk /r" has an obvious memory leak (by design, it seems). I haven't had to use "chkdsk /r" in years, but now that I do - it is absolutely strangling my laptop.

    As Vegan Fanatic stated, it might be something with my laptop - I don't know. My employer's IT staff trusts me to write multi-million dollar software, but not to disable Firewall or even change the time of anti-virus scans. :-)

    I'm attempting to use an open source tool now on my desktop (which is a clean Windows 7 install) to retrieve the data. If that doesn't work, I'll try "chkdsk /r" on it and see if it consumes all the memory as well...
    Saturday, June 09, 2012 1:37 PM
  • Noel,

    chkdsk /f does not "eat" memory. Only chkdsk /r uses all available memory.  So you may make your nice words stronger.

    One would use CHKDSK /R (which implies /F) specifically to recover weak data from a spinning disk, right?

    So let us get this straight:

    1. Something - an application error message, or the OS via the log, or a CHKDSK run without switches, or something - has told the user that the file system is corrupted and/or the operating system is having trouble reading data from a hard drive.
    2. Then the user is running CHKDSK /R to try to have the system recover weak data and write it elsewhere on the disk.
    3. The user is complaining that they can't continue to use their computer while they're trying to recover weak sectors.

     

    Why would someone do this?  Why would anyone think they could just keep playing while something as basic as data recovery is taking place?

    • Are they too cheap to buy a new disk drive to replace a failing drive?
    • Are they too foolhardy to do backups so that their data is already safe?
    • Are they too naive to know that attempted data recovery from a failing hard drive is a serious, last ditch effort and may actually have to interrupt their fun?

     

    In every case here the root problem is not that CHKDSK is poorly programmed, it's that the user is making poor choices that take them to the point where they need CHKDSK.  So the solution is not software improvement, it's user education!  Or maybe different life choices that don't involve the use of a computer at all.

    -Noel


    Detailed how-to in my eBooks:  

    Configure The Windows 7 "To Work" Options
    Configure The Windows 8 "To Work" Options



    • Edited by Noel Carboni Saturday, June 09, 2012 1:45 PM formatting
    Saturday, June 09, 2012 1:43 PM
  • As Igor said, "chkdsk" is fine - "chkdsk /r" has an obvious memory leak

    No, I did not say these words, it is your and only your (wrong) interpretation. Chkdsk _uses_ this memory.


    Saturday, June 09, 2012 1:51 PM
  • Noel,

    Maybe they simply want to view the status of the "chkdsk /r" command. If your screen hibernates due to inactivity (you're not using the computer right), and you have "On resume, display logon screen" checked on your screen saver options, then you're out of luck. What do you suggest...just start the "chkdsk /r" command and wait a couple of days to see if it was successful?

    With all due respect, I disagree on your point:
    " So the solution is not software improvement, it'suser education!  Or maybe different life choices that don't involve the use of a computer at all."

    So the solution is to tell the user to quit using a computer and go back to paper?
    In our industry, it is incredibly easy to just blame the user. In the end, a simple change to a couple lines of code could alleviate the whole problem.

    Saturday, June 09, 2012 2:19 PM
  • Yeah, I use combinations of DropBox, Live Mesh and Crash Plan. *If* I can get my brother's data back, I will definitely be setting him up with automated backup.

    Saturday, June 09, 2012 2:21 PM
  •  My apologies Igor - I should have been clearer. I was agreeing with your statement that "chkdsk is fine".
    To your point, I personally have never had a problem running "chkdsk /f".
    The "/r" flag is the only place I encounter problems.
    Saturday, June 09, 2012 2:25 PM
  • So the solution is to tell the user to quit using a computer and go back to paper?
    In our industry, it is incredibly easy to just blame the user. In the end, a simple change to a couple lines of code could alleviate the whole problem.

    I doubt that you could program a CHKDSK replacement, and so your "couple lines of code" comment is just so much BS.

    It's clear that you're frustrated, but...  There are two entities who need to accept "blame" here, and neither is Microsoft, who has graciously provided you with tools to deal with the messes that you and your brother have created:

    1.  Your brother chose not to back up his system, then to handle it irresponsibly enough that it has hit the floor.  Now we learn the data potentially lost from it is valuable enough for you to spend time trying to recover.  Did you ever advise him to back his system up?  Do you plan to do so now?

    2.  You have the expectation that you should be able to recover data from a physically damaged electromechanical hard drive, and further that it should not intrude into the other stuff you want to do, and even further that it should complete quickly without use of many system resources.

    Wouldn't you agree that what would "alleviate this whole problem" is more responsible computer usage? 

    Consider yourself better educated because you now know that it actually CAN take your system to its knees to try to recover data from a bad hard drive.

    I'm curious:  Do you drive your car until the engine seizes and stops, rather than maintain the oil level and change it occasionally?  Then do you expect the car dealership to replace the engine under warranty, all without disrupting your day?

    And are you really trying to blame Microsoft because YOU have your system configured to go to sleep on lack of user input, in the very same thread where you describe yourself as "the computer guy"?

    I'm really not being critical of you - life is one long learning experience - but I *AM* being critical of coming on here and trying to blame anyone but your brother and yourself for the mess you're dealing with.  Take responsibility for your mistakes instead of trying to pretend you haven't made them.

       

    -Noel


    Detailed how-to in my eBooks:  

    Configure The Windows 7 "To Work" Options
    Configure The Windows 8 "To Work" Options



    • Edited by Noel Carboni Saturday, June 09, 2012 3:36 PM typo
    Saturday, June 09, 2012 3:32 PM
  •  My apologies Igor - I should have been clearer. I was agreeing with your statement that "chkdsk is fine".
    To your point, I personally have never had a problem running "chkdsk /f".
    The "/r" flag is the only place I encounter problems.

    Thanks for apologies. Once more - there is no leak in chkdsk/r, it uses all the memory allocated. Sorry for repeating, but chkdsk /r is not normal working procedure. It is for repairing disk to diagnose or avoid problems with possible data loss. This is most important work at this moment and should not be slowered by any other task. 

    Imaging, you go into hospital for a check-up and says, hey, make your investigationgs but do not put obstacles in my work. Isn't it senceless? 


    Saturday, June 09, 2012 4:46 PM
  • Noel, Concerning your statement:

    ----------------------------

    If you are having to run CHKDSK regularly, something's wrong with your system, or with the way you do computing.

    The file system does not and should not normally become corrupted!

    ---------------------------

    In my case, I run chkdsk/r quite frequently because I am an IT consultant (since 1985).  I regularly take out hard drives from client systems, and attach it to an external USB or eSata box, and attach it to a known working system. Then I can run "out of band" antivirus and chkdsk types of analysis and repair. Recently, on a 3TB drive (that ultimatly chkdsked perfectly clean), it took about 9 hours to complete the chkdsk/r. Frankly, I wouldn't have minded if the check took 24 hours, but I (and my client) DID mind that the otherwise useful quad-core 10GB workstation, was incapacitated beyond usefulness during this period.

    This 3TB disk only had about 300 data files on it, and was less than 10% full. checking at a rate of about 20k clusters/sec over esata.

    If it is grabbing this memory for the allocation tables, it should release it BEFORE stage 5 (free space scanning).

    It may be design... but it looks, acts, feels, tastes, smells, like an arrogant designer flaw. And it's obvious many of us have stepped in this poop.

    However, i'm willing to negotiate. Make it default, but give me a flag to specify maximum memory allocation. Thank you for your consideration. rich

    Monday, June 11, 2012 10:48 PM
  • In your case something's wrong with the systems of the people you do your work for.  That still doesn't make it a generally common activity, and my comment does apply to them.  And I'm not clear on what it is you feel you gain for them by using the /R switch.  Did you need to use /R or is it just something you do just as a matter of course?

    In my opinion a drive requiring CHKDSK /R is on its way out and needs to be replaced.  Do you deal with many such drives?

    One could point out that if you DO do this work regularly, then you might want to consider having a separate system that's not useful for much else to do the work, instead of tying up your rompin' stompin' quad-core 10GB workstation all day.

    I can imagine the CHKDSK /R module reading the same block of sectors over and over a bunch of times, then comparing the block in RAM to make sure the sectors all read successfully every time.  Disks read most rapidly and efficiently when contiguous sectors are read.  Why it wouldn't release the RAM when entering a new phase I don't know - perhaps you're right about it being a poor design or implementation.

    I haven't checked to see if CHKDSK /R works the same in Windows 8.  Since Microsoft doesn't seem to have done too much to the core functionality of Windows 7 to make Windows 8, I'd guess that it does, but if it doesn't it sure would answer the question here about whether it's a bug.

    -Noel


    Detailed how-to in my eBooks:  

    Configure The Windows 7 "To Work" Options
    Configure The Windows 8 "To Work" Options


    Monday, June 11, 2012 11:36 PM
  • No they shouldnt. Chkdsk is a utility and as such it should be USEABLE.

     To design an effectively UNUSEABLE utilility is just had design. Its a question of semantics to say its not a bug or to ask why some one needs to run it. There are millions of windows users out there and a GROWING number of people using external drives for media. These drives now are at 1 TB at a minimum, and are often 2 TB and nowadays can be 4 TB in size.

    They are plugged into media players and all sorts of devices and have kids pulling them out when being used etc

     ITS NOT UNREASONABLE that occasonally they need a chkdsk run - and then for the household PC to be unuseable for a whole day is just appalling design.

    Now Ive just upgraded from a LINUX PC to to windows 7 PC -with 16 GB of RAM and I and running this on a friends External HDD.  and I see this problem.

         Its enough to make me seriously think about ditching windows and going back to linux to be honest - because its such APPALLING lack if user friendliness.  Windows is NOT FOR GEEKS its for  all users......  and to say you havent need to run it often is just saying YOU KNOW WHAT YOU ARE DOING - but doesnt mean familiies with Kids do....Now if I decide to stick with windows - I can use the VM solution to reserve memory  OR I can  set up a machine  to do this work on when I need to - I have spare copies of Vista, XP, and 64 BIT XP and PCs so thats no issue for a Geek. BUT IT IS FOR YOUR AVERAGE USER......    and ANY PROFESSIONAL should be thinking about good design and not trying to excuse bad design that locks up an entire PC for an entire day when its not needed... (and yes - doing the boot disk - thats probably needed - but for an external HDD - thats ridiculous).

    THIS NEEDS TO BE FIXED NOT sidestepped/

    Wednesday, June 20, 2012 1:23 PM
  •  ITS NOT UNREASONABLE that occasonally they need a chkdsk run - and then for the household PC to be unuseable for a whole day

    In most cases chkdsk finishes after a few minutes or less then a one minute.
    Wednesday, June 20, 2012 6:56 PM
  • ITS NOT UNREASONABLE that occasonally they need a chkdsk run - and then for the household PC to be unuseable for a whole day is just appalling design.

    You're confusing two things.

    As Igor has said, just running CHKDSK or CHKDSK /F on an external hard drive takes a minute.  I just did my external MyBook 2 TB drive in 59 seconds.

    The /R switch is a VERY SPECIFIC setting that tells the system to read the sectors and if any are weak attempt to recover the information and remap the data to another part of the drive.

    /R should not be needed except under rare circumstances with a failing drive, and could be a last ditch effort to recover data that's otherwise going to be lost.

    If you're having to do CHKDSK /R regularly on the same machine you need to really consider getting better hardware.

     

    Its enough to make me seriously think about ditching windows and going back to linux to be honest

    You don't have a whole lot to worry about, do you?  :)

    -Noel


    Detailed how-to in my eBooks:  

    Configure The Windows 7 "To Work" Options
    Configure The Windows 8 "To Work" Options

    Wednesday, June 20, 2012 11:18 PM
  • Noel, Concerning your statement:

    ----------------------------

    If you are having to run CHKDSK regularly, something's wrong with your system, or with the way you do computing.

    The file system does not and should not normally become corrupted!

    ---------------------------

    In my case, I run chkdsk/r quite frequently because I am an IT consultant (since 1985).  I regularly take out hard drives from client systems, and attach it to an external USB or eSata box, and attach it to a known working system. Then I can run "out of band" antivirus and chkdsk types of analysis and repair. Recently, on a 3TB drive (that ultimatly chkdsked perfectly clean), it took about 9 hours to complete the chkdsk/r. Frankly, I wouldn't have minded if the check took 24 hours, but I (and my client) DID mind that the otherwise useful quad-core 10GB workstation, was incapacitated beyond usefulness during this period.

    This 3TB disk only had about 300 data files on it, and was less than 10% full. checking at a rate of about 20k clusters/sec over esata.

    If it is grabbing this memory for the allocation tables, it should release it BEFORE stage 5 (free space scanning).

    It may be design... but it looks, acts, feels, tastes, smells, like an arrogant designer flaw. And it's obvious many of us have stepped in this poop.

    However, i'm willing to negotiate. Make it default, but give me a flag to specify maximum memory allocation. Thank you for your consideration. rich

    This thread really saddened me. It is filled with with so many opinionated people, which on any other forum would be classified as trolls and given suspensions or banned. People like Noel and Igor have only aggravated others that are suffering from this bug.

    Yes, I say bug - allow me to provide my reasoning.

    1) Windows is all about multitasking. This memory consuming design goes directly against everything Microsoft has aimed to achieve over the last few decades.

    That's really the only important point. Only the bootable form of the tool should consume all memory. System drives should be forced to run the bootable form, but external/USB/eSATA drives should be properly detected and be checked without causing all these problems reported in this thread.

    To expand upon that point...

    2) Tools like SATA docks are extremely common now. As an IT tech I probably scan at least a half dozen drives per week. There's hundreds of thousands of other people doing the same thing... maybe millions. This is not a fringe usage scenario.

    3) It's not uncommon to see one machine scanning 30 or 40 drives (rackmount, etc.) after an unexpected power failure at big companies/datacenters. Those drives run linux filesystems. Incapacitating one computer to check one drive at a time is extremely silly. Even if it makes it twice as fast, you lose out on having zero parallelization.

    Those are really the main reasons. Now, let me tell you an interesting story from yesterday.

    Normally chkdsk has worked fine for me, but yesterday I encountered this bug - I received a drive that could not be cloned with Windows tools, and could not successfully be chkdsk'd (unless I fire up a Vista/XP DVD) - both chkdsk /f and chkdsk /r fail under Win7, by consuming 99% of memory and causing everything to crash. (Backup software, background programs, then chkdsk itself locks up and stops doing anything.)

    This is a fringe case for sure, but it's caused by a bug - a design defect - something that would cause me to fire a coder if they made such a silly backwards assumption.

    Now for the details - *drumroll* - the drive that I'm checking is approximately 60GB large (80GB PATA drive with one main partition and one small recovery partition), and appears to have 18.2 million file records. (YEAH - fringe case) It completely incapacitates the Win7 chkdsk, but not the Vista or WinXP chkdsk. (Which, btw, check it over far faster. I suspect the simpler less memory hungry algorithm is faster than cannibalizing as much pagefile as it can get...) chkdsk /f takes many hours to run, and chkdsk /r did not complete overnight, but was finished by the end of today. I first got the idea to check over this drive when I heard it clacking away constantly for seconds for every single task. (Clicking a shortcut, clicking the start menu, etc.) I fired up Defraggler and noted 100% of the squares in the graphic were yellow. Despite that 70% of the drive is empty. Something has seriously gone wrong with NTFS on the main partition.


    Anyway, like I said, I'd fire the coder that made such an assumption if he refused to learn and correct it. Logic holes like this are exactly the kind of thing that create holes/exploits for viruses - although in this case it's a performance bug rather than security bug. Regardless, it's sloppy coding that didn't plan for fringe use cases (< 1%), and thus fails completely when encountering them. Proper behaviour (IMO) would be to heavily encourage rebooting to check a drive in the GUI CheckDisk, but allowing the cmdline chkdsk to run properly in Windows for non-system drives without devouring all available memory.

    • Proposed as answer by Kramy Thursday, November 29, 2012 9:41 AM
    Thursday, November 29, 2012 9:41 AM
  • 1) Windows is all about multitasking

    Oops.  I guess you aren't yet aware of the "immersive" new experiences of Windows 8.  Things are going in a direction that doesn't seem to make sense to we Windows users of the past.  Windows is moving away from multitasking.

    While I don't disagree with you that there could be a bug, think about what you're saying...  Why are you running CHKDSK in these scenarios with the repair switches?

    Your file system is corrupted; your disk is failing...  And you want to do other things while you diagnose and attempt to repair it?  What would those be?  Playing games?!?  Try to think logically here...  If you're having to run CHKDSK /R or CHKDSK /F you really don't want to be trying to multitask doing something else.  That's tantamount to wanting to continue to drive your car while a mechanic is underneath working on it.

    Yes, I understand the concept of checking multiple non-system disks simultaneously.  Are you sure you can't do this?

    That said, I am no more an advocate of software that fails than anyone else.  Clearly, like you, I'd rather have seen Windows 7's CHKDSK fix the problem for you.  You'll have to take that up with Microsoft; clearly they haven't chosen to fix it in all the time since this thread was started.

    I wonder if any changes have been made in the Windows 8 CHKDSK application.

     

    -Noel


    Detailed how-to in my eBooks:  

    Configure The Windows 7 "To Work" Options
    Configure The Windows 8 "To Work" Options

    • Edited by Noel Carboni Thursday, November 29, 2012 5:27 PM
    Thursday, November 29, 2012 5:23 PM
  • FYI, I happen to have a 1TB data drive in my system that has quite a few files on it (not in the millions, though).  I ran CHKDSK on it as a test.

    --

    CHKDSK /F did not use a noticeable amount of memory, and completed in a minute or so (without having to make any repairs).

    I suggest that a problem seen with CHKDSK /F on a volume with millions of files is completely separate from the issue being discussed in this thread.

    --

    CHKDSK /R DID use a lot of memory, showing this display in the CMD window at this point:

     

    CHKDSK is verifying file data (stage 4 of 5)...
    31 percent complete. (64 of 488944 files processed)

     

    Seems odd it would stop there, but I suspect the readout may be a misnomer.  At some point CHKDSK /R actually has to try to read every single sector from the disk, and that appears to be what it's doing.

    At this point it was reading data from the disk at 110 megabytes/second - apparently a big sequential read into RAM from \Device\HarddiskVolume5.

    Memory usage climbed steadily up to where only about 2GB was free (46.3GB used of 48GB) then leveled off.  At that point Resource Monitor showed the read speed drop to 83 megabytes/second, but after a while it climbed back up into the 120 MB/second range again without seeing the memory usage go up any further.

    I'll follow up with another post when CHKDSK /R finishes.

    --

    I suspect what the application is doing is a huge sequential disk read operation to see whether any sectors will throw an error, but that's just a guess.  Sequential Read operations are MUCH faster than smaller reads, and with the size of this operation it can use all the speed it can get.

      

    But what's important is this:

     

    At no point did my system become unresponsive or unable to run additional programs.  I was typing this, I started Resource Monitor and a number of other applications while CHKDSK continued.  Thus any comments about this "destroying the ability to multitask" are overly extreme.

     

    Perhaps Microsoft opted to maximize the rate at which it could check an individual disk via CHKDSK /R by allocating the maximum amount of available system RAM so as to do huge sequential reads.

    Would it have been nice for Microsoft to offer a choice for you to limit RAM usage?  Maybe, but they didn't.

    Where's the bug here?  If you want to call that a design bug - fine.  It's apparently not an implementation bug.

     

    In summary, I suspect that these things are a factor in this discussion:

       

    • Some folks don't realize that to actually read a terabyte of data even once to thoroughly check a hard disk, even at 100 megabytes/second it takes a significant amount of time!  Do the math:  1,000,000,000,000 bytes / 100,000,000 bytes/second == 10,000 seconds (nearly 3 hours).  Imagine how much longer it would take if it were only reading at a fraction of that speed into smaller blocks of RAM.
         
    • Some systems aren't up to the task of doing max-rate disk I/O and using of all of the system RAM for hours on end, and may see instability or crashes because of it.  Heat builds up and this stresses things that don't normally see that much stress.

       

    My advice remains:  Expect that RAM will be used and don't plan to do much else with your computer for some hours if you're going to do CHKDSK /R.

     

    -Noel


    Detailed how-to in my eBooks:  

    Configure The Windows 7 "To Work" Options
    Configure The Windows 8 "To Work" Options




    • Edited by Noel Carboni Thursday, November 29, 2012 6:21 PM typo
    Thursday, November 29, 2012 6:11 PM
  • I just noticed that my CHKDSK /R had finished at some point (no errors were found).  I forgot that it was running in the minimized CMD window, actually, while I did other work this afternoon.

    This experience kind of runs against the "OMG CHKDSK is an epic fail" sentiment that's being expressed throughout this thread, and supports my two-part conclusion above.

     

    -Noel


    Detailed how-to in my eBooks:  

    Configure The Windows 7 "To Work" Options
    Configure The Windows 8 "To Work" Options

    Thursday, November 29, 2012 9:16 PM
  • CHKDSK /R uses all memory:  this is definitely a BUG "by design": it eats all mem no matter how much memory you have (4, 8, 16) and...

    windows8 CHKDSK /R does not have this BUG!!! so please FIX windows 7 chkdsk as soon as possible. Thanks.

    Thursday, May 16, 2013 9:54 PM
  • I just noticed that my CHKDSK /R had finished at some point (no errors were found).  I forgot that it was running in the minimized CMD window, actually, while I did other work this afternoon.

    This experience kind of runs against the "OMG CHKDSK is an epic fail" sentiment that's being expressed throughout this thread, and supports my two-part conclusion above.




    Then you are lucky and I only wish I could say the same. You seem to misunderstood the nature of the problem the people in this thread have. It is not that we are complaining JUST about chkdsk /r allocating all RAM - this would be acceptable glitch IF IT EVER COMPLETED THE JOB. But gues what? It DOES NOT. After chkdsk eats all RAM, windows starts killing running apps INCLUDING chkdsk.

    As for the ehm... lets just say "irrelevant" questions like why would anybody run chkdsk /r - here is my reason: I wanted to mark bad sectors on a friend's failing disk because the backup tool I wanted to use fails to copy the partition if it has undiscovered bad sectors.

    There is no question this is a bug, because chkdsk /r simply fails to do its job, at least in my case. Maybe your chkdsk behaves somehow better and does not get killed by the OS, but in numerous cases it obviously fails miserably.

    As already noted, it was fixed on Windows 8, so please stop prettending that this is an intented behavior. There is no reason for a disk tool to allocate RAM like crazy, it can't provide any speedup for sequentional reading throughout the entire partition and it indeed does not.

    Sunday, July 14, 2013 5:52 PM
  • As already noted, it was fixed on Windows 8, so please stop prettending

    You're responding to a post from November 2012, just at the time of the Windows 8 release to the public, and you're asking "please stop"?

    The context of the discussion was re: Windows SEVEN.

    It may well be that Microsoft changed the design of CHKDSK for Windows 8.  Certainly they've been doing things to increase file system robustness (or at least saying that they have been).  It may well have been a "design bug" in Windows 7 to assume they could use all the RAM, but that doesn't change the behavior from being "as designed" for Windows 7.  It may be that they read this thread and realized they didn't anticipate people wanting their system resources for other work when doing restorative activity like CHKDSK /R.

    If you're seeing CHKDSK uncovering problems in your Windows 7 setup, it's entirely possible you don't have a fully stable computer system.  They're not all created equal.  Do you have high reliability parts?  There's a reason professional quality computers cost more than consumer systems.

     

    -Noel


    Detailed how-to in my eBooks:  

    Configure The Windows 7 "To Work" Options
    Configure The Windows 8 "To Work" Options


    • Edited by Noel Carboni Tuesday, July 16, 2013 1:37 AM Clarified wording
    Monday, July 15, 2013 4:17 PM
  • So basically, fix this shit you fucking MS assholes, we have enough with end user limitations already, fix one.
    Saturday, July 27, 2013 5:39 AM
  • I "FIX" the issue using procgov.exe to limit the memory the process can use

    https://diagnettoolkit.codeplex.com/releases

    my cmd line: procgov.exe -m 512M chkdsk.exe /r /x X:

    Regards.
    Tuesday, April 29, 2014 2:30 PM
  • Francisco Tesla  OUR SAVIOUR!!!! :) but sadly your
    herculean effort hasn't been readily spread over the web where this non-sequitor
    gets questioned regularly ( yes the notoriously unfeasible Igor + Noel of this
    thread  are the most humanly possible inept at logic + thinking, and likely
    ignorant of relevant knowledge going by the sheer misery of reading
    their INCESSANT(Obsessional?) GARBAGE posts EITHER that or they must be shilling
    for crApple with the amount of manipulative twisted deceitful,
    nefarious propaganda/hyperbole that they SPEW forth with.
    So Igor + Noel WANT a REASON WHY we might use chkdsk /r
    frequently? :o :o :o GOD even M$ aren't that conceited that they think they can control our
    personal choice  (they might have been expectant(DELUSIONAL?)but ended up with
    disappointment(what we all knew that  EOL   doesn't stop you using an OS
    practically these days even one as big a target as XP) of the huge migration
    from XP EOL to 8!!!! Talk about ad hominem  attacks, just
    because Igor + Noel's understanding is too poor/their conceit too great? to
    imagine reasons why many people might use chdsk /r frequently.
    Having  errors that require chkdsk /f however are
    part of regular/heavy use of an OS  however chkdsk /f  cannot provide ANY
    indication of disks health in respect to data loss, it is of course not the only
    tool to detect this (eg S.M.A.R.T disks) considering that disks can die any
    time with little to no warning any + all help is paramount, that the ease of a regular chkdsk/r is at least
    an additional tool for data protection via hardware integrity loss that of course
    does  replace regular back ups, never the less, getting data of a dying but
    still usable disk might be much quicker/more convenient than retrieval from the
    a back up.
    Additionally being paranoid if I have /f fixable
    errors naturally i want to be sure that its not the disk's integrity/hardware
    that caused them so i run the full /r because i have to run the /f steps first
    regardless of /f or /r  ie stages 4 + 5 can't be run separately it would mean
    repeating the /f results so might as well not waste that /f time + do the full
    /r (thankfully only the separated from OS's (as with docs/media SSD speed is
    redundant), data drive on the spinners takes  such a time i would need to use my
    back up for any data i wanted)

    PS Francisco from my understanding the /x switch is
    redundant with the the /f or /r switches,  for any drive accept the current OS
    they will ask you if they can first  dismount the drive(what the /x function) ie
    it wont be accessible BEFORE it can check the
    disk?

    **Anyway that's beside the point/being pedantic,  procgov.exe  works great but I've been using 7 for a couple of years now + only now have i noticed  this non-sequitor because  7 needed to warn how low Ram was + to start executing unnecessary software, so i instantly looked at taskmngr for the culprit - it couldn't have been any program I was running - IE9 !  I'm actively booting with another 2 XP partitions, 7 takes EXACTLY the same amount of time to chdsk/r  with all the GB of ram being HOGGED as the XP drives (even booting into the 7 rescue/repair disk , chkdsk/r uses is the same pre + post 7 windows microscopic memory use levels ??????) BY 'DESIGN' indeed, ROTFL, then what a pointless design that they've even corrected on 8 LOL, and COMPLETELY contradicting all the INANE bollocks that Igor(HOW THE HELL is he an MVP????) more like MPR/Mbollockser + Noel) have spouted on this thread. :( 





    • Edited by Al79 Wednesday, August 20, 2014 10:40 AM crap written language(yes it was EVEN worse then it is now :D)
    Wednesday, August 20, 2014 10:35 AM
  • Thanks for trying robotsrock but the hotfix may have fixed your similar problem but not the non-sequitor this thrd is based on;

     chkdsk /r using nearly the max memory you have (potentially to effect the use of of every activity you use the PC during the disk checking time from lack of available spare RAM (chkdsk/r must be one if not THE BIGGEST RESOURCE HOG in history) but M$ think we should just forget about it - as their paid cronies Igor + Noel show by  DESPERATELY encouraging us to believe with their starling,  dearth of logic/knowledge) whether its 500MB or 16GB plus ( one of the many reasons with such ASTRONOMIC diversion in RAM use, with out ANY diff in resulting function that makes NO LOGICAL SENSE UNLESS IT IS A BLATANT M$ MISTAKE to DO EXACTLY the SAME JOB IN EXACTLY the SAME TIME, as my multi win generation PC  tests show conclusively on Win OS both before 7 from XP,7  and AFTERWARDS (LMAO!) 7.

    .

    .

    ***MISTAKE - i originally mentioned that the MS 7 rescue/repair disk wasn't affected by the usual 7 memory leak BUT I made a mistake, IT WAS, i just double checked the off line boot disk now and its exactly the same situation,reaching 1 GB+++ (with only having 2GB total)very quickly, given that the boot "disk's" WIM image is based on 7's file system it would make sense, its only 'off line' wrt the other (inactive) OSs on drives as opposed to Optical disk/USB drive being used(ironically I boot mine (the .iso file) of an ssd (but booted from software on the USB drive) for speed - if the SSD totally died then i have a regularly ('non-live') 'mirrored' back up OSs SSD but even w/o that then I have tools with comparable functions 'OFF SITE') its still a "bare bones"  CMD  based set up but active (but you can execute some GUI utilities -especially if use add suitable ones with WIM manipulation tools, imageX  gimageX) Thus I except theoretically though not of practical use when chkdsk/r works on 7 boot, the memory HOG use is the same. I'm sure i have a copy of the comparable MS  Vista rescue/repair somewhere, i expect it will perform like Vista (no chdsk /r memory leak but if it doesnt I'll add it here).






    • Edited by Al79 Wednesday, August 20, 2014 12:55 PM
    Wednesday, August 20, 2014 11:01 AM
  • Yeah i was looking for this post when i replied to your hotfix post as you mention about the memory, that has everything to do with the threads point/enigma + exceptional(?)  age/wont die as much as M$ would prefer it to.

    Its seems M$ have a binding legal agreement (from crApple naturally - at least with 8 M$ evolved + took risks, AND some of the tech innovations  security etc developments I still appreciate even though not the OS itself but i wasn't M$ intended target audience + they did give me Xp but even more unfeasibley they repeated their achievement with 7) - compare to the parallel HORROR of the evolutionary backward "a touch screen, what's that?" :D Mac OS were Apple dumped them long ago but they are far too ignorant/gormless about "PC"s to know to their plight - that Dinosaurs have come back from extinction for Mac users :D :D ) or else Mac OS would be 'extinct' as a <strike thru>PC</strike thru> Mac platform by now ).

    It looks like originally with 7,  that M$ was going to get its legal arse seriously sued thus the introduction of this exquisite logic waving  chkdsk/r RAM hog for it customer's to suffer :(. I imagine the 'unfixable' ,similarly wont go to bed, 7 hibernation "issue" was introduced for the same reason - O/T of all the 'fixes' on the web for this, none fix my hibernated for 2 years then stopped but luckily i found my own fix -replacing the current grldr (grub4dos  multi OS/switches boot utility) MBR with the original  7/vista MBR whoopie!







    • Edited by Al79 Wednesday, August 20, 2014 12:08 PM
    Wednesday, August 20, 2014 12:04 PM
  • everybody, lets stop piling into this thread and make some new ones

    each person has discrete and unique issues, so get as much information into your post so that somebody can figure it out better


    Corsair Carbide 300R with TX850V2
    Asus M5A99FX PRO R2.0 CFX/SLI
    AMD Phenom II 965 C3 Black Edition @ 4.0 GHz
    G.SKILL RipjawsX DDR3-2133 8 GB
    EVGA GTX 660 Ti FTW Signature 2 (GK104 Kepler)
    Asus PA238QR IPS LED HDMI DP 1080p
    ST2000DM001 & Windows 8.1 Professional x64
    Microsoft Wireless Desktop 2000 & Wacom Bamboo CHT470M

    Place your rig specifics into your signature like I have, makes it 100x easier to understand!

    Hardcore Games Legendary is the Only Way to Play!

    Wednesday, August 20, 2014 12:36 PM
  • 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.

    To take this out of context , users aren't expected to want to reboot to do a chkdsk as the OS is unavailable to multi-task with. Thus i dont think there is a switch you can use to make it run at boot time however running   chkdsk on the OS drive you are currently running (the "active"  or 'system' drive in MS booting terms) will result in chdsk being performed at the next reboot..

    The chkdsk /r is the switch for checking bad sectors it does run at boot time,but so does the chdsk /f switch for.the 'normal' file system check too.(by performing on your current drive)

    Wednesday, August 20, 2014 3:29 PM
  • NB

    Jun 9 2012 Quote; Azazel123

    "As Vegan Fanatic stated,"

    + many posts of that time on this thrd include "@Vegan Fanatic". Considering your recent post is the only one on the thread now, your initial one(s) were deleted , interesting that you have made such a dodgy comment now, will your current post have the same fate as your previous post(s) on this thrd and share the reason for that fate?

    Quote; Vegan Fanatic

    ("everybody, lets stop piling into this thread and make some new ones")

    First comment/paragraph on this part of replied post below;

    "each person has discrete and unique issues, so get as much information into your post so that somebody can figure it out better"


    Err, aren't you supposed TO READ the thread before posting :(. The point is, in this thread we share the same discrete + unique issue, if you cant understand that then i can struggle to come up with only 2 possibles; your on M$ pay/ your mind doesn't function in a logical capacity or least least what the majority of understand as "logical"..Are you on recreational DRUGS/ILL etc (this from someone who has been diagnosed with excessive thinking - not that means any of it is quality unfortunately but perhaps by volume i have a greater random chance of understanding something then average :D????) OH your an AMD fanboy ;) say no more - a "when did AMD pcrs become equivalent to Intel's everywhere except the ALL IMPORTANT*, *HA! HA! HA! theoretical benchmark" wont exist in your delusion

    MVP????? More like like on their PR payroll with such preposterous post against common sense - if there's a problem which continues + the manufacturers pay no attention in their own forum despite with the continuation of time users are continually bothered by the SAME problem + its complete lack of logic... THEN your suggestion is to make separate threads about it ??? WTF???Talk about UNATURAL! Aren't people joining this Ancient thrd with the same maximally combined sentiment that's inspired them to post? Aren't they wanting the thrd to be as big and have  the best chance of being noticed,troubling someone for a solution in case of BAD PR etc. Contrast to yourself against freedom of speech/choice + wanting us to make many small threads less noticeable???Aren't you being too obvious at your M$ lackey manipulative hyperbole/deceit/nefariousness? You remind me of when Apple released the bastardized beta tester of all time, the <whispers> iPhone3G that had EVERYTHING wrong with it from the case to its complete + utter inability to keep in contact with another phone. What do apple decide is the best response in their own forum to cope with the MASS suffering + MASSIVE THREADS of such a rip off disaster? Keep quiet, ask people not to post in the same huge thread for moderation sake, + delete (critical) posts en masse to make such huge thread more manageable.YES that's "our" CrApple "morality" Will Vegan be clueless about REALITY as crApple,  and enjoy deleting posts questioning their sanity (my sanity isn't in question, I'm NOT)

    What exactly crawled up your arse + died , exactly + made you GOD of this forum. Do you not comprehend the meaning of freedom of thought, expression, + choice.This thread is about 1 TOPIC only , M$ have neither responded or explained this complete non sequitor despite the age of this problem +  using google blatantly shows  how popular/an unsolved problem this specific non-sequitor is.. "MORE THRDS" you say?????? ARRRRGH!!! - its no fun when you cant use your PC from lack of RAM because a utility that on EVERY SINGLE WIN OS APART from 7, uses over ten's of mb to complete the same task, with same efficiency + same speed ( on identical hardware). You sound like you are criticizing people choice and haven't even read WHAT they are complaining about , yes there are worse things but given "bareback forums" exists there can be no less deserving a topic to discuss in a public form.

     

     

     







    • Edited by Al79 Wednesday, August 20, 2014 3:51 PM
    Wednesday, August 20, 2014 3:41 PM
  • Well...I've got this problem too. I've read all the comments here, especially the things by Noel and I'll have to disagree with him. I've just assembled my PC again after a while of not having it around. My specifications are:

    Processor - Intel Core i7-3960X @ 3.3 GHz

    Motherboard - ASUS Sabertooth X79

    GPU - ATI Radeon HD 7950

    RAM - 12 GB

    2 Western Digital HDDs of 1TB each clocking at 7200 RPM

    Now...I don't run many programs on my PC, just BitTorrent, Skype and a few others. I have a PageFile on another partition than the one Windows is on. I have 2 partitions (C and D) on the primary HDD and 3 more on the other HDD. I run ChkDsk regularly with the '/r' switch and I do not find running 'chkdsk /r' as abnormal.

    Agreed, file-systems don't get corrupted very often, but I prefer to run it regularly to prevent problems, since I have a lot of data movement and power fluctuations...anyways, WHY I run it doesn't matter...I mean...unless I'm running ChkDsk 10 times a day, why the hell does it even matter WHY I'm running it? It's pretty OBVIOUS to run it because one thinks there's errors on the disk, or just to know that the disk is clean.

    Now...the thing is, if I want to check drive D: and have a game installed on drive C:...if I want to play the game, why the hell do I have to wait for the checking to complete? I mean, I agree...if I had to use the D: drive, then it was fine...I'd rather let the disk check and do my work later...but what the problem is when I want to use the rest of the system? What then? Do I have to just sit around and get bored while the system locks things up for me and doesn't let me use what I want to? Why shouldn't I be able to use things other than the ones on the affected partition?

    I do not know if this is a design flaw or a big...but this is DEFINITELY not agreeable. I'd rather have a disk check which completes in 10 hours and lets me do my job than have one which takes 3 hours and bores me when I have nothing else to do. And it's not even that I'm trying to use the drive being checked...I never do that, but what about the rest of the system? Why can't I use the other drives and things while the check is being performed on one drive?

    Really, Noel...I know, you people are much more qualified and know a lot more than me...but THIS...is literal nonsense...

    13 hours 3 minutes ago