A customer had a line-of-business application that frequently bumped into the default limit of 10,000 GDI handles per process. The wanted to know if it was safe to raise the limit.
Increasing the per-process GDI handle limit means that a single process can consume a larger percentage of GDI resources, starving out other processes. The current value was chosen to mitigate the impact of a process that consumes a large amount of GDI resources. That process could be consuming a large amount of GDI resources maliciously (trying to trigger a denial of service by exhausting system resources), or it could be inadvertent (a bug in the app causes it to leak GDI resources).
Preventing a process from consuming all of the GDI resources makes it more likely that there will be enough GDI resources remaining to do things like open a command prompt or Task Manager to terminate the runaway process.
In this customers case, the high usage is due to the app simply having a large GDI object requirement in its natural course of business. You can raise the limit in order to accommodate your program. Just be aware that you are also raising the limit for the other two types of programs (malicious or inadvertent resource consumption) and opening yourself to risk of attack from those types of apps.
In the meantime, you might want to see what you can do to get your program to consume fewer GDI resources in its natural course of business. That would let you return the handle limit to its normal value and simplify deployment.
Is there still a 64 K system wide limit on GDI/User Handles? If one process uses 10 K there cannnot be 7 processes consuming as many GDI/User Handles? For the customer who is using too many GDI objects should try out Performance HUD (https://www.microsoft.com/en-us/download/100813) on a recent OS to see which call stacks are allocating most User/GDI objects. That should make targeted improvements much easier.
I have a heavy process spawning multiple windows with animations – is it better to have multiple threads still within one process instead each with its own msg/drawing queue or even better(for scalability) to have multiple processes instead(controlled by master process) for even less locking?
Thank you.
If you have to ask where the resource limit is or how to rise it, you are probably doing something wrong. When there is a limit, it’s usually there because of some good reason, even if it’s not evident. This applies to a surprisingly large number of things: GDI and User objects, open files, network and database connections, processes, threads…
XAML gets you out of the GDI/USER handle rat race.
Not quite. The number of handles a select() call can wait on is too low. This renders the proactor design pattern unusable on Windows.
This comment has been deleted.