Leaking window handles

[Mike B]

I've got a forms engine-type app that's very control intensive, and
after it runs long enough it gets the "can't create windows handle"
message. I don't seem to be able to track down whatever it is I'm not
disposing, and have been looking into resource tracker type programs
to help me narrow it down. I sure miss the early CNet days, it's spam
city out there now. Can anyone recommend a good util, free, share, or
$? I'm trying out SciTech's Memory Profiler now, it does report hwnds
but really wants to give you too much info, takes almost a minute to
gather its snapshot - I could really use something a lot quicker &
more resource-specific.

I've read a few other threads here and am willing to try out the
WMI/Systems.Diagnostics approach & roll my own, but this isn't a
terribly well-documented part of VB, any pointers there would be
greatly appreciated.

Also - just out of curiosity, I'm not proposing to "fix" it this way -
does anyone know if the handle limit is a static per-process limit, or
if it's tied to the SharedSection param in the Windows value of
\System\CurrentControlSet\Control\Session Manager\SubSystems?
According to MS, 512k allows 2500 windows, so the default value of
3072 should allow 15,000 windows? Exceeding that limit is supposed to
return an "out of memory" error, so does that mean that there are two
independant limits governing handles, or am I just all mixed up here?

Thanks,
Mike B

 

[camainc]

Mike,

What OS is this running on? What language is it written in?

I don't know if this is the same issue we ran into, but we had a
similar issue with a Windows Forms memory leak.

Every time a form was created or shown new GDI objects were being
created, but they were never being destroyed. After a while the GDI
objects were consuming all available memory and our application had to
be restarted. We tracked down the issue to a bug that was fixed with
XP SP2. The KB article that described our problem is:

http://support.microsoft.com/kb/319740

Chuck

 

[Mike B]

Sorry, that's VB.NET 2005 on XP Pro SP2, so I have SP2 and not MFC.

The GDI aspect is interesting though, because this is the first time
I've really played with it. I have a lot of tabs, buttons, etc on
which I use gradient brushes for 3d & shadow effects (so of course I
have to draw the text myself as well, etc) Lots of graphics, pens,
and brushes floating around... That's the one thing I was able to be
pretty thorough with though, just hunted for every create statement &
made sure I had a dispose in the execution path.

What's odd after reading that KB though, is that I do seem to have
some actions that use graphics objects but do not create any
additional controls, in which I know I'm disposing everything, yet
still show slight hwnd count increases. It just takes so long to get
the counts from Memory Profiler that I haven't tried to drill down
into that yet.

Makes one wonder if that issue is truly fixed, and if it's MFC only
(do managed code & MFC GDI calls end up at the same API routines?)
Think I'll drop some of my graphics code into it's own little app &
loop the create/dispose cycle, see if anything bursts into flames...

 

[CodeMonkey]

I use Memory Profiler from SciTech to track this kind of stuff down. It
can be hard to find, but since they give you a lot of information,
mostly what you don't need, you have the ability to just find it by
digging around.

I had a case where I was not disposing of a pen and a brush in one draw
event. What I didn't realize was that event was getting called hundreds
of times... Make sure that anywhere you create a new object, you also
dispose of this object when you are done.

Still though, your best bet is going to be a tool like Memory Profiler.