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
From here we can see that my process is ID #4496
Step 3: Use VADump to get a summary of the process
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
To continue reading for free, register below or login
To read more you must become a member of SearchSOA.com
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
Once the debugger loads use this command to load our extension DLL
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.
