none
pinned heap objects

    Question

  • Hello *,

     

    we have a Windows Forms Desktop Application written in VB.NET. The components of our GUI we call „formular“ (inherits Windows.Forms.Form).  After recognizing OutOfMemoryExceptions at our customers and seeing that the memory of the application increases when opening  one formular after another or the same many times we debugged the application with WinDbg (with sos and sosex). It turns out that the GC was moving the instances of formulars up to Generation 2 and they were living there the whole time while the application was open although the formular.Dispose() method is explicitly called. The !gcroot command for the formulars shows that they all have root-handles which are pinned and the path to the root  seems to be similar for each formular. By climbing up the path from the formular up to the root (by sosex !refs) we ended up that some children aren’t connected to their shown parent. So the question is: How can we find out why the formulars are pinned?

     

    Below is the result of one !gcroot command for the formular “frmLohnarten”. It may be worth knowing that DataStart.Main is the main class of the application.

     

    Thread 11f4:

        0015ebc4 68f1ee58 System.Windows.Forms.Application+ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(IntPtr, Int32, Int32)

            ebp+50: 0015ebf0

                ->  021e64c0 System.Windows.Forms.Application+ComponentManager

                ->  021e6520 System.Collections.Hashtable

                ->  021e6554 System.Collections.Hashtable+bucket[]

                ->  021e6510 System.Windows.Forms.Application+ComponentManager+ComponentHashtableEntry

                ->  021b3a74 System.Windows.Forms.Application+ThreadContext

                ->  021c86f8 System.Threading.ThreadExceptionEventHandler

                ->  021b28b4 DataStart.My.MyApplication

                ->  021b376c Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase+WinFormsAppContext

                ->  021c9bfc DataStart.Main

                ->  021ce890 System.ComponentModel.EventHandlerList

                ->  02e0ad70 System.ComponentModel.EventHandlerList+ListEntry

                ->  02e0ab54 System.ComponentModel.EventHandlerList+ListEntry

                ->  02e071d8 System.ComponentModel.EventHandlerList+ListEntry

                ->  021e0ec4 System.ComponentModel.EventHandlerList+ListEntry

                ->  021e0eb0 System.ComponentModel.EventHandlerList+ListEntry

                ->  07e0f35c System.EventHandler

                ->  07e0f32c System.Object[]

                ->  0ab42a28 System.EventHandler

                ->  0ab270a4 System.Windows.Forms.ToolTip

                ->  0ab27118 System.Collections.Hashtable

                ->  0ab2b218 System.Collections.Hashtable+bucket[]

                ->  0ab28ec8 Data.NumericUpDownNoMouseWheel

                ->  0ab29014 System.Windows.Forms.PropertyStore

                ->  0ab2eae4 System.Windows.Forms.PropertyStore+ObjectEntry[]

                ->  0ab2c1bc System.Windows.Forms.ContextMenuStrip

                ->  0ab2c458 System.ComponentModel.EventHandlerList

                ->  0ab2e97c System.ComponentModel.EventHandlerList+ListEntry

                ->  0ab2e8d8 System.ComponentModel.EventHandlerList+ListEntry

                ->  0ab2e8c4 System.ComponentModel.EventHandlerList+ListEntry

                ->  0ab2e884 System.ComponentModel.CancelEventHandler

                ->  0ab26d9c Data.CFilter2

                ->  0ab26fc0 System.ComponentModel.EventHandlerList

                ->  0774c7b0 System.ComponentModel.EventHandlerList+ListEntry

                ->  0774c790 System.Windows.Forms.MouseEventHandler

                ->  0ab1d538 Lohn.frmLohnarten

     

    HandleTable:

        001b13ec (pinned handle)

        -> 031b3338 System.Object[]

        -> 021ce49c System.Collections.Generic.Dictionary`2[[System.Object, mscorlib],[System.Collections.Generic.List`1[[Microsoft.Win32.SystemEvents+SystemEventInvokeInfo, System]], mscorlib]]

        -> 021ce7c0 System.Collections.Generic.Dictionary`2+Entry[[System.Object, mscorlib],[System.Collections.Generic.List`1[[Microsoft.Win32.SystemEvents+SystemEventInvokeInfo, System]], mscorlib]][]

        -> 021d644c System.Collections.Generic.List`1[[Microsoft.Win32.SystemEvents+SystemEventInvokeInfo, System]]

        -> 0ae0db60 System.Object[]

        -> 0abeb4f4 Microsoft.Win32.SystemEvents+SystemEventInvokeInfo

        -> 0abeb4d4 Microsoft.Win32.UserPreferenceChangedEventHandler

        -> 0abe7078 System.Windows.Forms.ContextMenuStrip

        -> 0abe7314 System.ComponentModel.EventHandlerList

        -> 0ac2d4cc System.ComponentModel.EventHandlerList+ListEntry

        -> 0abf23cc System.ComponentModel.EventHandlerList+ListEntry

        -> 0abf23b8 System.ComponentModel.EventHandlerList+ListEntry

        -> 0abf2378 System.ComponentModel.CancelEventHandler

        -> 0abdd070 Data.AdvDataGridView

        -> 0abdd3cc System.ComponentModel.EventHandlerList

        -> 0abe6bb0 System.ComponentModel.EventHandlerList+ListEntry

        -> 0abe6c1c System.EventHandler

        -> 0abe6c04 System.Object[]

        -> 0abe6b90 System.EventHandler

        -> 0abe6b70 Data.Aktivierungsstack

        -> 0abdd9bc System.Windows.Forms.DataGridView

        -> 0abe6808 System.Windows.Forms.DataGridView+DataGridViewDataConnection

        -> 0abe6748 System.Data.DataView

        -> 0ab2fe6c System.Data.DataTable

        -> 0ab2fbf0 System.Data.DataSet

        -> 0ab2fc5c System.Data.DataTableCollection

        -> 0ab2fc80 System.Collections.ArrayList

        -> 0ab406e0 System.Object[]

        -> 0ab3d270 System.Data.DataTable

        -> 0ad566e4 System.Data.DataRowChangeEventHandler

        -> 0ad06054 Data.AdvDataGridView

        -> 0adff3c4 System.EventHandler`1[[Data.AdvDataGridView+CellCancelEventArgs, DataBasis]]

        -> 0ab1d538 Lohn.frmLohnarten

    Regards,

    David

    Wednesday, August 28, 2013 2:33 PM

Answers

  • Hi David,

    I have less information so that I can’t reproduce it on my side, could you please send me something more to deal with it?

    According to your description, GC has moved the instances to Generation 2 means that many instances were created, lived in heap and not disposed. Our target now is to narrow down this issue to find out what type of the instances caused this problem. I recommend you to build some simple test projects and each project contains one form from your application. Run them and see the changes of the heap.

    By the way, did you use MDI forms in your application? See http://www.vbforums.com/showthread.php?393174-RESOLVED-Howto-Dispose-of-Child-Form for more information and may helpful for your issue.

    Best Regards,


    <THE CONTENT IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND, WHETHER EXPRESS OR IMPLIED>
    Thanks
    MSDN Community Support

    Please remember to "Mark as Answer" the responses that resolved your issue. It is a common way to recognize those who have helped you, and makes it easier for other visitors to find the resolution later.

    Wednesday, September 04, 2013 9:16 AM

All replies

  • Have you checked if the problem can be caused by some event handlers, added explicitly with AddHandler, for example after creating a child dialog, but without RemoveHandler before the form is disposed?

    Wednesday, August 28, 2013 7:23 PM
  • Hi Drh,

    Welcome to post in MSDN forum.

    I do think the eventhanlder is a possible reason for this kind of issue.

    To add more, I think the following helps more.

    #OutOfMemoryException and Pinning

    http://blogs.msdn.com/b/yunjin/archive/2004/01/27/63642.aspx

    Best Regards,


    <THE CONTENT IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND, WHETHER EXPRESS OR IMPLIED>
    Thanks
    MSDN Community Support

    Please remember to "Mark as Answer" the responses that resolved your issue. It is a common way to recognize those who have helped you, and makes it easier for other visitors to find the resolution later.

    Thursday, August 29, 2013 8:07 AM
  • Thank you for your answers.

    I thought there is no need to use RemoveHandler for cleanup. I added calls of RemoveHandler in Dispose(Boolean) and ensure that Dispose is called recursively. But this seems to change nothing. Memory consumption is still about the same as before.
    Thursday, August 29, 2013 4:41 PM
  • Hi David,

    I have less information so that I can’t reproduce it on my side, could you please send me something more to deal with it?

    According to your description, GC has moved the instances to Generation 2 means that many instances were created, lived in heap and not disposed. Our target now is to narrow down this issue to find out what type of the instances caused this problem. I recommend you to build some simple test projects and each project contains one form from your application. Run them and see the changes of the heap.

    By the way, did you use MDI forms in your application? See http://www.vbforums.com/showthread.php?393174-RESOLVED-Howto-Dispose-of-Child-Form for more information and may helpful for your issue.

    Best Regards,


    <THE CONTENT IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND, WHETHER EXPRESS OR IMPLIED>
    Thanks
    MSDN Community Support

    Please remember to "Mark as Answer" the responses that resolved your issue. It is a common way to recognize those who have helped you, and makes it easier for other visitors to find the resolution later.

    Wednesday, September 04, 2013 9:16 AM