Filters cannot identify memory problems themselves, but they can help by focusing your investigation. The following notes suggest filters that can be useful in some conditions.

Filters that can help find a memory leak

The following filters can be useful in finding a memory leak:

• From the current snapshot, show only survivors in growing classes
  This filter is particularly useful, because classes with an instance diff of 0 on the Class List are good candidates for finding memory leaks (no instances of the class were disposed between the two snapshots).
• Disposed objects which are still in memory
  This filter is useful because disposed objects should not normally be kept in memory.
• Kept in memory exclusively by event handlers
  Event handlers should not normally be the only reason an object is kept in memory, so this filter can help identify a memory leak.
• Kept in memory exclusively by disposed objects
  Disposed objects should not normally be kept in memory, so this filter can help identify a memory leak.
• From the current snapshot, show only zombie objects
  This filter is useful because these objects should not normally still be in memory in the current snapshot.

Filters that can help focus on a specific part of your application

The following filters can be particularly useful when you want to focus on a specific part of an application, or exclude a specific part of an application:

• Objects on large object / Gen 0 / Gen 1 / Gen 2 heap
  Use this filter to understand how objects are allocated in memory. Looking at objects on the Gen 2 heap may be especially helpful, because these are the longest-surviving small objects.
  You can also use this filter to investigate objects on the large object heap, which is useful if you have large object heap fragmentation.
• Kept in memory exclusively by objects from namespace
  Use this filter to look for your classes, excluding third-party and framework code. You should not normally do this when first looking for the source of a memory leak, because this filter may hide the symptoms of a leak originating in your code.
• Never referenced by an instance of class/interface
  Use this filter if you think that all classes should be referenced by a particular class or interface. If a class is still shown, it is being kept in memory for a different reason.

See the worked example, which demonstrates using filters in your memory profiling workflow.