"Fortunate are those who take the first steps.” ― Paulo Coelho

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)

Debugging a GDI Resource Leak

Suggested to try these Office June updates in case of such leaks (enhances copy paste operation speed) (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 –

July 2, 2015 Posted by | .NET General, Memory, windbg | , , , | Leave a comment

How to debug an unmanaged exe under Windbg

Assume that we have got an exe(unmanaged/managed) which is crashing/hang/wanted to debug and see the intermediate values etc. For this example, I have used the below simple cpp program compiled to exe.

Steps for debugging this complied exe in Windbg:

1) Launch Windbg, -> Open Executable, browse and select our cpp program output “ConsoleApplication1.exe”

2) Now set the symbol path and source path pointing to its corresponding directory.

3) Reload the symbol to make sure the relevant symbols loaded.

4) If you press “g” mean go/F5 would run the program and displays the output.

5) Let us put some breakpoints at Main method and also Swap2Numbers to step in line by line debugging.

 >bp ConsoleApplication1!main 

  >bp ConsoleApplication1!Swap2numbers

6) Since we have mapped the source code path also, now on typing “t” would execute/step in line by line. You would also notice the source code window opened up and breakpoint indicator set.

7) If you wanted to unassemble, then use> uf ConsoleApplication1!main (assembly code).

8) When you go line by line debugging, you can view the intermediate value of the function by typing >dv  (display variable)

This slideshow requires JavaScript.

April 26, 2015 Posted by | windbg | | Leave a comment

Procdump is preferred over Adplus- About ProcDump.

There may be many ways to capture the dumps in winodws, but which one gives us the better dumps ? Obviously Procdump has lot of advantage, details and preferred over Adplus when see the details in Windbg. 

We suggest to use Procdump and also carefully select the bitness when capturing dumps. For 64 bit use -64 or else leave it blank(default it is 32 bit).

 The syntax goes like this for crash-> Procdump -e -ma -t -64 -w Outlook.exe    (Procdump page has got details about these command line switches)

Let me put it in steps,

1)    Before taking dump, enable page heap corruption checking using the following command:   gflags.exe -p /enable outlook.exe /full

 2)    Now run the procdump command to capture the dump with bitness set accordingly. Procdump -e -ma -t -64 -w Outlook.exe  Wait for the crash and confirm dump has been created successfully.

 3)    After the crash, reset command: gflags.exe -p /disable outlook.exe You can use the following command line to see if page heap checking is enabled:    gflags.exe –p

 For additional info, refer Dan B blog post here and about procdump quick video here.

June 6, 2014 Posted by | Uncategorized | | Leave a comment


%d bloggers like this: