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

Question

I have 6GB of ram, a fresh install of Windows 7 x64, and the screenshot shows what happens after leaving my PC on for a couple days. (3782+MB being used by modified memory ATM).
http://wow.deconstruct.me/images/ExcessiveMemory.jpg
Any ideas on this?
Edit:
Added this after first round of suggestions
http://wow.deconstruct.me/images/NotSoExcessiveMemory.jpg
This is uptime of around 2 hours.
The first image is of uptime of around 3-5 days.

Answer 1

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.