Not enough memory or not enough handles?

I am working on a large scale project where a custom (pretty good and robust) framework has been provided and we have to use that for showing up forms and views.

There is abstract class StrategyEditor (derived from some class in framework) which is instantiated whenever a new StrategyForm 开发者_高级运维is opened.

StrategyForm (a customized window frame) contains StrategyEditor.

StrategyEditor contains StrategyTab.

StrategyTab contains StrategyCanvas.

This is a small portion of the big classes to clarify that there are many objects that will be created if one StrategyForm object is allocated in memory at run-time. My component owns all these classes mentioned above except StrategyForm whose code is not in my control.

Now, at run-time, user opens up many strategy objects (which trigger creation of new StrategyForm object.) After creating approx. 44 strategy objects, we see that the USER OBJECT HANDLES (I'll use UOH from here onwards) created by the application reaches to about 20k+, while in registry the default amount for handles is 10k. Read more about User Objects here. Testing on different machines made it clear that the number of strategy objects opened is different for message to pop-up - on one m/c if it is 44, then it can be 40 on another.

When we see the message pop-up, it means that the application is going to respond slowly. It gets worse with few more objects and then creation of window frames and subsequent objects fail.

We first thought that it was not-enough-memory issue. But then reading more about new in C# helped in understanding that an exception would be thrown if app ran out of memory. This is not a memory issue then, I feel (task manager also showed 1.5GB+ available memory.)

M/C specs

Core 2 Duo 2GHz+

4GB RAM

80GB+ free disk space for page file

Virtual Memory set: 4000 - 6000

My questions

Q1. Does this look like a memory issue and I am wrong that it is not?

Q2. Does this point to exhaustion of free UOHs (as I'm thinking) and which is resulting in failure of creation of window handles?

Q3. How can we avoid loading up of an StrategyEditor object (beyond a threshold, keeping an eye on the current usage of UOHs)? (we already know how to fetch number of UOHs in use, so don't go there.) Keep in mind that the call to new StrategyForm() is outside the control of my component.

Q4. I am bit confused - what are Handles to user objects exactly? Is MSDN talking about any object that we create or only some specific objects like window handles, cursor handles, icon handles?

Q5. What exactly causes to use up a UOH? (almost same as Q4)

I would be really thankful to anyone who can give me some knowledgeable answers. Thanks much! :)

[Update]

Based on Stakx answer, please note that the windows that are being opened, will be closed by the user only. This is kind of MDI app situation where way too many children windows are opened. So, Dispose can not be called whenever we want.

Q1

Sounds like you're trying to create far too many UI controls at the same time. Even if there's memory left, you're running out of handles. See below for a brief, but fairly technical explanation.

Q4

I understand a user object to be any object that is part of the GUI. At least until Windows XP, the Windows UI API resided in USER.DLL (one of the core DLLs making up Windows). Basically, the UI is made up of "windows". All controls, such as buttons, textboxes, checkboxes, are internally the same thing, namely "windows". To create them, you'd call the Win32 API function CreateWindow. That function would then return a handle to the created "window" (UI element, or "user object").

So I assume that a user object handle is a handle as returned by this function. (Winforms is based on the old Win32 API and would therefore use the CreateWindow function.)

Q2

Indeed you cannot create as many UI controls as you want. All those handles retrieved through CreateWindow must at some point be freed. In Winforms, the easiest and safest way to do this is through the use of the using block or by calling Dispose:

using (MyForm form = new MyForm())
{
    if (form.ShowDialog() == DialogResult.OK) ...
}    

Basically, all System.Windows.Forms.Control can be Disposed, and should be disposed. Sometimes, that's done for you automatically, but you shouldn't rely on it. Always Dispose your UI controls when you no longer need them.

Note on Dispose for modal & modeless forms:

• Modal forms (shown with ShowDialog) are not automatically disposed. You have to do that yourself, as demonstrated in the code example above.
• Modeless forms (shown with Show) are automatically disposed for you, since you have no control over when it will be closed by the user. No need to explicitly call Dispose!

Q5

Everytime you create a UI object, Winforms internally makes calls to CreateWindow. That's how handles are allocated. And they're not freed until a corresponding call to DestroyWindow is made. In Winforms, that call is triggered through the Dispose method of any System.Windows.Forms.Control. (Note: While I'm farily certain about this, I'm actually guessing a little. I may not be 100% correct. Having a look at Winforms internals using Reflector would reveal the truth.)

Q3

Assuming that your StrategyEditor creates a massive bunch of UI controls, I don't think you can do a lot. If you can't simplify that control (with respect to the number of child controls it creates), then it seems you're stuck in the situation where you are. You simply can't create infinitely many UI controls.

You could, however, keep track of how many StrategyEditors are opened at any one time (increase a counter whenever one is instantiated, and decrease it whenever one is closed -- you can track the latter using the FormClosing/FormClosed event of a form, or in the Dispose method of a control). Then you could limit the number of simultaneously opened StrategyEditors to a fixed number, say 5. If the limit is exceeded, you could throw an exception in the constructor, so that no more instances are created. Of course I can't say whether StrategyForm is going to handle an exception from your StrategyEditor constructor well...

public class StrategyEditor : ...
{
    public StrategyEditor()
    {
        InitializeComponent();

        if (numberOfLiveInstances >= maximumAllowedLiveInstances)
            throw ...;
        // not a nice solution IMHO, but if you've no other choice...
    }
}

In either case, limiting the number of instantiated StrategyEditors seems like a temporary fix to me and won't solve the real problem.