If you think you've got memory leaks, or if you're just wondering what kind of stuff is on your heap you can follow the very same steps that I do and get fabulous results your friends will envy. OK, well maybe not, but they're handy anyway.
These steps will help you to go from a suspected memory leak to the specific object references that are keeping your objects alive. See the Resources at the end for the location of all these tools.
Step 1: Run your process and put it in the state you are curious about
Be sure to choose a scenario you can reproduce if that's at all possible, otherwise you'll never know if you're making headway in clearing out the memory leaks.
Step 2: Use tasklist to find its process ID
C:>tasklist
Image Name PID Session Name Session# Mem Usage
========================= ====== ================ ======== ============
System Idle Process 0 RDP-Tcp#9 0 16 K
System 4 RDP-Tcp#9 0 112 K
smss.exe 624 RDP-Tcp#9 0 252 K
...etc...
ShowFormComplex.exe 4496 RDP-Tcp#9 0 20,708 K
tasklist.exe 3636 RDP-Tcp#9 0 4,180 K
From here we can see that my process is ID #4496
Step 3: Use VADump to get a summary of the process
C:>vadump -sop 4496
Category Total Private Shareable Shared
Pages KBytes KBytes KBytes KBytes
Page Table Pages 35 140 140 0 0
Other System 15 60 60 0 0
Code/StaticData 4596 18384 4020 3376 10988
Heap 215 860 860 0 0
Stack 30 120 120 0 0
Teb 4 16 16 0 0
Mapped Data 129 516 0 24 492
Other Data 157 628 624 4 0
Total Modules 4596 18384 4020 3376 10988
Total Dynamic Data 535 2140 1620 28 492
Total System 50 200 200 0 0
Grand Total Working Set 5181 20724 5840 3404 11480
Here we can see that the process is mostly code (18384k)
The vast majority of the resources that the CLR uses are under "Other Data" -- this is because the GC Heap is directly allocated with VirtualAlloc -- it doesn't go through a regular windows heap. And same for the so-called "loader heaps" which hold type information and jitted code. Most of the conventional "Heap" allocations are from whatever unmanaged is running. In this case it's a winform application with piles of controls so there's storage associated with those things.
There isn't much "Other Data" here so the heap situation is probably pretty good but let's see where we stand on detailed CLR memory usage.
Step 4: Attach Windbg and load SOS
C:> windbg -p 4496
Once the debugger loads use this command to load our extension DLL
0:004> .loadby sos mscorwks
This tells the debugger to load the extension "sos.dll" from the same place that mscorwks.dll was loaded. That ensures that you get the right version of SOS (it should be the one that matches the mscorwks you are using).
Click here to read the remaining four steps to this process.
Rico Mariani is a Performance Architect in the Developer Division at Microsoft. Rico began his career at Microsoft in 1988, working on language products beginning with Microsoft C version 6.0, and contributed there until the release of the Microsoft Visual C++ version 5.0 development system. In 1995, Rico became development manager for what was to become the "Sidewalk" project, which started his 7 years of platform work on various MSN technologies. In the summer of 2002, Rico returned to the Developer Division to take his present position as Performance Architect on the CLR team. Rico's interests include compilers and language theory, databases, 3-D art, and good fiction.
