Continued from part 1 (or what does VMMap give).
Before checking the memory with the application running (from just looking at Task Manager I know I have a problem there too), I actually wanted to see how the other programs look after the memory leak was solved.
Task manager (after going to lunch (last time the computer just died)):
VMMap:
It still show a lot of the memory as free but at least some of the memory is freed over time. It is still weird because Task manager shows ~100MB of memory used and this graph shows more. Because of that I decided to investigate Task Manager a bit more and view most of the memory related columns:
I actually looked at “Memory (Private Working Set)” before (the default selected one and more correct one) and the timeline is with “Working Set (Memory)”. The difference between the two is that the second is the private working set (memory that can’t be shared) plus the memory that can be shared whereas the first is only the private memory that cannot be shared (at least according to this).
It actually still have a large hole in the middle (the purple lines are images – unmanaged memory). But I already thought in the last post I might have a problem there.
This main window is still pretty much unreadable. Can anyone really read this?
Comparing it to the before state:
The bottom grid is unneeded – it is just too much data without any way to organize it. Using the default sorting might show you the holes in the memory but Address Space Fragmentation is much better at this.
The middle grid is the interesting grid, look at the Private WS (=Work Set) column (this is the memory private to your process at least according to this):
- Purple – image – weird the memory was halved, see *
- Blue – Mapped File – is still unused.
- Light blue – Shareable – is still unused.
- Orange – Heap – has grown by 150%, see *
- Green – Managed Heap – from ~350MB to ~40MB, fixed that problem
- Light orange – Stack – is unchanged and is too low for me to care for…
- Yellow – Private Data – is lower by ~30%, see *
- Brown – Page Table – is lower but it’s too low to care…
* It can actually be because the testing process wasn’t as long or with as many updates.
Back to VMMap main page, the top seems to be a graphical representation of the Committed column, Private column and Total WS Column (in the middle grid). Again it is irrelevant to us (no way of changing it to Private WS column).
One last warning if you are planning to use VMMap, then don’t use at startup the option of “Launch and Trace a new process” with IE:
This option will launch with the process for the tab IE process not the IE process for the Silverlight Application(for more information on that look here (debugging and profiling being very similar…)). It is also the only way I found to activate the Call Tree and Trace buttons (bottom right of VMMap). The Heap Allocations button never worked for me…
So use this Task Manager knockoff (it gives you process name, PID, memory and user):
I just chose the IE process with the most memory usage – I usually have only two (and if I got the wrong one I actually don’t have a memory problem, do I? 
).
Until next time (this time I won’t say tomorrow since both my computer died (it’s still has problems) and our IT department decided to upgrade the systems over the weekend and nothing worked until they downgraded it back).
Resources:
Windows: What do the Task Manager memory columns mean?
Silverlight Tip of the Day #2– Attach to Process Debugging
Keywords: memory, vmmap, silverlight, memory leak
