Recherche de l'utilisation des ressources GDI / utilisateur à partir d'un vidage sur incident

Question

J'ai un crash dump d'une application censée avoir une fuite de GDI. L'application fonctionne sous XP et je n'ai aucun problème à la charger dans WinDbg. Auparavant, nous utilisions l ' extension Gdikdx.dll pour consulter les informations Gdi, mais cette extension n'est pas supportée sous XP ou Vista.

Quelqu'un at-il un indicateur pour rechercher l'utilisation d'un objet GDI dans WinDbg?

J'ai également accès au programme défaillant (et à sa suite de tests de contrainte), ce qui me permet de reproduire sur un système en cours d'exécution si vous connaissez des outils de débogage «en direct» pour XP et Vista (ou Windows 2000, bien que cela ne soit pas le cas). notre cible).

Answer 1

Un article de MSDN Magazine paru il y a plusieurs années a été publié. parlé de fuites de GDI. Cela pointe vers plusieurs endroits différents offrant une bonne information.

Dans WinDbg, vous pouvez également essayer la commande ! poolused pour certaines informations.

Il peut être difficile de trouver des fuites de ressources à partir d'un vidage mémoire (post-mortem) - si c'était toujours au même endroit, en utilisant la même variable qui fuit la mémoire, et si vous avez de la chance, vous pouvez voir le dernier endroit. qu’il y aura des fuites, etc. Cela serait probablement beaucoup plus facile avec un programme en direct exécuté sous le débogueur.

Vous pouvez également utiliser Microsoft Detours , mais la licence ne fonctionne pas toujours. en dehors. C'est aussi un peu plus invasif et avancé.

Answer 2

J'ai passé la semaine dernière à travailler sur un outil de recherche de fuite GDI. Nous effectuons également des tests de contrainte réguliers et cela ne dure jamais plus d'une journée sans arrêt en raison de la surconsommation de la gestion des objets par l'utilisateur / gdi.

Mes tentatives ont été assez fructueuses pour autant que je sache. Bien sûr, j'avais déjà passé un peu de temps à la recherche d'une solution alternative et plus rapide. Il vaut la peine de mentionner que j'avais déjà eu une expérience à moitié chanceuse avec l'outil GDILeaks de l'article msdn mentionné ci-dessus. Sans oublier que je devais résoudre quelques problèmes avant de le mettre au travail et cette fois, ça ne me donnait pas quoi et comment je le voulais. L’inconvénient de leur approche est l’interface de débogage très lourde (elle ralentit la cible recherchée de plusieurs ordres de grandeur, ce que j’ai trouvé inacceptable). Un autre inconvénient est que cela ne fonctionnait pas tout le temps - sur certaines courses, je ne pouvais tout simplement pas le faire rapporter / calculer quoi que ce soit! Sa complexité (à en juger par la quantité de code) était un autre facteur effrayant. Je ne suis pas un grand fan des interfaces graphiques, car je suis convaincu que je suis plus productif sans aucune fenêtre; o). J'ai également eu du mal à le faire trouver et utiliser mes symboles.

Un autre outil que j’avais utilisé avant de commencer à écrire le mien était le fuitebrowser .

Quoi qu'il en soit, j'ai finalement opté pour une approche itérative pour atteindre les objectifs suivants:

• pénalités de performances mineures
• simplicité de mise en oeuvre
• non invasif (utilisé pour plusieurs produits)
• compter autant que possible sur les disponibilités

J'ai utilisé des détours (utilisation non commerciale) pour les fonctionnalités principales (il s'agit d'une DLL injectable). Utilisez Javascript pour la génération automatique de code (script 15K à code source 100K - impossible de le coder manuellement et sans préprocesseur C impliqué!), Ainsi qu’une extension windbg pour l’analyse des données et la prise en charge des captures instantanées / diff.

Pour résumer la longue histoire, après que j’ai eu fini, c’était une question de quelques heures pour recueillir des informations lors d’un autre test de résistance et une autre heure pour analyser et réparer les fuites.

Je serai plus qu'heureux de partager mes découvertes.

P.S. J'ai passé un peu de temps à essayer d'améliorer le travail précédent. Mon intention était de minimiser les faux positifs (j'en ai vu trop en développement), donc il va également vérifier la cohérence de l'allocation / libération et éviter de prendre en compte les allocations qui ne sont jamais divulguées.

Modifier: recherchez l'outil ici

Answer 3

J'ai créé un script Windbg pour cela. Regardez la réponse de

Commande pour obtenir le descripteur GDI compter à partir d'un vidage sur incident

Pour suivre la pile d'allocation, vous pouvez définir un point d'arrêt ba (rupture sur accès) situé après le dernier objet GDICell alloué, juste au moment où une autre affectation GDI se produit. Cela peut paraître un peu complexe car l’adresse change, mais cela pourrait être suffisant pour détecter pratiquement toute fuite.