Event handlers leak
This type of leak occurs when subscribing an object (let's call it listener) to an event of some other object (let's call it source). For example: Timer1.Tick += OnTimer; During subscription, the source object gets a reference to the event handler of the listener object. If you delete the listener, this reference will prevent it from being garbage collected. dotMemory automatically finds objects that are referenced in event handlers but are never unsubscribed from corresponding events.
Wpf binding leak
Breaking WPF data binding patterns also can cause a memory leak. After you perform data binding to some property of a source object, the binding target object starts to listen for property change notifications. If the property is not aDependencyProperty object and the target object does not implement the INotifyPropertyChanged interface, a memory leak in source object and in every object to which source object refers may occur. dotMemory detects such binding pattern violations and shows you the list of objects that may potentially cause this leak type.
The leak will not take place in case the OneTime binding mode is used to update the target.
Wpf collection binding leak
This leak is similar to the WPF binding leak described above. If there is binding to a collection that does not implement the INotifyCollectionChanged interface, WPF creates a strong reference to this collection. As a result, it stays in memory for the entire application lifetime. dotMemory detects and shows you such objects.
Dependency property leak
This leak occurs due to quite the same reasons as the event handlers leak. GC will not collect objects subscribed onDependencyProperty changes through the AddValueChanged method until they are unsubscribed using the RemoveValueChanged method. dotMemory detects and shows you all such A objects.
x:Name WPF leak
This leak takes place because of the following WPF peculiarity: WPF creates a strong global reference to the UI element that is declared in XAML and uses the x:Name directive. For example:< XNameTest:UserControl1 Grid.Row="0" x:Name="myControl1"/> Thus, if you dynamically remove the element declared in such a way, it will still be in memory.