In his last post, David Anson explained how it was possible for "hidden" event handlers to introduce memory leaks and showed an easy way to prevent such leaks. Now he is going to show how to diagnose a .NET memory leak with the help of WinDbg, SOS, and GCRoot.
What if you don't know the source of the memory leak in the first place? Knowing how something is leaking is the first step to fixing it, and the web has some great resources for learning more about tracking down managed memory leaks in WPF and Silverlight applications. I am not going to try to duplicate that information here. :) Instead, I'll refer interested readers to these excellent resources and recommend a bit of web searching if additional background is needed.