alexandria122
asked on
.NET form re-open memory leak
I have a VB.NET program (3.0) that opens a very heavily populated form with the click of a button. The form has 7 tab pages with hundreds of controls. The first time I open the form, my memory usage jumps 180 MB - which is fine, except when I close the form, my memory usage never goes down. Every time I re-open the form by clicking the button, my memory usage jumps another 70 MB. We've had complaints from users using this program that they are getting Out Of Memory errors after clicking the button about 10 times.
To test .NET handling of large forms, I created a dummy Windows programs with 1 form with a single button on it that opens another form with 7 tab pages and hundreds of controls (there is no code-behind, therefore no extra baggage involved - just .NET objects). The first time I clicked the button, the process memory jumped 22 MB (60 MB total). I closed the form, set the object to Nothing in code and forced GC.Collect(). Still 60 MB. Clicked the button repeatedly and repeatedly closed the form. After about 7 clicks, I was at 92 MB and no sign of it going down.
Is this something that anybody ever ran into? How can I force .NET to let go of a form out of memory once it's been closed? I don't care about re-load time.
And if .NET does keep form controls in memory for speed, why does memory usage continue going up in increments as I click the "New form" button with no end in sight?
To test .NET handling of large forms, I created a dummy Windows programs with 1 form with a single button on it that opens another form with 7 tab pages and hundreds of controls (there is no code-behind, therefore no extra baggage involved - just .NET objects). The first time I clicked the button, the process memory jumped 22 MB (60 MB total). I closed the form, set the object to Nothing in code and forced GC.Collect(). Still 60 MB. Clicked the button repeatedly and repeatedly closed the form. After about 7 clicks, I was at 92 MB and no sign of it going down.
Is this something that anybody ever ran into? How can I force .NET to let go of a form out of memory once it's been closed? I don't care about re-load time.
And if .NET does keep form controls in memory for speed, why does memory usage continue going up in increments as I click the "New form" button with no end in sight?
Can you upload the TEST project so we can test it?
(try zipping it all up and adding .txt to the end so it doesn't get rejected)
(try zipping it all up and adding .txt to the end so it doesn't get rejected)
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Can't tell from the simplified example, but you should consider using a NEW instance of the form each time you need it as the "default instance" (accessed simply by using the forms name without using the "New" keyword) has different behavior than that of a instantiated form.
You can leverage the "Using" keyword to make sure the object is disposed automatically:
Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
Using frm As New FormXXX
frm.ShowDialog()
End Using
' is this overkill?
GC.Collect()
GC.WaitForPendingFinalizer
End Sub
Using Statement:
http://msdn.microsoft.com/en-us/library/htd05whh.aspx
"However, you can still use a Using block to force the disposal of a managed resource instead of waiting for the garbage collector."
You can leverage the "Using" keyword to make sure the object is disposed automatically:
Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
Using frm As New FormXXX
frm.ShowDialog()
End Using
' is this overkill?
GC.Collect()
GC.WaitForPendingFinalizer
End Sub
Using Statement:
http://msdn.microsoft.com/en-us/library/htd05whh.aspx
"However, you can still use a Using block to force the disposal of a managed resource instead of waiting for the garbage collector."
ASKER
Eventually figured it out.
http://msdn.microsoft.com/en-us/magazine/cc188782.aspx