In QuickUnit we develop a Visual Studio addin which allows developers to easily create quality unit tests. It’s a rather complicated, highly extensible, code-analysis and code-generation, .net application, with a rather complex UI layer (but with a simple UX). We use WPF (on MVVM) for the UI infrastructure, and make very heavy use of viewmodel objects, data bound to data templates. We’ve encountered a scenario where our memory consumption started growing, after every action which basically only re-rendered the UI. ProcessExplorer was kind enough to show us that the gen2 heap was growing steadily, and GC collections had no effect. Basically, the classic telltale signs of a managed memory leak. Our first mistake was to try to find the leak manually, by code reviews. We’re a strong, two-man team, and we know the code pretty darn well, so we figured this was only a matter of catching the ill-written line or two. The second mistake was finding an ill-written line or two which made us feel good about solving the problem. J After realizing that our solution did not help one bit – we told ourselves to get serious about it, and start profiling. Oh, the Ants Memory profiler kicks so much ass... After adding a “GC Collect” button to our application (a great feature to have in any memory profiler, btw) we were good to go. Read more: Technicals and Technicalities