What is GDI Object leaks and tips to detect..

Recently I worked for an office issue where Excel 2013 goes to frozen state after executing some time consuming VBA code/macro. It did some operations like – copy ranges and pasted over another sheet within the same workbook. The copy and paste operation iterates over some 100 thousand times depends on the data row etc. It took nearly 3-4 hours to complete the whole copy operation due to data density spreads to x columns with x number of rows.

Problem identification: We saw the application was very much alive but could not able to click or respond to our mouse events like maximize/minimize. Moreover it was slowing the system performance as well. We could not able to figure out the cause in the initial stage. But we tried tools like Procmon, windbg dumps, VMMAP etc could not give that heads up. But after checking the task manager GDI count, we come to know that this is sort of object leak – GDI Leaks creating this hang state/lock situation.

How to identify the GDI object leaks? It is so simple to check such leaks from the task manager itself. Launch the taskmanager > details tab > right click any of the existing column > then ‘Select Columns” enable GDI Object to get added to the details process grid. From there you can keep a note of the count to conclude whether its a GDI leak or not. Typically, you would find this count in hundreds, but in case if you notice them in thousands and also incremented, then something sure to do with GDI leak fix.

What is GDI Objects? According to this MSDN article – GDI Objects are resources that are managed by GDI32.DLL on behalf of an application. Some of the common GDI Objects we consume directly/indirectly through code – Device Contexts (DCs), Bitmaps, Brushes, Fonts, Metafiles, Pens, and Regions etc. These objects gets created using API call but when never gets destructed after usage – this would lead to this leak situation. As like in .NET, it is recommended to dispose of when not interested with that ready to cleaned objects. Of-course, we do this very judiciously, but at times when our code path not cleaned after some exception or some condition branching stops us to do so, then this would be a show stopper for sure :).

What is the limit? It is limited to 64,536 (64k) GDI handles per user session- across all process. But for any individual process, the upper limit is 10000. System allows us to create these many handles and then halts after reaching this limit. You could also try tweaking this limit from registry, but generally not advised to do so due to various reasons like -affects other application performance etc.

What happens after reaching this 10,000 limit? The application would be alive as I said earlier but of no use. It is starving to create further GDI Objects to render it but indefinite halt after that due to no more Create handles permitted. When an application goes out of resources, then the create API call to functions like CreateFont, CreateDC etc would fail with this error : ERROR_INVALID_HANDLE.

There are some tools and guidance to research more on this, but I see very limited materials around this in net. I suggest the below links.

Very old cached MSDN article(thanks to google cache) http://webcache.googleusercontent.com/search?q=cache:XOnUN-jJpGoJ:msdn.microsoft.com/magazine/efea0849-057a-42b7-a5bf-a106bd38faa2&hl=en&gl=in&strip=0&vwsrc=0

Debugging a GDI Resource Leak
http://blogs.msdn.com/b/dsui_team/archive/2013/04/23/debugging-a-gdi-resource-leak.aspx

Suggested to try these Office June updates in case of such leaks
https://support.microsoft.com/en-us/kb/2817579 (enhances copy paste operation speed)
https://support.microsoft.com/en-us/kb/3054794 (some fixes around object leaks)

This slideshow requires JavaScript.

Update : 19-July
From scott blog, I found this nice tool to see the GDI count under types – http://www.nirsoft.net/utils/gdi_handles.html