Memory Leak

dbetting

Can someone give me a suggestion? I've tried several different methods of creating this form and destroying it when I am done, all with the same results. This seems to be the cleanest and easiest method to use but it still does not give a good result. using (frmContainer FrmMP = new frmContainer(null, TFormList.MasterParts, -1)) { FrmMP.SetSalesOrderInfo(SelectedOrderNumber, SelectedReferenceNumber); FrmMP.ShowInTaskbar = false; FrmMP.StartPosition = FormStartPosition.CenterParent; FrmMP.ShowDialog(); } Upon opening this window, I've added 3K to my memory. Wouldn't be a problem except it gets called several times per hour. For some people this is 100K per hour. The only way I've been able to actually get the memory collected is by minimizing and then resuming the program. Not very convenient for the user and they don't know when they need to go through that ritual (nor should they). I've tried several different calls to do garbage collection (even though it is not recommended) but these didn't work either. A session will usually start at about 10K. When it hits a couple hundred K, I can minimize and restore the pgm and it is usually back down to 15-20K. If I do not minimize, it just continues to grow. Any suggestions?

Steve Maier

I have seen this behavior with just about any Windows program. VS6 was pretty bad, Word, Lotus Notes, and many others. You could try to set your FrmMP = null; I have seen others do that where they were trying to reclaim memory. Steve Maier, MCSD MCAD

S Senthil Kumar

Where did you see your memory consumption? In the Task Manager? It's a bad idea to use Task Manager to find the memory used by managed applications. Task Manager reports the total memory consumed by an application. For managed applications, the Garbage Collector manages the heap and it acquires and releases memory from the OS whenever it wants to. In your case, it decided not to release it back, but it eventually will. You can use this[^] to peer into your GC heap, if you're really sure it never releases it back, even when the system runs out of virtual memory. Or you can use perfmon, with # Bytes in all heaps. When you minimize your application, all you are doing is minimizing the working set of your process, ie, the pages that are currently in physical memory for the process. It doesn't mean that the application is now consuming lesser memory. If you look into the VM Size column, you'll see that it doesn't change when you minimize or maximize your application. Regards Senthil _____________________________ My Blog | My Articles | WinMacro

Dave Kreskowiak

Whenever you use .ShowDialog(), you MUST call .Dispose() on that form object when your done with it. Form.ShowDialog()[^] docs. [EDIT] Whoops! Didn't see the using statement you had in there... RageInTheMachine9532 "...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome

Dan Neely

Something that's not clear from the msdn docs. Will the GC eventually finalize the dialog and reclaim the memory in the indefinite future, or is it as permanantly lost as in unmanaged code.

Dave Kreskowiak

It's not really the memory that's the problem, but the unmanaged handle-based resources that the form holds onto. If used frequently enough, and not freed by explicitly calling .Dispose(), they can be exhausted, causing an "Out of memory" exception, even though memory is not what you ran out of. The GC doesn't track handle usage, and so, can't tell when the system is running low. If the GC can't tell this, it can't speed up Disposing and Finalizing the objects it's supposed to collect. RageInTheMachine9532 "...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome