Error creating windows handle

This forum has migrated to Microsoft Q&A. Visit Microsoft Q&A to post new questions.

Answered by:

Question

An application is throwing a system error.

“System.ComponentModel.Win32Exception (0x80004005): Error creating window handle”

The exception happened when increase the application instance at the server level, we are using Windows server 2012 R2 Standard. The application team is requesting to increase the handles. Which registry property points to the application handle?

Answers

Share below information with application team. it may be helpful to fix.

• Proposed as answer by Teemo Tang Microsoft contingent staff Thursday, October 31, 2019 9:21 AM
• Marked as answer by Hamid Sadeghpour Saleh MVP Thursday, December 19, 2019 7:04 PM

All replies

Share below information with application team. it may be helpful to fix.

• Proposed as answer by Teemo Tang Microsoft contingent staff Thursday, October 31, 2019 9:21 AM
• Marked as answer by Hamid Sadeghpour Saleh MVP Thursday, December 19, 2019 7:04 PM

“Run Process Explorer or the Windows Task Manager to look at the GDI Objects, Handles, Threads and USER objects. Select those columns to be viewed (Task Manager choose View->Select Columns. Then run your app and take a look at those columns for that app and see if one of those is growing really large.

It might be that you’ve got UI components that you think are cleaned up but haven’t been Disposed”

“The windows handle limit for your application is 10,000 handles. You’re getting the error because your program is creating too many handles. You’ll need to find the memory leak. As other users have suggested, use a Memory Profiler.”

Winforms issue — Error creating window handle

Please Note: Since the website is not hosted by Microsoft, the link may change without notice. Microsoft does not guarantee the accuracy of this information.

Error Creating Window Handle (VB.NET)

I have a fairly large application written in VB.NET which seems to be suffering from a memory leak of one kind or another. Several times per day, I have instances of this application that crash (seemingly at random, but always after being used for almost a day). I’ve searched and read many forums and even questions asked here on Stack Overflow about this particular problem. What I’ve determined is that this is related to a memory leak and usually points to either the handles exceeding 10,000 or the objects exceeding the limit.

I’ve downloaded the memory pro filer and have used it to locate and fix several memory leaks in the program but that hasn’t seemed to slow down the daily crash count. My program uses a global error catcher to log these events and store information about them in the database. I’ve now got about 2 months worth of data but the error message doesn’t really help point me in any kind of direction. I’ve recently added the ability for this global error catcher to log the handles that the application has and so far it has been far below the 10,000 handle threshold. Usually it is under 1,000.

Long story short, my question is this. Is there some way to log the GDI object count so I can determine if that is causing my program to crash? Are there other ‘objects’ that might be causing the memory leak and crash besides these two and can I log those some how?

I’ve tried reading as much as I can and I just can’t get a good grasp on this so I appreciate any direction you can give me. It seems like these types of problems plague a lot of programs. Hopefully someone can help me and this can help others in the future.

A little more information about my program and environment. It mostly runs on Windows 7 64 bit machines (although some vista and XP machines are present), it is running on .NET 4.0 framework. The project consists of a few hundred forms, classes, and custom controls (built specifically for this project). I’m using .NET memory profiler 4.6 to check for memory leaks. I’ve run what I consider the most resource intensive operations on my computer for over an hour (opening and subsequently closing a lot of the screens, crunching gigs worth of data, etc. ) while watching the resources in the task manager (Handles, Threads, USER Objects, and GDI Objects) but none of them go over 1000.

Here is a copy of one of the logs from a crash event:

The only other though I had was that my global error catcher is crashing when it tries to load because it cannot create any more handles and I’m somehow losing that information. But the times when it isn’t crashing and it is able to log the handle count it is quite low (sub 1000). Is the garbage collector freeing up a lot of resources right after the crash before the program can log the high handle count? I’m just a little lost and confused about the data I have.

Winforms issue — Error creating window handle [duplicate]

We are seeing this error in a Winform application. Can anyone help on why you would see this error, and more importantly how to fix it or avoid it from happening.

10 Answers 10

Have you run Process Explorer or the Windows Task Manager to look at the GDI Objects, Handles, Threads and USER objects? If not, select those columns to be viewed (Task Manager choose View->Select Columns. Then run your app and take a look at those columns for that app and see if one of those is growing really large.

It might be that you’ve got UI components that you think are cleaned up but haven’t been Disposed.

Here’s a link about this that might be helpful.

The windows handle limit for your application is 10,000 handles. You’re getting the error because your program is creating too many handles. You’ll need to find the memory leak. As other users have suggested, use a Memory Profiler. I use the .Net Memory Profiler as well. Also, make sure you’re calling the dispose method on controls if you’re removing them from a form before the form closes (otherwise the controls won’t dispose). You’ll also have to make sure that there are no events registered with the control. I myself have the same issue, and despite what I already know, I still have some memory leaks that continue to elude me..

See this post of mine about «Error creating window handle» and how it relates to USER Objects and the Desktop Heap. I provide some solutions.

This problem is almost always related to the GDI Object count, User Object count or Handle count and usually not because of an out-of-memory condition on your machine.

When I am tracking one of these bugs, I open ProcessExplorer and watch these columns: Handles, Threads, GDI Objects, USER Objects, Private Bytes, Virtual Size and Working Set.

(In my experience, the problem is usually an object leak due to an event handler holding the object and preventing it from being disposed.)

Well, in my case it was definitely the USER Objects that were out of control. I looked in the Windows Task Manager and sure enough, the USER Objects count was at 10’000 exactly.

I am dynamically embedding property and list sheets in Tab Pages by setting the Parent property of the property or list sheet’s container panel to that of the Tab Page. I am conditionally recycling or re-creating the property and list sheet forms depending on the type of collection being listed or class type of the object being inspected.

NB: In Delphi, all controls had an Owner and a Parent property. Even if one changed the Parent property of a control, it would still be disposed by its owner when the owning control got destroyed.

Error creating windows handle

This forum has migrated to Microsoft Q&A. Visit Microsoft Q&A to post new questions.

Answered by:

Question

What can cause an exception stating «Error Creating Window Handle»? I get this exception all the time:

System.ComponentModel.Win32Exception: Error creating window handle.

at System.Windows.Forms.NativeWindow.CreateHandle(CreateParams cp)

Answers

All replies

Unfortuneatly, in my app, it’s a very common problem. It occurs about 10 times per day with 10-15 users working in it all day. I have a feeling it’s being caused by the datagrid just because I’ve experienced so many other problems with the datagrid, but with the stack trace I’m recieving I just don’t know where to start. It’s a big problem because maybe %10 of the time, it actually shuts down the application and the users lose their work.

Actually, so far today, the two different versions of the exception (one that recovers and one that crashes the app) have already occurred 17 times.

The meaning being that I wouldn’t quite consider that uncommon. No need for the attitude. Remember it was your choice to respond, and I do appreciate your help today.

People seem to ignore posts with stack traces. A couple of them can be seen here:

Here is the most problematic exception that crashes the application:

Exception = Compass.App.CompassException: Unhandled Exception. —> System.ComponentModel.Win32Exception: Error creating window handle.

at System.Windows.Forms.NativeWindow.CreateHandle(CreateParams cp)

at System.Windows.Forms.ThreadExceptionDialog..ctor(Exception t)

at System.Windows.Forms.Application.ThreadContext.OnThreadException(Exception t)

at System.Windows.Forms.Control.WndProcException(Exception e)

at System.Windows.Forms.Control.ControlNativeWindow.OnThreadException(Exception e)

at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

at System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG& msg)

at System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(Int32 dwComponentID, Int32 reason, Int32 pvLoopData)

at System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(Int32 reason, ApplicationContext context)

at System.Windows.Forms.Application.ThreadContext.RunMessageLoop(Int32 reason, ApplicationContext context)

at System.Windows.Forms.Application.Run(Form mainForm)

— End of inner exception stack trace —

Thanks. I’ll post with updates.

I was finally able to re-produce the error. I was running in debug so I was able to find this inner exception:

The current process has used all of its system allowance of handles for Window Manager objects

The application has a list of items on the top half that can be opened in a tab view on the bottom half. The tab pages that open are user controls with a menu down the left that opens different user controls on the right. Currently, the user controls are loaded with the tab page instead of being loaded dynamically when a menu item is clicked so my first move will be to load those views dynamically. Anyone know what the handle limit is?

So a single application can never contain more than 10,000 controls at one time because each control is assigned it’s own handle right?

I am running into this problem as well for a different type of application. However, after reading through this article and seeing the magic «10,000» control limit, I recall this being a problem for me about five years ago with another application. The problem is because (I think) GDI can only manage 65,535 GDI objects, which was established with Windows 3.0 (or 3.11, but does it really matter). My users mostly use Windows XP (in 2011) but some of them use Windows Vista/7.

After a bit of research and digging, it seems to me that this is a problem with GDI and is, therefore, most likely still a problem with modern versions of Windows (Vista, 7.) The semi-good news is that there is a fix for it. Navigate to the following registry key:

The value defaults to 10,000 but the value can range from 256 to 65536. This is obviously a 16 bit value which hints at the fact that Microsoft has probably never updated the underlying GDI library since Windows NT. Maxing the value of this key should help most users. The obvious problems associated with this «fix» is that this involves hacking the registry and that this has to be done for each user’s PC. This means that the fix is not a fix for most of us, but a bug that we have to live with.

As mentioned, this is a problem for me and it’s March, 2011. This has been a problem for a very long time. It would be nice to see the underlying GDI API updated to allow for a 32-bit limitation and an increase of the default registry value from 10,000 to some larger value. Even if updating the GDI library isn’t going to happen, MS could at least issue a patch that could at a minimum update the registry value. FYI, I also just checked my test Windows 7 machine— the key value is 10k on it as well.