Vishful thinking…

Hunting down memory leaks in Silverlight

Posted in .NET, Silverlight by viswaug on July 13, 2009

Recently, I was noticing some memory issues with a Silverlight application I was working on. I was creating a dialog window (user control) dynamically where the user could edit and save data. The dialog user control was data bound to a ‘ViewModel’ type which populates the data controls in the dialog and is then used to populate and save a business object. After, the user clicks on the OK or the Cancel button, i was disposing away with the user control from memory by setting its reference to NULL. But, when i repeated the process of opening and closing the dialog multiple times, the memory used by Internet Explorer always kept going up. This made me suspicious that even though I was setting the user control’s reference to NULL, the user control was never disposed away from memory.

To confirm that multiple instances of the user control were still in memory, I resorted to using “windbg”. Following the steps below, you can confirm and debug memory leaks in Silverlight and also in the .NET CLR.

  1. Download and install windbg from here.
  2. Run the Silverlight application and bring it to a state where you think a memory problem exists. In my case above, I had to open and close the suspect dialog multiple times.
  3. Run windbg and attach to the Internet Explorer process running your Silverlight application.

    windbg1windbg2

  4. Load the SOS debugging extension for Silverlight. This is installed with the Silverlight SDK on your system. The ‘SOS.dll’ is found under the Silverlight installation directory. For me it is at “C:\Program Files\Microsoft Silverlight\2.0.40115.0\sos.dll”. To load the SOS debugging extension execute the command “.load C:\Program Files\Microsoft Silverlight\2.0.40115.0\sos.dll” in the windbg window.

    windbg3

  5. Run the “!dumpheap -stat” command to view the objects in memory and the count of their instances.
  6. Run the “!dumpheap –stat –type [TypeName]” command to view the number of instances of the specified type in memory. In my case, I found that the number of instances of the dialog user control object in memory was always equal to the number of times I had opened and closed the dialog user control. This indicated that the user control object were not getting disposed from memory even when I had set its reference to NULL.
  7. Run the “!dumpheap –type [TypeName]” command to view all the memory addresses of the object’s instances.
  8. Run the “!gcroot [Address]” command to view how the instance of the object can be reached. In other words, it tells us what is holding on to the reference of the object and thus keeping the object in memory without being cleaned up by the garbage collector. The output here is hard to read, but the pain of going through this exercise will definitely pay off when the memory leak in the application has been fixed.

In my case, it turned out that the ‘ViewModel’ object the dialog user control was being data bound to was holding on to a reference to the user control object. So, to fix the memory leak, all I had to do was to set the ‘DataContext’ property of the user control to NULL before setting the user control reference itself to NULL.

About these ads

5 Responses

Subscribe to comments with RSS.

  1. junihor said, on July 13, 2009 at 5:39 pm

    Thank you for the detailed steps. I too was looking for ways to find ML in .net apps. Your post offers a lot of insights. Good work.

  2. alvin said, on March 5, 2010 at 4:28 am

    hello, just wondering does this step work with x64 windows 7.. silverlight 4? can’t get it to work.. when I execute the “.load ….\sos.dll” its giving me %1 is not a valid Win32 application. thanks!

  3. Mark said, on September 27, 2010 at 9:42 pm

    alvin: use .load C:\Windows\Microsoft.NET\Framework64\v4.0.30319\sos.dll

  4. Mark said, on September 27, 2010 at 10:57 pm

    Alvin:

    Actually for debugging Silverlight apps you need the 32 bit version of WinDbg.

    Also, note that if you are installing the Debugging tools from the Windows SDK Toolkit, it will install the 64-bit version of WinDbg ONLY. To get the 32 bit version, you have to do the following:
    - Re-run the installer and check off ‘Redistributable -> Debugging Tools’ in the installer (it isn’t selected by default)
    - When the installer finishes, you will find the x86 version of WinDbg here:
    C:\Program Files\Microsoft SDKs\Windows\v7.1\Redist\Debugging Tools for Windows\dbg_x86.msi

    Install this, run the 32 bit version of WinDbg, and attach to the second IE process (to know which is the correct process, look here: http://forums.silverlight.net/forums/p/199289/464882.aspx). The commands should work OK going forward.

  5. Anil Kumar Perugu (@anilchinnu21) said, on September 25, 2011 at 10:26 am

    Below is the ultimate solution that we found after looking into the codeplex community forum threads.

    http://www.dotnetthread.com/articles/6-SolutiontoMemoryleakissueswithSilverlightcontroltoolkit.aspx


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: