Finding GDI / User Resource Usage from a Crash Dump

Question

I have an application crash, presumably a GDI leak. The application runs on XP, and I have no problem loading it into WinDbg to look at it. We used to use the Gdikdx.dll extension to view Gdi information, but this extension is not supported in XP or Vista.

Does anyone have pointers to search for using GDI objects in WinDbg.

As an alternative, I have access to a failed program (and its set of stress tests), so I can play it on a running system if you know any “live” debugging tools for XP and Vista (or Windows 2000, although this is not Our goal).

Answer 1

A few years ago, an article appeared in an MSDN Magazine article that talked about GDI leaks. This points to several different places with good information.

In WinDbg, you can also try the !poolused to get some information.

Finding resource leaks from a crash dump (posthumous) can be difficult - if it were always the same place, using the same variable as the memory leak, and you were lucky, you could see the last place that it would be leaked and that .d. It would probably be a lot easier with a live program running under the debugger.

You can also try Microsoft Detours , but the license does not always work. It is also a bit more invasive and advanced.

Answer 2

I spent the last week working on the GDI leak detection tool. We also conduct regular stress testing, and it never lasted longer than a day without stopping due to excessive consumption of the / gdi object descriptor.

My attempts have been quite successful, as far as I can tell. Of course, I spent some time in advance looking for an alternative and faster solution. It is worth mentioning that I had some previous semi-successful experience with the GDILeaks tool from the msdn article mentioned above. Not to mention the fact that I had to solve several problems before starting work, and this time it just did not give me what and how I wanted it. The disadvantage of their approach is the super-heavy debugger interface (it slows down the target under study by orders of magnitude, which I consider unacceptable). Another drawback is that it did not work all the time - on some runs, I just could not get it to inform / calculate anything! Its complexity (judging by the amount of code) was another deterrent factor. I am not a big fan of the GUI since I am convinced that I am more productive without windows at all; o). It was also difficult for me to find and use my characters.

Another tool that I used before writing myself was testbrowser .

In any case, I finally decided to use an iterative approach to achieve the following goals:

• minor penalties
• ease of implementation
• non-invasiveness (used for several products)
• relying on the maximum possible

I used a bypass (non-commercial use) for the main functionality (this is an injection DLL). Put Javascript to automatically generate the code (15K script into 100K source code) - in no way do I manually code this and use the C preprocessor!) Plus the windbg extension for data analysis and support for snapshots / differences.

Tell a short story - after I finished, gather information in a few hours during another stress test and another hour to analyze and fix leaks.

I will be glad to share my conclusions.

PS I spent some time trying to improve the previous work. My intention was to minimize false positives (I saw almost too many who are developing), so he will also check the consistency of distribution / output, and also avoid accounting for emissions that never leak.

Edit: Find tool here

Answer 3

I created a Windbg script for this. Look at the answer

Command to get the GDI descriptor counter from a crash dump

To track the distribution stack, you can set a break point ba (Break on Access) for the last selected GDICell to break only at the point when another GDI distribution occurs. It can be a little complicated because the address is changing, but it can be enough to find almost any leak.