Suppose you want a more detailed drill-down into your application’s GC heap usage. For example, you want to see if there’s fragmentation going on, or if there are lots of large objects, or if the XMLDocument objects you allocated a while ago are finally gone. This is something you can do with the CLR Profiler, another free Microsoft tool that supports memory allocation profiling as well as visualizing the managed heap at the individual object level.
Unfortunately, running the application under the CLR Profiler is very expensive. What do you need to do to obtain a memory view without running the application with the profiler attached?
- Open a dump file of the relevant application, or attach WinDbg to it.
- Load SOS and run the !traverseheap command to store a heap dump to a file (explained here in more detail). The larger the heap the longer this takes—may take hours for really large processes.
- Run CLR Profiler, select File | Open Log File and navigate to your heap dump.
- Click the "Object by Address" button to get a pretty view of the heap, with colors indicating various object types. If you zoom in (by adjusting the "Bytes/Pixel" and "Width / Addressrange" scales) you can see individual objects.
Note: CLR Profiler has another useful visualization feature (that I already blogged about), "Heap Graph", which is often relevant for debugging memory leaks.
To summarize, you have lots of options when it comes to understanding your .NET application’s memory usage. Even large applications with a variety of allocation sources can be dissected and analyzed, and every bit of memory can be accounted for. In the managed heaps, tools like CLR Profiler give you an object-level granular view of heap contents.