none
Having a problem with Excessive "modified" memory usage in Win7 x64, upwards of 3.6GB, any suggestions?

Answers

  • Modified memory is memory that was allocated by some application and then removed from the application's working set, usually because it hasn't been used for a long time. The fact that most of your memory is in this state means two things:

    1. Some app (or multiple apps) allocated a lot of memory, and is not actively using most of it. Often (but not always) this is due to a memory leak in the app.
    2. The pagefile is not large enough for the system to move all this unused memory to disk.

    If you sort the processes by Commit Size do you see any particularly big ones? If yes, do you expect them to be using that much memory?

    Also, have you disabled or reduced the default pagefile size? If yes, you can set it back to "system managed" and that will allow the system to recover physical memory by moving unused pages to the pagefile. (However, if it does turn out to be a memory leak then the pagefile will eventually become full anyway, so you'll need to close the leaking app, or if it's a driver leak, reboot the system).

    Wednesday, February 03, 2010 9:16 AM
  • Matthew,

    The only reason why these pages are kept on the modified list indefinitely is because the system doesn't have any available pagefile space left. If you increase the size of the pagefile the system will write most of these pages to disk and then move them from the modified list to the standby list. Standby pages are considered part of "available memory", because they can be reused for some other purpose if necessary.

    Whether this would "fix" the problem or not depends on what the actual problem is. If it's an unbound memory leak then increasing the size of the pagefile will simply allow the system to run longer before it eventually hits the maximum pagefile size limit, or runs out of disk space. On the other hand, if it's a case of some application allocating a lot of memory and not using it for a long time, then increasing the pagefile might be a perfectly valid solution.

    Allowing the system to manage the size of the pagefile actually works well in most cases. Pagefile fragmentation (at the filesystem level) can only occur when the initially chosen size is not large enough and the system has to extend it at run time. For win7 we have telemetry data that shows that even for systems with 1 GB of RAM, less than 0.1% of all boot sessions end up having to extend the pagefile, and this number is even lower for larger amounts of RAM. If you think you are in that 0.1% and your pagefile might be getting fragmented, you can manually increase its minimum size such that the total system commit charge stays below 80% even if you run all your apps at once (80% is the threshold at which the pagefile is automatically extended). This will make sure the pagefile is created once and then stays at the same size forever, so it can't fragment. The maximum size can either be set to the same value as the minimum, or you can make it larger so that the system is more resilient to memory leaks or unexpectedly high loads.

    By the way, Windows doesn't use pagefiles as "extra memory", it uses them as a backing store for private pages, just like regular files are used as a backing store for EXEs/DLLs and memory mapped files. So if the system really has more than enough RAM (like in your second screenshot, where you have 3.6 GB of free pages) you shouldn't see any reads from the pagefile. You can verify this by going to the Disk tab in the resource monitor and looking for any disk IO from pagefile.sys. On smaller systems that don't have an excess of free pages you may see periodic reads from the pagefile, and this is expected because the total amount of data referenced by the OS/drivers/processes is larger than the total RAM. Forcefully keeping all pagefile-backed pages in memory (which is what disabling the pagefile does) would simply mean some other pages (memory mapped files, DLL code or data etc) would have to be paged out.

    Regarding further troubleshooting steps: If the system runs fine with a larger pagefile (commit charge stabilizes well below 80%, and you no longer see gigabytes of modified pages accumulating in memory) then you don't really need to do anything. If the problem persists, you can check for any processes with an abnormally high commit charge, and also check kernel memory usage in task manager. If it's a kernel leak you can usually narrow it down to a particular driver using poolmon.exe or kernel debugger.

    • Marked as answer by Matthew Buddha Wednesday, February 10, 2010 2:09 PM
    Wednesday, February 10, 2010 7:59 AM

All replies

  • Modified memory is memory that was allocated by some application and then removed from the application's working set, usually because it hasn't been used for a long time. The fact that most of your memory is in this state means two things:

    1. Some app (or multiple apps) allocated a lot of memory, and is not actively using most of it. Often (but not always) this is due to a memory leak in the app.
    2. The pagefile is not large enough for the system to move all this unused memory to disk.

    If you sort the processes by Commit Size do you see any particularly big ones? If yes, do you expect them to be using that much memory?

    Also, have you disabled or reduced the default pagefile size? If yes, you can set it back to "system managed" and that will allow the system to recover physical memory by moving unused pages to the pagefile. (However, if it does turn out to be a memory leak then the pagefile will eventually become full anyway, so you'll need to close the leaking app, or if it's a driver leak, reboot the system).

    Wednesday, February 03, 2010 9:16 AM
  • Just start the computer go to BIOS and find the Memory Remap Feature and put Enable .

    This solve the problem.

    Regards

    I want to be a MVP! ______________________________ Computer Technician
    Wednesday, February 03, 2010 9:08 PM
  • Pavel:
    Well, as an idea I dont believe changing the page file will fix this - I will set it at 2GB for now, but as a student of 2 years in the computer networking field and being certified as an A+ tech (weak cert, but still), along with all the knowledge I have (I've been working on computers since win1.0), I dont have any belief that this is a solution.  As I understand paging files, it is managed "virtual memory" located as hard drive space and is used as the system as a last resort for dumping RAM it's still using - but perhaps not actively: IE: as real memory, just lower priority memory.

    1. Most likely possible a memory leak (where what how I dont know), firefox is the largest app on all memory sets - as shown in the screenshot and I really have no idea how to go about finding "what" is using such extreme amounts of memory without resorting to debugging MS Win7  system itself and using various programs to monitor further (again, my intent is to find an answer without having to debug an OS since I am a student with little to no free time as it is).

    2. How does this impact getting the data off/out of system RAM?  Is the Pagefile now used as a buffer that must be large enough before it can write it from memory to disk and then back to disk again?  (again, this isn't ignorance, Im going by how a Pagefile is accessed - as memory, not as a gateway).

    Every book I have ever bought, read, thought of - every web site, resource, teacher - and every experience with computers tells me that "allowing the system to manage swap file" is wrong.  There is nothing more exciting than a system with far more than enough physical memory, grinding a drive as extra memory if windows sees fit, while fragmenting (since if its managed by the OS it fragments, there fore causing larger/harder/more spaced read writes, access times, and data read/writing.) the swap and causing unnecessary slowdowns.  Again, unless the definition of pagefile has been changed since Windows 3.0 I do not think there is reason for a computer with 6GB of physical mostly unused memory, aside from a growing "modified memory"), to be needing a swap file larger than 512MB as when I start the PC I have more than 4GB free system RAM.

    Driver leak seems to be the most predominant feasible idea: How would I go about finding out what could be the culprit without destroying my system (without disabling/re-enabling drivers across the board and restarts between, reinstalling windows, etc.)?

    ~Matthew Buddha

    ~PS:  This was not meant to sound arrogant/like a jerk and I definitely should have supplied a much more thorough question.
    • Edited by Matthew Buddha Sunday, February 07, 2010 1:00 AM Minor Grammar and Reference edit
    Saturday, February 06, 2010 9:10 PM
  • benmenau:
    Memory Remap?  Do all BIOS have this?  And how does it solve the problem?  I have more than enough free resources when the computer is started. Its during long up time that the memory footprint grows large enough to get "there is not enough memory, close some programs" when opening a program such as any game I have, open office, or anything that uses more than 200MB of actual memory.

    My computer is already set correctly against hardware defect: this was not a problem in windows XP32bit (except the 4gb max memory, including video card memory/driver footprint/hardware allocation), or xp64 (tested through MSDN), or vista x64 (tested through MSDN and throw out the window).

    This is a problem that has not occurred due to hardware settings/limitations on any prior install of operating system, but is new to Win 7 (unless it happened in vista since win 7 is loosely built off it, I never left vista on longer than to see that a base install was taking over 50GB of space).

    ~Matthew Buddha
    Saturday, February 06, 2010 9:17 PM
  • Matthew,

    The only reason why these pages are kept on the modified list indefinitely is because the system doesn't have any available pagefile space left. If you increase the size of the pagefile the system will write most of these pages to disk and then move them from the modified list to the standby list. Standby pages are considered part of "available memory", because they can be reused for some other purpose if necessary.

    Whether this would "fix" the problem or not depends on what the actual problem is. If it's an unbound memory leak then increasing the size of the pagefile will simply allow the system to run longer before it eventually hits the maximum pagefile size limit, or runs out of disk space. On the other hand, if it's a case of some application allocating a lot of memory and not using it for a long time, then increasing the pagefile might be a perfectly valid solution.

    Allowing the system to manage the size of the pagefile actually works well in most cases. Pagefile fragmentation (at the filesystem level) can only occur when the initially chosen size is not large enough and the system has to extend it at run time. For win7 we have telemetry data that shows that even for systems with 1 GB of RAM, less than 0.1% of all boot sessions end up having to extend the pagefile, and this number is even lower for larger amounts of RAM. If you think you are in that 0.1% and your pagefile might be getting fragmented, you can manually increase its minimum size such that the total system commit charge stays below 80% even if you run all your apps at once (80% is the threshold at which the pagefile is automatically extended). This will make sure the pagefile is created once and then stays at the same size forever, so it can't fragment. The maximum size can either be set to the same value as the minimum, or you can make it larger so that the system is more resilient to memory leaks or unexpectedly high loads.

    By the way, Windows doesn't use pagefiles as "extra memory", it uses them as a backing store for private pages, just like regular files are used as a backing store for EXEs/DLLs and memory mapped files. So if the system really has more than enough RAM (like in your second screenshot, where you have 3.6 GB of free pages) you shouldn't see any reads from the pagefile. You can verify this by going to the Disk tab in the resource monitor and looking for any disk IO from pagefile.sys. On smaller systems that don't have an excess of free pages you may see periodic reads from the pagefile, and this is expected because the total amount of data referenced by the OS/drivers/processes is larger than the total RAM. Forcefully keeping all pagefile-backed pages in memory (which is what disabling the pagefile does) would simply mean some other pages (memory mapped files, DLL code or data etc) would have to be paged out.

    Regarding further troubleshooting steps: If the system runs fine with a larger pagefile (commit charge stabilizes well below 80%, and you no longer see gigabytes of modified pages accumulating in memory) then you don't really need to do anything. If the problem persists, you can check for any processes with an abnormally high commit charge, and also check kernel memory usage in task manager. If it's a kernel leak you can usually narrow it down to a particular driver using poolmon.exe or kernel debugger.

    • Marked as answer by Matthew Buddha Wednesday, February 10, 2010 2:09 PM
    Wednesday, February 10, 2010 7:59 AM
  • I am having the same problem with Windows 7 32bit OS. I booted the system at 7:00am and by 10:30am it at 1GB in Modified memory. I set my pagefile to 1.5 times my RAM (4GBx1.5=6.1GB) and rebooted. It is now 2:45pm and it is slowly climbing again, it is above 1GB.
    Monday, February 22, 2010 11:00 PM
  • As it appears - it seems that increasing my swap size is only a stop-gap fix.  It continues after a few days more - which leads me to believe that my virtual memory fills up then starts to overflow.  Well, X that out. 

    Any better ideas?
    Friday, February 26, 2010 1:37 AM
  • As Pavel indicated...
    If the problem persists, you can check for any processes with an abnormally high commit charge, and also check kernel memory usage in task manager. If it's a kernel leak you can usually narrow it down to a particular driver using poolmon.exe or kernel debugger.
    Start by checking the Commit Size column on the Processes tab in Task Manager. Watch the value over time.  Does any process stand out as consuming  an excessive amount? On Task Manager's Performance tab, monitor the Paged and Nonpaged kernel memory over time. Do the values seem to grow unbounded?
    Friday, February 26, 2010 2:13 AM
  • I've just come across this topic after having a similar problem yesterday. 

    I reinstalled Windows Live Photo Gallery on my Win 7  x32 system with 3GB Ram, and this forced it to rebuild all the thumbnails. I have about 120,000 pictures stored currently. The RAM usage climbed steadily up to 99% with about 2GB of that being modified memory, over a couple of hours, and even if I shut WLPG it continued for a while as the running threads took up to another 20 minutes to complete. Even then the modified memory wasn't released and so I had to restart to make the system respond at normal speeds. I had to restart like this several times before it completed all the thumbnails. 

    I've just checked my Pagefile details - they are marked as under system control, and currently seems to be 3GB.

    Is this a known problem with WLPG? It's the most up to date version, and I reinstalled it after trying the Beta version for a couple of days. Normally I don't rebuild all the thumbnails and so haven't noticed this issue before. The other problem with this large modified memory chunk is that it makes shutting down take anything up to 10 minutes while it writes everything to disk. 

    Saturday, July 31, 2010 8:05 AM
  • Matthew,

    I was having the same issue. I isolated the issue to be my Dell Wireless WLAN service (DW WLAN). I disabled it through msconfig, just use windows WLAN AutoConfig, and all is well now. Even if not on a Dell try disabling the computer manufacturer's wireless service.

    Hope this works for ya!

    -ND

    Wednesday, August 11, 2010 9:04 PM
  • ndogg, yes, at least in my mind, DW WLAN is notorious. I uninstall it everywhere now and install just the driver, which allows wireless to work fine. The other 80MB of DW stuff (or whatever its size is), including the service and the rest of it, is unnecessary. Perhaps just disabling the service is enough, but I didn't want any of it around anymore after all the time wasted and trouble caused.

    I believe I isolated it to this by adding the Handles column to Task Manager and watching it leak them like crazy, which eventually leads to paged (or non-paged, I forget which) memory spiking and ultimately "low memory" warnings. One other symptom of having this installed: logoffs can take several minutes.

    Wednesday, August 11, 2010 9:29 PM
  • I wish the DW WLAN might be the problem... but it's not as I have a destop platform, no wireless devices, with a solid 1gbit connection/wired.  To this day the problem still persists, even through a few reinstalls/etc - even got rid of a few hardware bits and pieces to see if that were the problem (g15, new mouse, new motherboard) but it seems to persist.
    Wednesday, August 11, 2010 9:55 PM
  • Run RAMMap [1] and look what data are "modified" you can filter for it.

    André

    [1] http://technet.microsoft.com/en-us/sysinternals/ff700229.aspx

    "A programmer is just a tool which converts caffeine into code" CLIP- Stellvertreter http://www.winvistaside.de/
    Wednesday, August 11, 2010 10:54 PM
  • Also, did you overlook the message from No.Compromise above?  Add the Handles and GDI columns there too. Watch all those things and you should be able to narrow it to a process.
    Wednesday, August 11, 2010 11:11 PM

  • Sounds like a memory leak to me. Have you gone through your programs and processes one at a time to see which are growing in size? Probably a pain to do, but I would assume it's just one program not playing nice.
    As it appears - it seems that increasing my swap size is only a stop-gap fix.  It continues after a few days more - which leads me to believe that my virtual memory fills up then starts to overflow.  Well, X that out. 

    Any better ideas?

    Thursday, September 23, 2010 5:14 PM
  • I also have a problem with a lot of modified memory usage. In my case it is caused by a .net application which allocates and releases a lot of memory. The modified memory is not dedicated to the process of the .net application, but it is definatelely caused by it. Maybe something in kernel mode where I cannot take care of causes this memory leak?

    Another way to release the modified memory than just closing the application is by confirming the User Account Control, for ecample by starting the regedit.exe! This is a very strange behavior...

    Maybe this is something for the Windows 7 bug report category?


    • Edited by 313371 Thursday, February 23, 2012 3:05 PM
    Thursday, February 23, 2012 2:57 PM
  • 2 years to late but I am posting because, when this issue is Google'd this is one on the first page, so similar people having this issue will come here.

    I have 10GB, and 6.7gb was being used as modified, 8gb total used

    Taskmanager from what it appears does not show how much modified memory a program uses

    Anyway so I ended a couple , for me  around 50mb-150mb, programs and my ram use dropped to 2.5gb which is the norm usage for me.

    Programs include:

    AMD related processes

    Windows Update

    Windows MEdia Player

    MCC.exe, which is for remote controlling windows media player, from a android device

    Windows Media Center process

    Windows Live Messenger

    Skype

    ______________________________________________________________________

    I was aggravated so I ended them one after another, without  watching the memory, so I do not know if it is a mix of them that did it or if just one of them freed up the 5.5gb, but I solved my issue.

    Side note about the pagefile thing, mine is set to 500-2gb, I manually set it, windows never uses over 500mb for me, even during this episode of 6.7gb of ram being used for modified, it never used the remaining 1.5gb to try to help itself. People mentioned to look at commit size, maybe it is just my pc, but not one program's commit size was over 180mb.

    Anyway problem solved for me, which was a good thing because it has been climbing for days, and now it is finally gone.



    • Edited by martelmungo Thursday, August 02, 2012 4:12 PM misspelling
    Thursday, August 02, 2012 4:11 PM
  • Thanks everyone, I was having the same issue and added handles and GDI and saw BCMWLTRY.EXE, the Dell wireless tray util, is creating handles nonstop. Thanks for the advice.

    Update: So I disabled the service that started BCMWLTRY.EXE + rebooted and I'm now not seeing the handle leaks. WLTRAY.EXE is still running but it's not leaking handles.

    • Edited by netdragon2010 Wednesday, June 05, 2013 5:12 AM
    • Proposed as answer by TechGuyResolve Monday, February 24, 2014 1:17 PM
    • Unproposed as answer by TechGuyResolve Monday, February 24, 2014 1:17 PM
    • Proposed as answer by Agg25 Wednesday, April 23, 2014 9:25 AM
    Wednesday, June 05, 2013 4:54 AM
  • Hi all, it was making me a lot of headaches the excessive "modified" memory usage in Win7 x64. At first was everything okei, but when my computer was working like 2 hours the modified usage would go up to 3gb and if i opened firefox with 2 tabs open, it would immediately crash.

    Finally after reading all the suggestions 4x time i found the problem. My problem was conduithelp.exe it used about 3gb modified memory ( but i couldn't see anywhere that it uses that much, i noticed it under processes that it is 1 program that uses a lot of memory like ( 300k , the same as firefox) and im not sure what program it is so i searched it(conduithelp.exe) and found out it was not a original windows process so i removed  it from processes and the modified memory went from 3gb to 110mb.

    Im so happy becouse i used to restart my comouter all times when it happened and now i got rid of it :). And i hope by writing here it can help also others.

    Thank you all for your insights.

    Regards,

    Oliver.




    Monday, February 24, 2014 1:21 PM
  • Thanks everyone, I was having the same issue and added handles and GDI and saw BCMWLTRY.EXE, the Dell wireless tray util, is creating handles nonstop. Thanks for the advice.

    Update: So I disabled the service that started BCMWLTRY.EXE + rebooted and I'm now not seeing the handle leaks. WLTRAY.EXE is still running but it's not leaking handles.


    Thanks Netdragon2010, this fixed it for me as well on our Dell Latitude E6230's. 
    Wednesday, April 23, 2014 9:38 AM
  • Handles  in task manager actually narrows down to a service that has over 70,000 while others normally less than 3,000. And simply stop that service gives me back around 4GB of Modified memory, thank you very much.

    I don't have to re-install my win8(now 8.1),  and can still keep it for its lifetime( I installed it the day MSDN release RTM, hope it can last to win9 rtm)


    I am a passionate game programmer.

    Sunday, August 03, 2014 4:10 AM