Find Memory Leaks

One way to find memory leaks is to look at a task that performs a lot of memory allocations and keeps instances in memory, but whose memory should be released after the task is finished. Examples of such tasks are listed below:

  • Showing and closing a form
    When creating a form, each control must be allocated, and the instances of the form and controls are kept in memory. When the form closes all used memory should be garbage collected.

  • Opening and closing a document
    In a document-oriented program the user should be able to open a document, work with it and then close it without increasing the memory used by the application.

  • Retrieving a set of pages using ASP.NET
    When retrieving pages using ASP.NET, many temporary instances may be created, but, except for caching, all allocated instances should be released after the pages have been retrieved and the session (if any) has ended.

To find memory leaks of a selected task, you can click the “Investigate memory leaks” guide on the Start page and follow the steps in the guide. For more information, see Guided Profiling and the Tasks Window.

To find the memory leak manually, you can perform the following steps:

  1. Start profiling the application, service, or ASP.NET process using the procedure described under the Profile a .NET Process section.

  2. Perform the task you suspect are leaking memory (e.g., open a document, work with it, and then close it). This will make sure that all static instances are created.

  3. Collect a heap snapshot.

  4. Repeat the task performed under step 2.

  5. Collect another heap snapshot.

  6. Use the Show types drop-down list to select “With New or Removed Instances” to show types whose set of instances has changed between the two snapshots.

  7. Select the Types page and try to locate a type that has live instances that should have been collected. If no memory leak exists, the instances shown in the Types page should only be short-lived instances that have not been garbage collected yet. If a memory leak exists, you should be able to find a type with new instances that should have been garbage collected. For instance, if the task were opening and closing a document and a type representing the document has new instances, then there probably is a memory leak. If you have types that have disposed instances, it may also be an indication of a memory leak. For more information, see Dispose Tracker. The automatic memory analyser might also provide hints on potential memory leaks. For more information, see Automatic Memory Analysis

  8. Double-click on the type that has live instances that should have been collected.

  9. In the Instances table, double-click on one of the new instances (indicated by the symbol).

  10. In the Root path table you will get information about why the selected instance was not garbage collected.

For more information on how to locate memory leaks, see the .NET Memory Profiler tutorials at: http://memprofiler.com/tutorials.