Understanding Resource monitor Memory Usage

I am getting intermittent memory error message saying the pc has run out of memory and trying to track down what is causing it. When I boot up the pc I see Physical memory of 3.325 Gb and used memory of 1.04GB 32% in task manager. When i go to Resource manager I can't understand which of the different types of memory (Commit, working, private) make up the 1.04 reported as used. If I add up all the processes under Working Set it only comes to about 600Mb. So 2 questions:

a) Are ther other OS processes not listed in resource monitor that are using up the unaccounted 500Mb?
b) Is Working Set the right type of memory to be monitoring to see which p[rocess is causing the reported % usage to climb so much?

I'm intending to writie down each porcesses usage every 24 hours ot try and identify the culprit. Strangly the problem has only appeared since i increased the RAM from 1Gb to 4GB!

Thanks

You should post the actual error message, along with anything relevant from the event logs. There are many different types of memory and what you're experiencing could be any of a range of different issues. The numbers you're looking at generally require an understanding of "virtual memory" if they're to make sense. Many relatively sophisticated users fear this stuff because they think only in terms of RAM and they don't understand why the numbers don't add up.

Apps ("processes" actually) don't deal directly in physical memory (RAM). Instead, each app "sees" a 4GB virtual memory (VM) space of its own, irrespective of the amount of installed RAM, and the lower 2GB of that VM is usable by the app for its own needs. The other 2GB is VM occupied by kernel-mode code, and it cannot be directly touched by apps. (All this is 32-bit specific.)

An OS component called the memory manager (Mm) finds some "real" memory to back each region of used VM. It might be mapped to RAM or to the pagefile, depending on the amount of memory pressure, and generally the app neither knows nor cares. The OS guarantees that it will find suitable backing, as long as it has sufficient RAM and pagefile space to between them cover all of the "committed" VM that is currently in use. Simple definitions:

COMMITTED: The portion of an app's 2GB VM which is actually in use. This may be tiny, for Notepad say, or it may approach the theoretical 2GB VM maximum for large apps and games.

PRIVATE: If you run TASKLIST /M from a CMD prompt, you'll notice that each process loads more or less the same common DLLs into its 2GB VM space. It would be wasteful for the OS to consume multiple chunks of RAM to store multiple copies of say user32.dll, one for each process, given that user32.dll is always the same. Instead, those VM portions which are identical between multiple apps are actually "backed" by the same single RAM region. "Private" bytes are the opposite of that - those portions of the 2GB VM which are committed and unique to this process. In some ways it's the true size of the app.

WORKING SET: That portion of app VM which is currently resident in RAM. The rest of the committed VM is paged out to secondary memory (the pagefile on the HDD).

Perfmon can log these values over time so you don't have to write them down. Once you paste the exact error and any events you're seeing, it'll be easier to help you in a more practical way.

Next time it throws the eror I'll write it down and post it exactly. It takes about a week from each reboot to get to that point so I'm assuming that something is slowly leaking memory. Will revert when i have exact details.

could you just tell me where the Perfmon tool is so I can check that it is logging the right things to be useful?

Thanks

Type this or copy and past it into the search bar in the task manager or into the run command. perfmon.msc

Thanks, but all the reports are blank. I'm assuming I need to set something up somewhere to log particular statisitics. What statisitcs should I log if it is a memory problem and how do i create a report. I had a look in help and my eyes glazed over i'm afraid.

Yes, you need to create a collector definition. It's like a template which defines which perfmon data are to be logged, how often, and where to (which log file).

There's a built-in "System Performance" template but it's much too detailed for the type of memory leak you appear to suffer from. If you create a "user defined" log, all it needs are two objects:

\Process(*)\*
\Memory\*

In other words, all instances of all counters under the PROCESS object (just add the entire object), and all counters under MEMORY (again, add the entire object).
A log interval of say 5 minutes should be adequate, given it takes a week for the leak to manifest itself in an error.

If your pagefile is tiny or non-existent, odds are that one or more processes are leaking and the OS simply runs out of space (commit charge hits the commit limit).

Otherwise, it might even be a kernel-mode leak which would show up as a steady increase in "Memory\Pool paged bytes" or "Memory\Pool non-paged bytes". Those are more fun to troubleshoot

Ok so I have gone to Data Colelctor Set/user defined and clicked new. I have created manually and ticked all of performance counter, event trace and sys config info (don't if need all those). For perfomance counters I click add then click on process in top left box and add. Bottom left box has "totla" highlighted and right box now has Process. Same for Memory. I left event trace providers and reistry keys blank as not sur what these are for. i clicked start this data collector now. In reports/user defined I see a branch for the data set i just created with an entry saying running. inside that is a file 00001 with current time which presumably is first log. If i double click it is says "collecting data "

Have I done the right thing here?

Thanks

Sounds good. That file is getting written to with a new set of numbers (every 5 min, if that's the interval you've set), and by the time your symptom crops up you'll have a historical record which you can view as a line chart. The private/virtual/working set of each process, plus a bunch of other process-specific counters, plus the global "memory" counters. Perfmon is a cool toy.

If you now highlight "performance monitor" on the left pane, that shows you the analysis UI itself. Note the second button (view log data) - you'll need it a week's time. Counters can still be added for real-time viewing now, even though that data collector is running in the background.

Once you've got the log, I'd suggest first checking the "Memory\Committed bytes", "Memory\Pool paged bytes", and "Memory\Pool non-paged bytes" counters. If the committed bytes is going up and up and up towards your commit limit, which is the sum of all pagefile space plus 3.25GB (your RAM), then check the individual "Process\private bytes" under each process instance until you find the one(s) responsible.

If it's the pool counters then come back and say so, cos troubleshooting that is a tougher ask. Actually, you might already have warnings/errors in the Event Logs if you've got a pool leak.

Ok great I'll come bakc next time it happens and see if we can locate the problem. Thanks for all your help so far.

mike