Error creating window handle before window loads

Question

I have a large windows forms program with a lot of controls. The first window I see when I run it is the Login screen, it only has a combobox, button, textbox and a few labels. When I press the button it loads Form1. Form1, on load automatically creates an instance of Game, which it minimizes and embeds Game into Form1 using this code:

Game.Location = new Point(146, 6);
Game.TopLevel = false;
Game.Visible = true;
Game.BringToFront();
Game.FormBorderStyle = FormBorderStyle.None;
Controls.Add(Game);

I get the

"Error creating window handle"

error on this line (for some reason it's not on the window create line):

this.timer.Interval = 10;

Please help, others have said that this is to do with too many windows, but there I've tried deleting windows in project and I get the same error.

Answer 1

This question appears to already be answered: Error creating window handle

You're getting the error because your program is creating too many handles. The windows handle limit for your application is 10,000 handles. You'll need to find the memory leak.

Make sure you are calling Dispose() on forms after you close them and are done, or declare the Form inside using clauses:

using(Form mainForm = new Form())
{
    mainForm.Show();
}

Process Explorer or the Windows Task Manager allows you to look at the GDI Objects, Handles, Threads and USER objects. You will have to do to the details tab and select those columns to be viewed (Right click on columns->Select Columns). Look for a large number of GDI Objects to confirm the windows handle limit is indeed the problem.

Are you disposing the login form? You mention you have a-lot of controls, any way you can limit those, such as using a label and an array of text to display something instead of a bunch of labels or a grid of textboxes or the like.

An example of a memory profiler you could use would be the .Net Memory Profiler.

(Update 3/30/16)

Revising the information you have provided me, three things have occurred to me:

1. Unregistering events

   If you are dynamically creating and then removing Controls on your forms, you must ensure to unregister any event handlers from every event you have previously registered with this control. If you don't, the event handler will hold a reference to the control and be prevented from being eligible for garbage collection (along with the GDI/USER objects), even if you call Dispose! They will remain held until you Dispose the parent Form.

2. Timer (and other, not-UI) events

   The code in the Timer's tick event handler method (and any its calls) will be running on a separate thread that IS NOT the UI thread. If you need to access ANY of the UI properties, members, or methods, you must switch the thread context back to the UI thread, or else this can raise all kinds of funky exceptions. Also, if your creating UI objects (Controls) from a non UI thread, it creates MORE GUI/USER handles where it otherwise might have not. You do this by calling the Form's or Control's Invoke method and do your UI manipulation inside an anonymous method or pass its a delegate to the UI manipulation code. If you also call that method directly from any UI object, you might want to check Control.InvokeRequired to avoid the costly Invoke method which uses locks.

3. AppDomain.FirstChanceException

   If all else fails, and you still don't know why you are getting the exception, heres a clever little trick that I have used to find VERY obscure or difficult-to-find bugs: Register an event handler with the AppDomain.FirstChanceException event, and put a breakpoint in the handler's method body. That way, the very next time an Exception is thrown, your code will get 'first chance' to handle it, and you will hit that breakpoint in the FirstChanceException handler method I just mentioned. From here, you can open up the call stack window and see the stack trace from where the exception is being thrown. This includes exceptions that are originating from native or .net APIs. Normally, this information is hidden from you, because the call stack get cleared before handing off the exception to your code, where you catch it.

Answer 2

Just wanted to share that I got this error right at the start of our Desktop app, directly when loading the very first Form on startup. It turned out someone had configured compatibility mode 'Windows 95' on the startup executable. This appearently results in the exact same 'Error creating window handle'. Setting compatibility on the .exe remains, even after deploying a new .exe. I just hope that sharing this prevents others from wasting as much time as I did.