none
Disposed Control Still Referenced by System.Windows.Forms.LayoutEventArgs RRS feed

  • Question

  • Hi,
    I'm currently trying to reduce the memmory usage using windbg + the !gcroot/!do commands.
    And I noticed that some Controls/Forms are stilled refenced by System.Windows.Forms.LayoutEventArgs like this:

    DOMAIN(003409F0):HANDLE(Strong):c11f8:Root:02da1b3c(System.Threading.Thread)->
    035ed9e4(System.Object[][])->
    02dbed24(System.Object[])->
    02dd6288(ITS.Forms.My.MyProject+MyForms)->
    10365d70(ITS.Forms.frmLetzteMahnung)->
    1036d654(System.Windows.Forms.LayoutEventArgs)->
    103660b4(ITS.SharedForms.itsDATMahnereignisse)

    I also noticed that 1036d654 points to the cachedLayoutEventArgs var.
    Is this someting I can do something about?

    Sunday, June 27, 2010 8:29 PM

All replies

  •  

    It sounds that the memory  usage of your application is huge and you want to know the reason and solution, am i right?

     

    If so, we may need to identify whether there is a memory leak, following two articles may help:

    Tracking down managed memory leaks (how to find a GC leak)

    Memory Leak Detection in .NET


    Sincerely,
    Eric
    MSDN Subscriber Support in Forum
    If you have any feedback of our support, please contact msdnmg@microsoft.com.
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    Monday, June 28, 2010 3:01 AM
  • Hi eryang,

    Thanks for the links.

    >> It sounds that the memory  usage of your application is huge and you want to know the reason and solution, am i right?
    Yes that too, but actually I'm sure there is a memory, or rater a (GDI/User)handle leak, since if I run some of my tests multiple times, then the memory usage/Handle counts go up, even If I use GC.Collect between the runs.

    So looking throw my objects, I found some rater old object, witch where disposed quit some time ago, but a still alive, because there is still a reference left, like the one in my original post, so I wanted to know if there is anything I can do about it.

    Thursday, July 1, 2010 4:21 PM
  •  

    Hi,

    Those objects keeping alive because they are still rooted, in your case, they are referenced  by MyForms object, I guess that the MyForms object represents the main form of your application, so this object will alive until your application exits.

    If you call Dispose method manually, you may set the object to null, so that the object will be GCed as soon as possible.


    Sincerely,
    Eric
    MSDN Subscriber Support in Forum
    If you have any feedback of our support, please contact msdnmg@microsoft.com.
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    Friday, July 2, 2010 6:49 AM
  • Hi Eric,

    >>  in your case, they are referenced  by MyForms object, I guess that the MyForms object represents the main form of your application
    The MyForms is a VB.Net Helper class, witch allows to easily acces a Std instance of all the Forms in the EXE Project, it doesn't represent my Main Form.

    >>, so this object will alive until your application exits.
    Some Forms are still collected/removed even with that reference, but I suppose it is faster if I remove it.

    There are even some object with don't even have any reference left, acording to !gcroot, but are still not collected, even if they are rater old

    Anything else I chould check, other then !gcroot and !do, in order to see why the gc doesn't remove it?
    (I just checked and I have 89 instances of a form, witch each have no references acording to !gcroot and where closed by form.close & form.dispose)

    Friday, July 2, 2010 7:55 AM
  •  

    Objects in managed heap are divided into three generations, gen0, gen1 and gen2. New allocated objects are gen0 objects, once an object survived after a GC operation, the generation of this object get prompted, gen0 -> gen1, gen1 -> gen2.

     

    GC on gen0 object has the highest frequency than gen1 GC, gen2 GC has the lowest GC frequency, so, if a gen2 object has no root, it still can alive from server gen0/gen1 GC operations; You may check whether those un-rooted objects is gen2 objects, sosex has a command !gcgen for this purpose.


    Sincerely,
    Eric
    MSDN Subscriber Support in Forum
    If you have any feedback of our support, please contact msdnmg@microsoft.com.
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    Friday, July 2, 2010 10:14 AM
  • Thanks for the link ot sosex, this helps a lot.

    But shouldn't objects from gc gen 2 get collected if I call System.GC.collect(2)
    I checked one of these objects witch has no more references via gcroot, and did a gcgen on it wich showd gen 2.
    So I did a System.GC.collect(2), but the object is still allive.
    Acording to !finq the object (and all other 23 instances of it) is on the finalization queue generation 2
    Also the !refs command showed this result:

    0:027> !refs 3510a530
    Objects referenced by 3510a530 (ITS.Controls8.frmError):
    3510a810      16 System.ComponentModel.EventHandlerList
    3510a70c      56 System.Windows.Forms.Control+ControlNativeWindow
    3510a764      52 System.Windows.Forms.CreateParams
    3510a6fc      16 System.Windows.Forms.PropertyStore
    3510ac40      16 System.Windows.Forms.LayoutEventArgs
    3510adc8      36 System.Collections.Queue
    3510a7c0      40 System.Windows.Forms.VScrollProperties
    3510a798      40 System.Windows.Forms.HScrollProperties

    Objects referencing 3510a530 (ITS.Controls8.frmError):
    3510a734       0 <?>
    3510a79c       0 <?>
    3510a7c4       0 <?>
    3510a818       0 <?>
    3510ae84       0 <?>
    3510ae8c       0 <?>

    Does this mean, that the 6 references with the size 0 and type <?> are whats keeping this object alive?

    Anyway, I also tried to attach VS and do a System.GC.WaitForPendingFinalizers, but the only thing that happened is that the app forze, so I detached vs again, after a couple of minutes.

    Saturday, July 3, 2010 4:18 PM
  •  

    You're correct, System.GC.Collect(2) collects objects of all generations.

     

    Since a call to GC.WaitForPendingFinalizers will froze your application, the finalize methods of some objects on finalize queue may working on time-consuming operations. "!threads" can show all managed threads, and the last one is the finalizer thread, switch to the finalizer thread by using command "~ns" (here, replace 'n' with the id of finalizer thread), then use "k" command to see the call stack, the call stack will show you what the finalizer thread doing.


    Sincerely,
    Eric
    MSDN Subscriber Support in Forum
    If you have any feedback of our support, please contact msdnmg@microsoft.com.
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    Monday, July 5, 2010 3:36 AM
  • I did this, and got this stack:

    0:002> k
    ChildEBP RetAddr 
    04aaf724 76920816 ntdll!ZwWaitForSingleObject+0x15
    04aaf790 771c1184 KERNELBASE!WaitForSingleObjectEx+0x98
    04aaf7a8 6e16e1c1 KERNEL32!WaitForSingleObjectExImplementation+0x75
    04aaf7ec 6e16e0f7 mscorwks!PEImage::LoadImage+0x1af
    04aaf83c 6e16e116 mscorwks!CLREvent::WaitEx+0x117
    04aaf850 6e3f7cb1 mscorwks!CLREvent::Wait+0x17
    04aaf8d4 6e3f7df7 mscorwks!Thread::WaitSuspendEventsHelper+0xc7
    04aaf8e8 6e3f819b mscorwks!Thread::WaitSuspendEvents+0x18
    04aaf8fc 6e25fb97 mscorwks!Thread::RareEnablePreemptiveGC+0xa5
    04aaf934 6e336f32 mscorwks!Thread::RareDisablePreemptiveGC+0xde
    04aafa44 6e36bd77 mscorwks!CtxEntry::EnterContext+0x54b
    04aafa78 6e36be1c mscorwks!RCWCleanupList::ReleaseRCWListInCorrectCtx+0xc4
    04aafac8 6e1efc5b mscorwks!RCWCleanupList::CleanupAllWrappers+0xdb
    04aafb0c 6e1efb6b mscorwks!SyncBlockCache::CleanupSyncBlocks+0xec
    04aafcd0 6e1e9270 mscorwks!Thread::DoExtraWorkForFinalizer+0x40
    04aafce0 6e1a01bf mscorwks!WKS::GCHeap::FinalizerThreadWorker+0x9a
    04aafcf4 6e1a015b mscorwks!Thread::DoADCallBack+0x32a
    04aafd88 6e1a0081 mscorwks!Thread::ShouldChangeAbortToUnload+0xe3
    04aafdc4 6e26a3ac mscorwks!Thread::ShouldChangeAbortToUnload+0x30a
    04aafdec 6e26a3bd mscorwks!ManagedThreadBase_NoADTransition+0x32

    Monday, July 5, 2010 8:04 AM
  •  

    It looks like an idle thread, the finalizer thread hasn't began to work or has finished its work.

     

    Could you please send me a dump file? you can create a dump file using command ".dump /mfh d:\mydump.dmp " in windbg, after you get the dump, please let me know your email address by sending a mail to v-eryang@microsoft.com. Then I will create a file transfer workspace where you can upload your dump file. The dump will be kept confidential. 

     

    By the way, it will be more helpful if you can attached your project source files.


    Sincerely,
    Eric
    MSDN Subscriber Support in Forum
    If you have any feedback of our support, please contact msdnmg@microsoft.com.
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    Monday, July 5, 2010 9:10 AM