| Date: | July 18, 2007 / year-entry #260 |
| Tags: | history |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20070718-00/?p=25963 |
| Comments: | 37 |
| Summary: | If your program runs haywire, you will find that it manages to create about 10,000 window manager objects and then the system won't let it have any more. Why stop at 10,000? The first answer is "If you have to ask, you're probably doing something wrong." Programs shouldn't be creating anywhere near ten thousands window... |
If your program runs haywire, you will find that it manages to create about 10,000 window manager objects and then the system won't let it have any more. Why stop at 10,000? The first answer is "If you have to ask, you're probably doing something wrong." Programs shouldn't be creating anywhere near ten thousands window manager objects in the first place. Furthermore, as we saw last time, the maximum number of window manager objects that can be created is around 32,700. Giving a program 10,000 is already a third of the total amount available. That's already pretty darned generous, if you ask me. Preventing a program from running away and consuming all of the window manager objects is an attempt to contain the damage caused by a runaway program. Even if a program goes haywire, there's still around 20,000 objects available for the other programs to use. One of them might even be Task Manager, which the user fired up in order to kill the runaway program. |
Comments (37)
Comments are closed. |
640K should be enough for anyone!
I know this is totally off topic, but shouldn’t be the task manager run under special priority like CTRL ALT DEL signal does? I mean bypassing even any pending completion ports request by the shell?. (It happens to be a question I’ve always made to myself)
I just tried and I could only create 9,998 objects. I am being cheated.
Why 10000? Why not a nice round number like 8192 or 16384?
John: …ages to create <b>about</b> 10,000 window manager objects and the…
I think with that response you’ve passed the Turing test. Congratulations!
10,000 is a lot, but a lot less than you think.
Especially when you consider that the most pervasive abstraction in Windows is the window itself. Every button, textbox, label, checkbox, etc. are all windows.
Like this page alone consumes at least 8 windows, that I can spot offhand. Let’s ignore the fact that I’m running Firefox and have multiple tabs open, where each tab is also probably a window. The address bar, the menus, the toolbars, the buttons in the toolbars, the google search bar, all windows.
Juan: a process will, by design, never get stuck during termination. The only part that might be subject to indefinite delays is waiting for all pending I/O to complete, and even that has a timeout. Of course, the process might still get stuck for an unseen side effect of termination… the most common being a deadlocked KernelMode wait (UserMode waits are interrupted automatically by termination, but being in an UserMode wait marks the kernel-mode stack as pageable, so to make things simpler everyone uses KernelMode waits…). I believe Windows Vista and later fix the most common cases of processes stuck during termination, but I have not really tried
Adam: http://www.wired.com/politics/law/news/1997/01/1484
BA: as I see it, Microsoft should just document their windowless controls library (DirectUI) already… it’s the one used to render forms (entire pages?) in Internet Explorer, or the Task Pane in Explorer, or the Install or Remove Applications window in the control panel – check it out: the whole window with all the customized widgets takes exactly one HWND (I believe it started out as a HTA, and was ported to DirectUI for Windows XP)
BA: Ah, but you’re wrong! Open DOM Inspector and inspect a Mozilla Firefox window. It’s not windows, it’s HTML!
You can use a program like Spy++ (Included with some versions of Visual C++) to look at all the windows currently open to see what is a window and what isn’t.
WndList also has this basic functionality: http://www.bttsoftware.co.uk/wndlist.html
I’ve worked with applications that created tons and tons of windows. For example, the build their own "Property inspector" where each element was a different window. For each value, the left side was a static control, the right side was an edit control with up to three different buttons.
The thing was DOG SLOW.
I wrote a new one using a single listbox and dynamically created edit controls on selection and it was VERY FAST. They were shocked that my control could handle 10,000 values without an issue (a count that the old version would need to create 50,000 windows).
Even if creating 10,000 windows might "work" from a user’s perspective, the performance issues to the computer would probably drive it insane.
Pardon my ignorance, but how does the ~32,700 window limit apply to Terminal Server sessions and/or Citrix?
If 100 simulatenous users create 400 windows each, what happens?
Or is that 32,700 windows per virtual desktop?
I’ve run xwininfo on Linux with a number of apps open and the highest number of X windows I’ve seen is in the 3000 range. That’s shared amongst all applications. The major toolkits use X windows for any widget that can receive events, so even with all the buttons and stuff, there’s still only 3000 or so X windows. No application should need 10,000 window handles.
Dan: Well I knew that IE created windowless controls for a page’s content, I wasn’t sure if Firefox did or not (and true Firefox’s browser UI is rendered using XUL).
However, the point still stands that more windows are created by an application than are actually realized.
And I have used Spy++ (from both VS6.0 and VS2005 Standard Edition). Point it at some third party apps, you’ll see more windows than you expect.
Just want to mention that buttons on a toolbar are not windows (as have HWND), they are simple data objects based on RECT structure.
When you talk about "window manager objects", are these the same thing as "GDI Objects" in Task Manager?
Ralf: Look up "Window Stations" and "Desktops" on MSDN. To put it very simply, each terminal server session has it’s own limit of 32768 handles.
Window manager objects are User objects and drawing objects like pens/bitmaps/paths/etc are GDI objects, or so I always thought.
In some software it really is necessary to have more than 10,000 controls/windows. Music-studio software like Propellerheads Reason, Orion, UltranoSoft Dreamer, Project5, etc. There we go around it all by making virtual-windows and draw it all with DIBs, basic GDI, or Direct3D.
A similar approach is used in browsers.
True, if a program *designed for Windows* tries to create 10,000 window handles, then it probably is poorly designed. And it’s cool that Windows puts some reasonable artificial limits in place to stop runaway programs before they cripple the system.
But Windows has these limits for historical reasons. When resources were tight, it made sense to have very flat window hierarchies with relatively smart controls that encapsulated lots of complex behavior. Programs built for Windows generally have to follow that model.
But suppose windows were cheap, lightweight objects. Further suppose they could be combined in interesting ways. You could imagine a world where it does make sense to create tens of thousands of them in deep hierarchies which layer on complex behavior with incredible generality. It would be a very powerful system. (I believe WPF/XAML goes in this direction.)
I’m not knocking Windows, or this limit, or Raymond’s advice. I’m just pointing out that, while it’s insane for a program to want to create zillions of Windows windows, it doesn’t necessarily mean that all designs which involve creating lots of objects are bad. I think programmers sometimes get into that mindset, and it precludes elegant designs.
The thing that drove this home for me was the original _Design Patterns_ book, which describes a document editor that treats every single glyph as an object, and each of those has much of the functionality of a window. I was flabbergasted at first. But by keeping glyphs simple and by combining them with composition and decoration, they produce an elegant, extensible, and efficient design.
I was surprised that the .NET Framework was still using old fashioned window handles underneath.
How much kernel memory is used by each barebones traditional window object?
Out of curiosity I’d love to see the doco for whatever Office uses (or used) to do its dialogs — I’ve been intrigued by its low-handle approach since Windows 3 (uh… Winword 1.1 or something). Me, I just use as many handles as I need these days. Greedy.
As for tools, Winspector is my Spy++ replacement of choice.
Sorry to double post, but we’ve been here before..
http://blogs.msdn.com/oldnewthing/archive/2005/02/11/371042.aspx#371157
You get around the 32K window limit in Terminal Server because these objects seem to be stored in "Session Space," which is a piece of Kernel-mode memory that is mapped into every process in a given session.
I’m curious about whether someone ever considered making a set of preallocated handles for taskmgr (perhaps controlled by a SYSTEM-level regkey with application – quota pairs) that could be deployed when GDI resources are low. Probably the extra complexit wasn’t worth it at the time, but are there any other problems with this idea?
Interestingly enough I’ve had a problem I believe is related to window objects before.
My standard XP SP2 install flipped out a year or so ago and started acting oddly without any obvious reason. I would have a couple apps open (several IE windows, Outlook, Word, Visual Studio, etc) and out of the blue when I went to open another window or app I’d hear the critical stop sound (but see no message) and the app would crash (Task Manager included).
I found that if I closed a few programs I had open (an IE window for example) I could then open the program I was trying to use. I played around with Task Manager to try and see if any apps were gobbling up GDI Objects (again, is that the right metric?), but none seemed to be going nuts.
I seemed to have the most problems when trying to open programs with lots of menus/buttons (Paint Shop Pro and Photoshop come to mind), and the probably sometimes became so bad I’d have to reboot, in which case it cleared up for an hour or so. In the end I had to reinstall because it was killing my productivity.
Yeah, blah blah who cares, not a tech support forum, but I figured I’d put this out and see if anyone has any ideas about what could cause something like this.
Nick: "USER Objects" corresponds to Windows (+ a few other window manager objects, I believe). "GDI Objects" corresponds to GDI things (obviously): pens, brushes and so on.
Nick: Something is chewing up the desktop hezp I believe. I have the same issue as well – but this time things don’t draw correctly – a dialog may be missing buttons, a window may not blit its background, etc.
Try reading "Still plenty of 0s, but you’re out of 1s" of http://www.dansdata.com/io067.htm – there are links on how to enlarge the heap. I myself am at a loss of why it happens to me (it only started a few months ago). Not as bad as you, but still.
Anyhow, I remember a popular RPG game that if you alt-tabbed out, would easily leak 500-1000 handles – you’d see the handle count rise steadily. The handles it leaked were memory expensive too – caused the kernel to bloat up more and more until your PC thrashed. It caused the game to eventually crash if you alt-tabbed enough. It was fixed in a patch, though. But the memory leaked would be recovered only by a reboot. Ick.
Worf: I’ve seen select boxes on IE 6.0 get drawn incorrectly (a 4 instead of the ‘open’ arrow, no contents) because there were too many GDI objects. This was because I (mis)used a behaviour to do highlighting on a very big table list.
Possibly some spyware or something might be creating window handles in the background?
> Microsoft should just document their windowless controls library
Microsoft *did* document a windowless control library: Windows Presentation Foundation. What’s so special about DirectUI? It’s unmanaged? Seriously, after developing for WPF for any reasonable amount of time, you’d not *want* to use anything else!
Whenever I used windowless techniques, I always got grief from QA that they couldn’t test using MS-Test, Visual Test, Silk Performer or whatever window handle based test tool of the day they were using. I just don’t bother anymore to conserve window handles, but I still don’t think I ever get anywhere near the 10000 limit.
I am fairly certain I have quipped about this before, but I work on a financial information application, and our users have huge workspaces consisting of many "pages", each page containing about, say, a dozen windows.
As the user switches pages, we then hide and show windows as needed. Or at least we used to do that. Now we destroy window handles and recreate them at the appropriate moment.
Which saves a bunch of handles and desktop heap resources… But the result is that we are now doing the window manager’s job. And since we use the framework of our development tool (Delphi) we get some nice issues where certain controls forget their contents (listbox shows up empty after being recreated) because the framework does not always provide temporary storage for the controls that might show up again.
So now we are doing both the job of the windows manager as well as the framework we’re building on.
Effectively, who needs an OS? Should we build that as well? :->
I think we will see larger and larger screens. I have a 30" monitor at home. 23" is quickly moving in as the next default monitor size and I have no problems visualising people sitting with two or three such monitors. The resolution will grow too. More room to fit windows inside.
With 32-bit Windows, 30 instances of IE will give or take a few windows, exhaust the desktop heap size. The 32000 handle limit should suffice for a while, but we will see more windows in the near future for certain.
Oh… the time it takes to destroy about 20000 window handles and the toll it puts on the OS is very limiting. The user can forget about interacting with task manager for the next minute as everything will freeze hard…
Maybe this is another area where WPF will shine? Presumably it will offload the window manager?
Raymond: technically, anyone can implement DirectUI on their own. In practice, though, only one entity in the world has the luxury of the common controls source code at its disposal, or the luxury of dedicated hooks in OLE Accessibility. I guess what I really meant is I’d like to see windowless as a standard Common Controls feature
Dean & Wolf: Thanks for the info, and from the KB article linked to on that site it does sound like it was a problem with the heap.
Too bad I reinstalled – I’m curious now if increasing the heap size would have helped.
Shortsighted artificial limits. 15 bit values in a 32 bit os is just as absurd now as the DC limits in Win 3.1 were.
It’s called RAM, check into it.
Just to clarify for those Firefox (and other Gecko-based browser) users, current versions create native windows (i.e. HWNDs) to optimise certain effects such as scrolling, however I understand that the plan is to internally track dirty areas and such like so that BitBlt can be used for scrolling and so no subwindows will be required.