Die Suche nach GDI / User Ressourcennutzung von einem Crash-Dump

Question

Ich habe einen Crash-Dump eine Anwendung, die angeblich GDI ist undicht. Die App läuft auf XP und ich habe keine Probleme, die es in WinDbg Laden um es zu betrachten. Bisher haben wir die Gdikdx.dll Erweiterung verwenden bei Gdi Informationen suchen, aber diese Erweiterung ist auf XP oder Vista nicht unterstützt.

Hat jemand irgendwelche Hinweise für die Suche nach GDI-Objekt Verwendung in WinDbg.

Alternativ kann ich Zugriff auf das fehlerhafte Programm (und seine Stresstest-Suite), so kann ich auf einem laufenden System reproduzieren, wenn Sie von irgendwelchen ‚live‘ Debugging-Tools für XP und Vista (oder Windows 2000 wissen, obwohl dies nicht der Fall ist unser Ziel).

Answer 1

Es gab ein MSDN Magazine Artikel von vor einigen Jahren dass sprach über GDI Lecks. Dies deutet auf verschiedene Orte mit guten Informationen.

In WinDbg, können Sie auch den Befehl !poolused versuchen einige Informationen.

Finding Ressourcenlecks in einer Crash-Dump (post-mortem) kann schwierig sein - wenn es immer am selben Ort war, die gleiche Variable, die den Speicherlecks, und Sie Glück haben, können Sie den letzten Platz sehen dass es durchgesickert wird, usw. es wäre wahrscheinlich viel einfacher, mit einem Live-Programm läuft unter dem Debugger sein.

Sie können auch unter Verwendung versuchen Microsoft Detours , aber die Lizenz funktioniert nicht immer aus. Es ist auch ein bisschen mehr invasive und Fortgeschrittene.

Answer 2

Ich habe die letzte Woche der Arbeit an einem GDI Leck-Finder-Tool ausgegeben. Wir führen auch regelmäßige Tests Stress und es nie dauerte länger als ein Tag im Wert w / o zu exzessiven Benutzer / gdi Objektanfasser durch Anhalten.

Meine Versuche waren ziemlich erfolgreich, soweit ich das beurteilen kann. Natürlich habe ich vorher einige Zeit für eine alternative und schnellere Lösung suchen. Es ist erwähnenswert, ich hatte einige vorherigen Halb Glück Erfahrungen mit dem GDILeaks Werkzeug aus Msdn Artikeln oben erwähnt. Ganz zu schweigen davon, dass ich vor ein paar Probleme zu lösen, hatte es darum, zu arbeiten und dieses Mal ist es einfach nicht geben Sie mir, was und wie ich es wollte. Der Nachteil ihres Ansatzes ist das Schwergewicht Debugger-Schnittstelle (den erforschten Zielgrößenordnungen verlangsamt, die ich gefunden inakzeptabel). Ein weiterer Nachteil ist, dass es nicht die ganze Zeit nicht funktioniert - bei einigen Läufen konnte ich einfach nicht bekommen es zu berichten / berechnen nichts! Seine Komplexität (durch die Menge an Kodebeurteilungsschaltung) war ein weiterer Panik weg Faktor. Ich bin kein großer Fan von GUIs, wie es meine Überzeugung ist, dass ich ohne Fenster produktiver bin überhaupt; o). Ich fand es auch schwer es meine Symbole finden herzustellen und zu verwenden.

Ein weiteres Werkzeug, das ich vor der Einstellung auf verwendet, um meine eigene zu schreiben, war die leakbrowser .

Wie auch immer, ich schließlich auf einem iterativen Ansatz angesiedelt folgenden Ziele zu erreichen:

• geringfügige Leistungseinbußen
• Umsetzung Einfachheit
• Nicht-Invasivität (für mehrere Produkte verwendet)
• unter Berufung auf so viel wie möglich verfügbar

Ich habe Umwege (nicht-kommerzielle Nutzung) für Kernfunktionalität (es ist eine injizierbare DLL). Setzen Sie Javascript zum automatischen Codegenerierung zu verwenden (15K Skript gen 100K Quellcode - keine Art, wie ich dies manuell kodieren und keinen C-Präprozessor beteiligt!) Sowie eine windbg Erweiterung für die Datenanalyse und Snapshot / diff-Unterstützung.

Um die lange Geschichte kurz zu sagen - nachdem ich fertig war, ist es eine Sache von wenigen Stunden ist es, Informationen eines anderen Stresstest und eine weitere Stunde zu sammeln, die Lecks zu analysieren und zu beheben.

Ich werde mehr als glücklich, meine Erkenntnisse zu teilen.

P. S. einige Zeit habe ich auf den Versuch verbringen auf der bisherigen Arbeit zu verbessern. Meine Absicht war, zu minimieren Fehlalarme (Ich habe gerade über zu viele von denen während der Entwicklung zu sehen ist), so dass es auch für die Zuordnung / Freigabe Konsistenzprüfung wird sowie avoid in Zurechnungen, die nie durchgesickert sind.

Edit: Finden Sie das Tool hier

Answer 3

Ich habe einen Windbg Skript dafür geschaffen. Schauen Sie sich die Antwort von

Befehl GDI Griff zu bekommen zählen von einem Crash-Dump

die Zuordnung Stapel verfolgen Sie ba (Break auf Access) Haltepunkt nach dem letzten zugeordneten GDICell Objekt festgelegt konnten nur an dem Punkt zu brechen, wenn ein andere GDI Zuordnung geschieht. Das könnte ein wenig komplex, da sich die Adresse ändert, aber es könnte genug sein, um so ziemlich jedes Leck zu finden.