Encontrando GDI / User uso de recursos de um despejo de memória

Question

Eu tenho um despejo de memória de um aplicativo que supostamente está vazando GDI. O aplicativo está sendo executado no XP e não tenho problemas carregá-lo em WinDbg para olhar para ele. Anteriormente temos utilizar a Gdikdx.dll extensão a olhar para informações GDI, mas esta extensão não é compatível com XP ou Vista.

Alguém tem qualquer ponteiros para encontrar uso do objeto GDI no WinDbg.

Como alternativa, eu tenho acesso ao programa falhar (e sua suíte de testes de estresse) para que eu possa reproduzir em um sistema executando se você souber de alguma depuração ferramentas 'ao vivo' para XP e Vista (ou Windows 2000, embora este não é nossa meta).

Answer 1

Houve um artigo MSDN Magazine de vários anos atrás que falou sobre vazamentos GDI. Isto aponta para vários lugares diferentes, com boas informações.

Em WinDbg, você pode também tentar o comando !poolused algumas informações.

Encontrar vazamentos de recursos a partir de um despejo de memória (post-mortem) pode ser difícil - se ele era sempre o mesmo lugar, usando a mesma variável que vazamentos de memória, e você tiver sorte, você pode ver o último lugar que será vazado, etc ele provavelmente seria muito mais fácil com um programa ao vivo em execução sob o depurador.

Você também pode tentar usar Microsoft Detours , mas a licença nem sempre funciona Fora. É também um pouco mais invasivo e avançado.

Answer 2

Eu passei a última semana trabalhando em um vazamento ferramenta GDI finder. Nós também realizar testes de estresse regulares e nunca durou mais do que um dia inteiro w / o parar devido ao usuário / gdi consumo excessivo objeto punho.

As minhas tentativas têm sido muito bem sucedida, tanto quanto eu posso dizer. Claro, eu passei algum tempo previamente à procura de uma solução alternativa e mais rápido. Vale a pena mencionar, eu tive alguma experiência semi-lucky anterior com a ferramenta GDILeaks de artigo do MSDN mencionado acima. Já para não falar que eu tinha que resolver alguns problemas antes de colocá-lo para o trabalho e desta vez ele simplesmente não me o que dar e como eu queria. A desvantagem da sua abordagem é a interface depurador pesado (que retarda o alvo pesquisado por ordens de magnitude que eu encontrei inaceitável). Outra desvantagem é que não funcionou o tempo todo - em algumas corridas eu simplesmente não poderia obtê-lo para relatar / qualquer coisa de computação! Sua complexidade (a julgar pela quantidade de código) foi outro fator susto-away. Eu não sou um grande fã de GUIs, como é minha convicção de que eu sou mais produtivo sem janelas em tudo; o). Eu também achei difícil para torná-lo a encontrar e usar os meus símbolos.

Mais uma ferramenta que usei antes de definir a escrever meu próprio, foi o leakbrowser .

De qualquer forma, eu finalmente liquidada em uma abordagem iterativa para alcançar objetivos seguinte:

• penalidades de desempenho menor
• simplicidade de implementação
• não-invasiva (usado para vários produtos)
• contando com o máximo disponível como possível

I utilizado desvios (uso não comercial) para a funcionalidade de núcleo (isto é uma DLL injectável). Coloque o JavaScript para usar para a geração automática de código (15K script para o código-fonte gen 100K - nenhum código de maneira que eu isso manualmente e sem C pré-processador envolvido!) Mais uma extensão windbg para análise de dados e snapshot / diff apoio.

Para dizer a longa história - depois que eu tinha terminado, era uma questão de algumas horas para coletar informações durante outra teste de estresse e mais uma hora para analisar e corrigir os vazamentos.

Eu serei mais do que feliz em compartilhar minhas descobertas.

P.S. algum tempo eu gastei na tentativa de melhorar o trabalho anterior. Minha intenção era minimizar falsos positivos (eu vi apenas sobre muitas das pessoas durante o desenvolvimento), de modo que também irá verificar a consistência de alocação / release, bem como tendo em conta evitar alocações que nunca são vazaram.

Edit: Encontre a ferramenta aqui

Answer 3

Eu criei um script Windbg para isso. Olhe para a resposta de

comando para obter alça GDI contar a partir de um despejo de memória

Para rastrear a pilha de alocação você poderia definir um ba (Ruptura no Access) ponto de interrupção após o último objeto GDICell alocados para quebrar apenas no momento em que outra repartição GDI acontece. Isso poderia ser um pouco complexo, porque as mudanças de endereço, mas poderia ser o suficiente para encontrar praticamente qualquer vazamento.