Menu
Have an application with a GDI leak that will eventually hit 10,000 allocated GDI objects and crash. I tried increasing the GDIProcessHandleQuota to 20,000, but the program still crashed when it reached 10,000 objects. We're currently working on patching this leak, but out of curiosity--is there a way to increase the GDI limit for a single process? Or is 10k an individual application's hard limit?
724
The Graphics Device Interface (GDI) is a legacy component of Microsoft Windows responsible for representing graphical objects and transmitting them to output devices such as monitors and printers.
It provides pens to draw lines, brushes to fill interiors, and fonts to draw text. MFC provides graphic-object classes equivalent to the drawing tools in Windows. The table below shows the available classes and the equivalent Windows graphics device interface (GDI) handle types.
What are GDI Handles? GDI stands for Graphical Device Interface and every process that displays graphical objects and formatted text uses it. By default, each process has a limit of 10 000 GDI handles. Just like when CPU usage is high or available RAM is low, your computer can become unstable, when GDI handles run low.
Leaking GDI objects can be seen from the task manager or from Process Explorer. (Well you don't see the leaks, but you can see if object uasage count continually goes up.) There are also tools that allow to view GDI objects by type, such as GDIView[a], DeLeaker, DPUS or the GDIDebug (sourecode).
10K is a hard limit.
GDI objects represent graphical device interface resources like fonts, bitmaps, brushes, pens, and device contexts (drawing surfaces). As it does for USER objects, the window manager limits processes to at most 10,000 GDI objects [...]
Mark Russinovich has a series of articles that go in-depth about the various limits in Windows. You might find these two useful:
Another good article from Raymond Chen:
198
There is a solution that might work. I deal with a misbehaved vendor's app here that allocates tons of GDI objects and this solution allows it to work most of the time...
Do
reg query "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\SubSystems" /v windows
Look for SharedSection= which should be 3 numbers separated by commas. Increase the middle number by 1024 at a time and see if that solves your problem. You are controlling the amount of "desktop heap" with this variable which has in the past allowed me to get a misbehaving GDI running.
Look at KB184802 for a little more info. Search for SharedSection to find the relevant part of the page.
40
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
