Encontrar el uso de recursos de usuario/GDI a partir de un volcado de memoria

Question

Tengo un volcado de memoria de una aplicación que supuestamente tiene fugas de GDI.La aplicación se ejecuta en XP y no tengo problemas para cargarla en WinDbg para verla.Anteriormente hemos utilizado el Extensión gdikdx.dll para ver la información de Gdi, pero esta extensión no es compatible con XP o Vista.

¿Alguien tiene alguna sugerencia para encontrar el uso de objetos GDI en WinDbg?

Alternativamente, tengo acceso al programa que falla (y su conjunto de pruebas de estrés) para poder reproducirlo en un sistema en ejecución si conoce alguna herramienta de depuración "activa" para XP y Vista (o Windows 2000, aunque este no es nuestro objetivo). .

Answer 1

Hubo un Artículo de MSDN Magazine de hace varios años. que hablaba de fugas de GDI.Esto apunta a varios lugares diferentes con buena información.

En WinDbg, también puedes probar el !poolused comando para obtener alguna información.

Encontrar fugas de recursos desde un volcado de memoria (post-mortem) puede ser difícil: si siempre fuera el mismo lugar, usando la misma variable que pierde la memoria, y tienes suerte, podrías ver el último lugar donde se filtrará. tener fugas, etc.Probablemente sería mucho más fácil con un programa en vivo ejecutándose con el depurador.

También puedes intentar usar Desvíos de Microsoft, pero la licencia no siempre funciona.También es un poco más invasivo y avanzado.

Answer 2

Pasé la última semana trabajando en una herramienta de búsqueda de fugas GDI.También realizamos pruebas de estrés periódicas y nunca duró más de un día sin detenerse debido al consumo excesivo de identificadores de objetos de usuario/gdi.

Mis intentos han tenido bastante éxito hasta donde yo sé.Por supuesto, de antemano dediqué algún tiempo a buscar una solución alternativa y más rápida.Vale la pena mencionar que tuve una experiencia previa con mala suerte con la herramienta GDILeaks del artículo de msdn mencionado anteriormente.Sin mencionar que tuve que resolver algunos problemas antes de ponerlo a funcionar y esta vez simplemente no me dio lo que quería ni cómo lo quería.La desventaja de su enfoque es la pesada interfaz del depurador (ralentiza el objetivo investigado en órdenes de magnitud, lo cual me pareció inaceptable).Otra desventaja es que no funcionó todo el tiempo; en algunas ejecuciones simplemente no pude lograr que informara/calculara nada.Su complejidad (a juzgar por la cantidad de código) fue otro factor que ahuyentó.No soy un gran admirador de las GUI, ya que creo que soy más productivo sin ninguna ventana; o).También me resultó difícil lograr que encontrara y usara mis símbolos.

Una herramienta más que utilicé antes de empezar a escribir la mía fue la navegador de fugas.

De todos modos, finalmente me decidí por un enfoque iterativo para lograr los siguientes objetivos:

• sanciones menores de desempeño
• simplicidad de implementación
• no invasividad (utilizado para múltiples productos)
• confiando en todo lo disponible posible

Utilicé desvíos (uso no comercial) para la funcionalidad principal (es una DLL inyectable).Utilice Javascript para la generación automática de código (script de 15K para generar código fuente de 100K; ¡de ninguna manera codifico esto manualmente y sin preprocesador C involucrado!), además de una extensión windbg para análisis de datos y soporte para instantáneas/diferencias.

Para resumir la historia, una vez que terminé, fue cuestión de unas pocas horas recopilar información durante otra prueba de estrés y otra hora para analizar y reparar las fugas.

Estaré más que feliz de compartir mis hallazgos.

PDDediqué algo de tiempo a intentar mejorar el trabajo anterior.Mi intención era minimizar los falsos positivos (he visto demasiados durante el desarrollo), por lo que también verificará la coherencia de la asignación/liberación y evitará tener en cuenta asignaciones que nunca se filtran.

Editar:Encuentra la herramienta aquí

Answer 3

He creado un script Windbg para eso.Mira la respuesta de

Comando para obtener el recuento de identificadores de GDI a partir de un volcado de memoria

Para realizar un seguimiento de la pila de asignación, puede establecer un punto de interrupción ba (Interrupción en el acceso) más allá del último objeto GDICell asignado para que se interrumpa justo en el punto en que ocurre otra asignación de GDI.Esto podría ser un poco complejo porque la dirección cambia, pero podría ser suficiente para encontrar prácticamente cualquier fuga.