LUKE PUPLETT

Supplementary to my last post on WinDbg, here’s how I found a memory leak (600Mb working set for a background app anyone?) in under a minute.

The only instructions are: create a dump of your process using Task Manager, then drag and drop it into WinDbg. Load SOS and then issue the commands in bold in the following screen dump.

So, –dumpheap stat gives all objects and the memory they’re hogging. Strings and Ints are always the most so ignore them and focus on the next largest ‘real’ object.

For me, a generic Dictionary is hoarding over 100Mb. I then use !dumpheap –mt {address} to dump out the method table for this dodgy type.

This spits out addresses for each object. Then I just pick a random one and use !gcroot to see which object is holding the reference open.

The entire chain of references is shown, and RecorderScheduler is right at the bottom. I look at this in my code and find I have a Dictionary of “bad items” which is holding references to the Microsoft Windows Media Center API, which has a memory leak – i.e. my code is fine but the MS API is apparently not designed to have objects held open for days.

Luke

P.S. Another thing I noticed was how easy it is to see the value of a string, and thus how bad it is to store passwords in plaintext.