I blogged a long time ago on how to use WinDbg to find memory leaks in Silverlight application.  Yesterday I had to face a variation of the problem, but this time I had to debug a custom issue.  So, what we did is have customer create memory dumps.  To do that we instructed them to run the application in IE, what periodically for memory used by IE, then when memory got unreasonably high, take memory dump.  You can do that from Task Manager.  Just right-click on your process (iexplore.exe), and select option Create Dump File.  Once that is done, just have your customer transfer the file to you.

Once you have it on your local hard drive, start WinDbg (32 bit version) and under File menu select Open Crash Dump and point to your file.  Once thing you must have is the same version of Silverlight as they use.  If you do not, find a machine that has that version and copy the content of C:Program Files (x86)Microsoft Silverlight{target version} onto your machine into the same folder.  You may have to use C:Program FilesMicrosoft Silverlight if the customer is running 32 bit OS because the dump file will refer to that path.

Once that is done, in command line window (bottom of WinDbg screen) type

.load C:Program Files (x86)Microsoft Silverlight4.1.10111.0sos.dll

where the path you use is the one containing the same version of Silverlight.

Once that is done, you need to load CLR debugging modules

.cordll -ve -u –l

You may also need to expand search path for WinDbg to find debugging symbols

.exepath+ C:Program FilesMicrosoft Silverlight4.1.10111.0

After that you are ready to run

!dumpheap -stat

Then continue as described in my previous post.  What have we achieved here you ask?  I just implemented remote debugging on client machine!  Pretty cool, hah?

Thanks.