views:

20

answers:

2

Hi Guys,

I hope someone may be able to help!

We have a pretty large VB.Net MDI application that has been converted from VB6. When it is first run up with no MDIChild forms opened it uses about 35,000K. As more and more forms are opened (but not closed) the memory usage (according to Task Manager) creeps up at approximately 4,000K per form. (I am aware that T.M. only shows allocated memory for the application, and not the actual memory used.)

The issue is that when the allocated memory reaches a certain point, which is different depending upon what the available memory is on the target machine, no more forms can be opened until one or more of the open forms are closed. The "limit" of the ammount of forms that can be opened seems to depend upon the available memory of the machine.

For example: - On a virtual machine with only 512M for the whole machine it appears to be about 7-8 forms and the allocated memory is around 80,000K when this happens. - On our terminal server machine which has 3GB and is also running various other thirsty applications it stops at around 20+ forms and a memory allocation of about 100,000 - 105,000K.

I have tried using perfmon to see if there is a leak and that is indicating steady usage.

However, even if I close the forms the allocated memory only drops by about 3000K for the first form closed and then 100K for each form closed after. If I then add a few more forms the memeory increases, and if I then close some the same -3000K, -100K meomry reduction pattern happens again.

Has any one come accross this before? Can any one please help as this is looking like a bit of a show stopper! I look forward to your replies.

Incidentally the original VB6 version does not have this issue and also will return it's memory allocation to that it started with if you close each form rather than the allocation gradually creeping up because teh app releases less than it is allocated.

EDIT: I have just managed to get the same error while in dev. It appears that a WIN32Exception is being thrown in a UserControl. The error is "Error creating window handle."

Thanks and kind regards, Duane.

A: 

Your app is simply consuming the quota of handles that Windows imposes. By default it is 10,000 handles, trying to create another window will fail with "Error creating window handle".

Maybe those limits are lower for a VM or TS install, not sure. The upper limit is rather enormous and you should never have any trouble staying far away from it. In Task Manager, use View + Select Columns and tick USER objects, GDI object and Handles. Any of these columns growing without bound is a sure sign of a bug in your code, like not disposing forms or controls. Consuming more memory is a side-effect of this leak.

Hans Passant
Thank you Hans.You are correct, it is the USER object count. It hits 9,999 then the application bombs.Regards,Duane.
Dib
The next issue is to find out why there are so many "USER Objects"!
Dib
I can't see your code from here, but using Controls.Clear() or Controls.Remove() without calling Dispose() on the controls you removed explicitly causes this problem.
Hans Passant
Thanks Hans, that worked a treat.
Dib
Please don't hesitate to vote on helpful answers. You have enough rep.
Hans Passant
A: 

It turns out that we needed to explicitly Dispose of each individual control in our custom UserControls before the USER Objects would be released.

Dib