If you work on .NET stack, you might have already encountered situations where your application, for some reasons is using a lot of memory. To investigate, we as developers, will most of the times, use Profilers tools.
Profilers help troubleshooting those issues but what they mainly do is give information about memory allocation. What they don’t do though, is giving you accurate information about the memory that is kept and hanging round.

Debug your application

Tess Fernandez, from Microsoft, show us how to use tools like WinDbg to debug .NET code. What you do is create Dump files and analyze them. Windbg is a native debugger and doesn’t understand anything about .NET objects. To make things more usable, we use an extension called SOS (Son of Strike).

Let’say, for some reasons you want to know which quantity of object memory is still not de-allocated and resides on the heap. How would you do that ?

What if you want to know the address of any instance of a specific object’s type on the heap ?

Windbg

We assume that .NET Garbage Collector runs, based on conditions that we don’t control.
Yes, you can always (technically) explicitly call GC.Collect, but that would be a bad decision. If you happen to think about using this code, it’s time to re-think what you are doing… From the early days, Microsoft architect Rico Mariani has warned us about GC.Collect() usage. Also, Phil Haack, former Microsoftie, and now at GitHub wrote something similar about GC.Collect().

Back to Tess and .NET debugging, I recommend you take a look at this DNR TV show, in which Carl, from Franklins.Net discusses with Tess about intricacies inherent to Debugging in .NET.

Tess talks with Carl

Have fun and enjoy Tess Ferrandez brings her debugging wizardry to dnrTV. Tess shows us how to solve memory and performance issues using tools such as windbg and sos, and also gives a preview of debugging in Visual Studio 2010.