Today we’re going to talking about a memory leak issue found in Silverlight 4 and report on Silverlight’s forum by tsheflin As you know Silverlight is a .NET technology, so it’s mean you can use C# or Visual Basic to build your Silverlight’s applications and you have all the goodness of .NET, automatic memory management, garbage collector, type safety and so on.
But sometimes something goes wrong and we found that there are memory leaks on a dot net application; Silverlight is not free about this issues. So we’re going to identify how to find this memory issues with WinDBG and sos for Silverlight.
I’m going to use the same example provided by the user of the Silverlight.net forum. You can download from here.
First of all we need to build and run our application in release mode, this is important because there are a few differences between debug and release mode, then run the application without debugging and now its WinDBG time!
If your browser is Windows Internet Explorer 8 and you running Windows 7 or Vista, you may know that IE runs each tab in a separate process so you need to identify first witch process is running your code, in my example I found my process is 7958.
With WinDBG open (you can download from here http://www.microsoft.com/whdc/devtools/debugging/installx86.mspx#a), go to File -> Attach to process (F6), and select your process id (in my machine is 7958), immediately appear output window with all the basic debug information. Since our application is a managed application and WinDBG is designed to debug native application we need a debugger extension to debug managed application. What we need is SOS (Son of Strike). SOS is located in my machine here C:\Program Files (x86)\Microsoft Silverlight\4.0.50401.0\sos.dll for every version of Silverlight there is a SOS version, so depending the Silverlight version you’re debugging you need to load this extension.
Once we have this file, SOS can be loaded writing
And now we have all the power of SOS in WinDBG.
Next we need to find a valid memory address for our type SilverlightVisualTreeRemovalFail.SilverlightControl1 so we’re going to use !dumpheap command to dump all heap types and filter by this type writing this:
In output window we found some addresses for this type, selecting one 087b1a80 we need to find witch object is referencing this object (this is what is causing not to be recoleted) writing this:
We found that this object (087b1a80) is reference by other object and on the top of the list there is a HANDLE(Pinned):4a912f8 so its means that the garbage collection will always found a path to this object causing not to be garbage collected.
Now we identify the problem, but for now we can’t do anything because this is a Microsoft issue, because Microsoft’s code is referencing our control so we can’t fix this by ourselves. If this code is from us what we need to is simply remove references from this dictionary and then the control will be garbage collected.
We can also dump all the heap to a file and then open this file with CLRProfiler, type !traverseheap and file output and the open with CLRProfiler.
All the best.