What programming practices affect the number of window handles?

Question

I'm getting the runtime error "Error creating window handle". From my research, I know this error typically indicates that an application has exceeded Windows' 10,000 handle limit, and I should address the error by making sure handles aren't created unnecessarily and are disposed of properly.

However, I can't find any documentation on what causes a window handle to be created. Is a window handle created each time I instantiate a form? Each time I instantiate a control? Each time I instantiate a class? Or what?

Would it be true to say that for light-UI applications, there is no need to be particularly concerned with the number of handles used, but for applications with many graphical elements, programmers must take measures to limit the number of window handles? Is that what "windowless controls" and "lightweight controls" are all about? Are there other relevant concepts I should know about?

Up to now, I haven't thought of my application as particularly UI-intensive. However, it does display a grid of charts, where each chart is a user control composed of several component controls. For large analyses, the total number of controls might reach into the thousands. Assuming I want to retain this grid, are there specific techniques I can apply to keep the handle count down? For instance, is there a way to "render" a control so that it is still visible, but no longer requires a window handle?

-TC

Answer 1

However, I can't find any documentation on what causes a window handle to be created.

That's probably because .net is an abstraction.

In the "real" world of Win32, a window handle is denoted by the type HWND and is given to almost everything. Every button, menu and so on can have a HWND.

Actually, that's not quite true. Every class (in the C Windows API) of object you can create has a handle. Each class usually only draws the entire control - however, some controls may draw more complicated controls, such as extra buttons. Either they can create another window (control) or they can just draw it using say GDI.

So, not everything you see generates a HWND - but most things do.

Intriguingly, you might like to know that to create a control in C/Win32 you use CreateWindow(). Everything is a Window.

So now back to your .net APP. If the controls you are relying on create a lot of objects via their underlying CreateWindow calls, you're going to issue a lot of HWND variables and eventually run out of unique identifiers.

Mark Russinovich covers the practical limits in his pushing the limits of Windows, where he deliberately attempts to exhaust the allocation for his application.

So what programming practices cause this? Creating too many Window objects. This might not correspond to actual Windows in the sense of application windows - rather it corresponds to the amount of controls. The only way to avoid this is to use less, or if a third party is causing the issue design your application based on the practical limits of what you can display at a time.

An alternative would be to produce your own control which, rather than using sub-controls, draws them instead. This can, however, be a lot of work.

Answer 2

In short, window handle is given to every UI element that is interactive. Every real window, every textbox, grid cell, button, menu and so on. Although non-interactive controls do not require window handles they might still use them if they were not written properly.

Normally it is very difficult to reach window handles limit. If this is happening and your app is not particularly UI intensive this usually means you are leaking handles. This can happen if you use badly written library of visual components that is not releasing resources when it should. Window handle is an unmanaged resource and care must be taken to release it when no more needed. If you happen to use a library and observe handles leaking, best is to change library. It is usually harder than it sounds so as a bad workaround you can try to force garbage collector to collect objects and hope that all unmanaged resources are freed in finalizers/destructors.

GC.Collect();

There is no guarantee this will help because if controls you are using are badly written they might not release handles even in their finalizers. Again, this is bad practice but might be helpful if you have no other choice.

If you use only standard .NET controls make sure that you Close() every form after use and not just hide it. This will dispose a non-dialog form and all its controls and if they are standard controls there will be no leaking. Dialog forms need to be disposed in code. Detailed documentation is here.