windbg memory leak trail

In this scenario, we are trying to explore the dump for memory leaks. Maybe that will be easier to focus on certain commands instead of learning all windbg commands. 

Analyzing memory 

Open your dump file and then run the following

!address -summary

address-summary will give a bird eye view of what's happening with the memory. 

!dumpheap -stat

You can see that we have about 20,000 objects of type Product and it is taking up about 0.8M.

If you click on the 7ffb81e16330 , it will display a whole list of product instances. 

Click on any one of them or do a !dumpobj /d 185b3ff8260 , you will be able to see details information of the object type. In this case, it contains only a simple name, id and details. 

To see what is holding on to these objects - or still having a direct references to this instance here, we do !gcroot and follow by any address of Product type we identify earlier.

!gcroot 0185b3ff3398

Look at the strong handle in screen below:- 

To see what's happening in our code, we run 

!clrstack 

This will returns a bunch of calls loaded at the moment. Since most of them belongs to dotnet, the only one relevant is Program.main.

To see what's happening in the code, we can use !u (unassemble) or we can use dumpil (which gives a proper CLR il code). To use dumpil,  we first need to get the method descriptor. For that we can run 

!name2ee *!Program.Main

name2ee - displays the MethodTable structure and EEClass structure for the specified type or method in the specified module.

In our case it is, 00007ffb81e09740. So to look at the il code we can just do 

!dumpil 00007ffb81e09740

And this is the actual code 

Other FAQ.

If you  get "No CLR runtime found. This means that a .NET", close and re-open your dump file again. It may helps to run  !analyze -v to download the relevant symbols first.