Help finding a Memory Leak cause

Question

I have the following Leak situation in a VB.NET (.NET2) application: a form - DetailTache (TaskDetails) - in my MDI application is not garbage collected is not collected ofter open/close.

I did the following profiling root:

any idea how this leak could be fixed? thanks.

EDIT:

Result search from projet of WinComboRowSelected Event. There are 3 usages of this word in application:

1. Declaration in Class WinCombo: Event WinComboRowSelected(ByVal sender... (only one)
2. Raising: RaiseEvent WinComboRowSelected(sender, (3 raisings)
3. Usage: ...e As Keolis.ctlWinCombo.WinCombo.WinComboRowSelectedEventArgs) Handles cmbProduit1.WinComboRowSelected (multiple handles).

there is No other usage of this event.

If need other code details, please ask and I will post it.

Answer 1

Without your code it is hard to say how to fix the leak.

Remember what would make an item not garbage collected. If it still had a reference to the object.

I would look at your could and make sure all references are set to null when you expect it to be collected. If it is not being collected that means something still has a reference to it.

I would read this article for a better understanding of Garbage Collection.

Answer 2

Does your form have any event handlers that have not been unsubscribed? This would be the number one cause to controls not being garbage collected.

Make sure that the forms that subscribe to WinComboRowSelectedEvent also get unsubscribed before disposing of the form.

Answer 3

VMMap offers flexible views for memory analysis of live processes :

VMMap is a process virtual and physical memory analysis utility. It shows a breakdown of a process's committed virtual memory types as well as the amount of physical memory (working set) assigned by the operating system to those types. Besides graphical representations of memory usage, VMMap also shows summary information and a detailed process memory map. Powerful filtering and refresh capabilities allow you to identify the sources of process memory usage and the memory cost of application features.

Answer 4

The ToolTip that appears in the object tree looks significant to me. It probably wires a event handler for the RowSelected event so it can update the tip. Clearly you are using a 3rd party control, it smells like Infragistics. Not a company well known for the quality of its products. I'd further guess that the ToolTip is internal to its control and that you can't access it to forcibly unsubscribe the event handler. Beyond giving up on tool tips, if that's even possible, you can't do much but contact the vendor for support. Or ditch the control.

Answer 5

As pointed out nobugs (thanks again), the problem really resided in the used 3rd party components - Infragistics.

As I find out later, Infragistics team decided to keep static references to all the added controls in memory in order to support such (secondary imho) effects as XP theme changes.

Really helpful on the problem was this article, the solution provided in witch replaced the kept in memory objects with WeakReferences, that can be collected by the GC.

Luckily we used a older version of Infragistics that in the article and the solution worked. It's a pity, however, that Infragistics does not plan to fix this bugs, even declared years ago.