none
Memory leak Found in .NET Framework 2.0 SP2 RRS feed

  • Question

  • Hi All please help in this issue .. Thanks in advance

    After showing, closing and disposing an MDI child form, the Form instance was still alive. So that memory utilization of the Application grows bigger  and bigger after open and close new child form. The memory usage is monitored using task Manager and clearly indicate that the memory leak is occured(shows increasing of memory even after closing the child form). I don't know what is the real cause for this particular issue.

    If the original version of .NET 2.0 Framework without any service pack this problem never come in to the existence and prove with Dot Net Memory profiler 3.1.

    But after installed Dot Net Service Pack 1 this problem come in to the existence. Now I am working with Dot Net Service Pack 2 and still have the problem exist . It will great help me to give me the reason and fix this issue.


    Talish George

    Friday, April 17, 2009 9:39 AM

All replies

  • Check for bug on MS official site http://connect.microsoft.com/ . As for me "no miracles in today's life". You could create simple application and check if you'll get same problem(i think if you got same behavior you should talk to MS about this), but it's unlickely... You just forgot to release some resources after some changes etc. Just start from creating MDI application to check if it's indeed problem in SP
    Regards
    Friday, April 17, 2009 11:37 AM
  • do you call any native code from your application?

    If not, then there might be bug, I will try and see if I can reproduce the issue.
    Ganesh Ranganathan
    [Please mark the post as answer if you find it helpful]
    Friday, April 17, 2009 11:49 AM
  • Hi Ganesh,

    Pls help me

    I found some related problem in the following link.

    http://www.scitech.se/blog/index.php/category/net-framework/

    Minor memory leak introduced in .NET Framework 2.0 SP1

    Thursday, March 20th, 2008

    A while ago we received a support request from a customer that had a memory leak in his application. After showing, closing and disposing an MDI child form, the Form instance was still alive. The root path indicated that the child form instance was kept alive by the MDI parent, via the internal propertyStore field. I tried to reproduce the problem using an MDI application that was easily available: the Game of Life application used in the .NET Memory Profiler tutorials . And to my surprise the Game of Life application had a memory leak, even after the memory leak fix in the tutorial had been applied.

    After having collected the last snapshot in the second .NET Memory Profiler tutorial  (after closing the Game of Life MDI window), there should be no new instances of any type (since the memory leak should have been fixed). Thus if the type filter is set to only show types “With new or removed instances”, the Types list shold be empty. If the original version of .NET Framework 2.0 is used, this is almost true. A single new <GCHandle> instance will exist, but for now I will ignore this (it will be discussed in a future post).

    GameOfLife snapshot (without SP)

    However, testing the tutorial after having installed .NET Framework 2.0 SP1 shows completely different results (as can be seen in the picture below). Even though no additional instances have been created (Delta is 0), there are still a lot of New and Removed instances.

    GameOfLife snapshot (SP1)

    At the time of the last snapshot, no Game of Life windows are open, so I would expect all LifeForm instances to be GCed, but there’s still one new live instance left. So the new LifeForm instance is a good candidate for memory leak analysis. The details of the new LifeForm instance is shown in the picture below.

    LifeForm instance details

    The shown root path of the instance indicates that a reference to the LifeForm instance is stored in a PropertyStore. The PropertyStore class is used internally by WinForms to save space when storing property values. Instead of using instance fields, the dictionary-like PropertyStore is used. Anyway, after doing some digging around using Reflector, I came to the conclusion that the LifeForm instance was put into the PropertyStore using the Form.FormerlyActiveMdiChild property. This is a private property that seems to be only used to update the window icon when an MDI child is deactivated. Below is the code originally used to update the icon:

    1. if ( this .FormerlyActiveMdiChild != null )
    2. {
    3.      this .FormerlyActiveMdiChild.UpdateWindowIcon( true );
    4.      this .FormerlyActiveMdiChild = null ;
    5. }

    It seems like Microsoft tried to fix a problem with the icon update when the deactivated form was actually closing, so in .NET Framework 2.0 SP1, the code now looks like this:

    1. if ( this .FormerlyActiveMdiChild != null &&
    2.      ! this .FormerlyActiveMdiChild.IsClosing )
    3. {
    4.      this .FormerlyActiveMdiChild.UpdateWindowIcon( true );
    5.      this .FormerlyActiveMdiChild = null ;
    6. }

    However, this causes the assignment “this.FormerlyActiveMdiChild = null” to be skipped and a reference is left to the closed (and possibly disposed) MDI form. This prevents it (and all its child instances) from being GCed. It would probably be more correct if the original code was changed to:

    1. if ( this .FormerlyActiveMdiChild != null )
    2. {
    3.      if ( ! this .FormerlyActiveMdiChild.IsClosing )
    4.        this .FormerlyActiveMdiChild.UpdateWindowIcon( true );
    5.      this .FormerlyActiveMdiChild = null ;
    6. }

    Note that this memory leak only causes a single form (and its child instances) to be kept in memory. If you open and close another form, the original form will become eligible for GC (i.e., the memory leak doesn’t grow over time). Nonetheless, it is preferable to make sure that all unused instances are correctly GCed. One workaround to this problem is to use reflection to set the private property “FormerlyActiveMdiChild” to null, for instance in the MdiChildActivate event in the MDI parent. Something like this:

    01. protected override void OnMdiChildActivate( EventArgs e )
    02. {
    03.    base .OnMdiChildActivate( e );
    04.    try
    05.    {
    06.      typeof ( Form ).InvokeMember( "FormerlyActiveMdiChild" ,
    07.        BindingFlags.Instance | BindingFlags.SetProperty |
    08.        BindingFlags.NonPublic, null ,
    09.        this , new object [] { null } );
    10.    }
    11.    catch ( Exception )
    12.    {
    13.      // Something went wrong. Maybe we don't have enough
    14.      // permissions to perform this or the
    15.      // "FormerlyActiveMdiChild" property no longer
    16.      // exists.
    17.    }
    18. }

    Most of the text in this post is copied from my reply to a forum question at http://memprofiler.com/forum/viewtopic.php?t=1160 . In the forum I said that the problem was introduced in .NET Framework 3.5. However, installing .NET Framework 3.5 will automatically install .NET Framework 2.0 SP1 and .NET Framework 3.0 SP1, and the memory leak exists in the .NET 2.0 assembly “System.Windows.Forms.dll”.

    Unfortunately, this problem affects the .NET Memory Profiler tutorials. When we get the time to update them, we will have to take this into consideration.

    In my next post I will make a comment on the single <GCHandle> instance that existed after the last snapshot when using the original .NET Framework 2.0.

    Friday, April 17, 2009 12:31 PM
  • Pls help me

    I found some related problem in the following link.

    http://www.scitech.se/blog/index.php/category/net-framework/

    Minor memory leak introduced in .NET Framework 2.0 SP1 Reply Reply

    Thursday, March 20th, 2008

    A while ago we received a support request from a customer that had a memory leak in his application. After showing, closing and disposing an MDI child form, the Form instance was still alive. The root path indicated that the child form instance was kept alive by the MDI parent, via the internal propertyStore field. I tried to reproduce the problem using an MDI application that was easily available: the Game of Life application used in the .NET Memory Profiler tutorials . And to my surprise the Game of Life application had a memory leak, even after the memory leak fix in the tutorial had been applied.

    After having collected the last snapshot in the second .NET Memory Profiler tutorial  (after closing the Game of Life MDI window), there should be no new instances of any type (since the memory leak should have been fixed). Thus if the type filter is set to only show types “With new or removed instances”, the Types list shold be empty. If the original version of .NET Framework 2.0 is used, this is almost true. A single new <GCHandle> instance will exist, but for now I will ignore this (it will be discussed in a future post).

    GameOfLife snapshot (without SP)

    However, testing the tutorial after having installed .NET Framework 2.0 SP1 shows completely different results (as can be seen in the picture below). Even though no additional instances have been created (Delta is 0), there are still a lot of New and Removed instances.

    GameOfLife snapshot (SP1)

    At the time of the last snapshot, no Game of Life windows are open, so I would expect all LifeForm instances to be GCed, but there’s still one new live instance left. So the new LifeForm instance is a good candidate for memory leak analysis. The details of the new LifeForm instance is shown in the picture below.

    LifeForm instance details

    The shown root path of the instance indicates that a reference to the LifeForm instance is stored in a PropertyStore. The PropertyStore class is used internally by WinForms to save space when storing property values. Instead of using instance fields, the dictionary-like PropertyStore is used. Anyway, after doing some digging around using Reflector, I came to the conclusion that the LifeForm instance was put into the PropertyStore using the Form.FormerlyActiveMdiChild property. This is a private property that seems to be only used to update the window icon when an MDI child is deactivated. Below is the code originally used to update the icon:

    1. if ( this .FormerlyActiveMdiChild != null )
    2. {
    3.      this .FormerlyActiveMdiChild.UpdateWindowIcon( true );
    4.      this .FormerlyActiveMdiChild = null ;
    5. }

    It seems like Microsoft tried to fix a problem with the icon update when the deactivated form was actually closing, so in .NET Framework 2.0 SP1, the code now looks like this:

    1. if ( this .FormerlyActiveMdiChild != null &&
    2.      ! this .FormerlyActiveMdiChild.IsClosing )
    3. {
    4.      this .FormerlyActiveMdiChild.UpdateWindowIcon( true );
    5.      this .FormerlyActiveMdiChild = null ;
    6. }

    However, this causes the assignment “this.FormerlyActiveMdiChild = null” to be skipped and a reference is left to the closed (and possibly disposed) MDI form. This prevents it (and all its child instances) from being GCed. It would probably be more correct if the original code was changed to:

    1. if ( this .FormerlyActiveMdiChild != null )
    2. {
    3.      if ( ! this .FormerlyActiveMdiChild.IsClosing )
    4.        this .FormerlyActiveMdiChild.UpdateWindowIcon( true );
    5.      this .FormerlyActiveMdiChild = null ;
    6. }

    Note that this memory leak only causes a single form (and its child instances) to be kept in memory. If you open and close another form, the original form will become eligible for GC (i.e., the memory leak doesn’t grow over time). Nonetheless, it is preferable to make sure that all unused instances are correctly GCed. One workaround to this problem is to use reflection to set the private property “FormerlyActiveMdiChild” to null, for instance in the MdiChildActivate event in the MDI parent. Something like this:

    01. protected override void OnMdiChildActivate( EventArgs e )
    02. {
    03.    base .OnMdiChildActivate( e );
    04.    try
    05.    {
    06.      typeof ( Form ).InvokeMember( "FormerlyActiveMdiChild" ,
    07.        BindingFlags.Instance | BindingFlags.SetProperty |
    08.        BindingFlags.NonPublic, null ,
    09.        this , new object [] { null } );
    10.    }
    11.    catch ( Exception )
    12.    {
    13.      // Something went wrong. Maybe we don't have enough
    14.      // permissions to perform this or the
    15.      // "FormerlyActiveMdiChild" property no longer
    16.      // exists.
    17.    }
    18. }

    Most of the text in this post is copied from my reply to a forum question at http://memprofiler.com/forum/viewtopic.php?t=1160 . In the forum I said that the problem was introduced in .NET Framework 3.5. However, installing .NET Framework 3.5 will automatically install .NET Framework 2.0 SP1 and .NET Framework 3.0 SP1, and the memory leak exists in the .NET 2.0 assembly “System.Windows.Forms.dll”.

    Unfortunately, this problem affects the .NET Memory Profiler tutorials. When we get the time to update them, we will have to take this into consideration.

    In my next post I will make a comment on the single <GCHandle> instance that existed after the last snapshot when using the original .NET Framework 2.0.

    Friday, April 17, 2009 12:31 PM