A longa (chata) história

Atualmente, tenho um aplicativo que leva a uma exceção em apenas um pc. Depois de algumas pesquisas, eu poderia encapsular o problema com um pequeno aplicativo de amostra, mas o verdadeiro motivo ainda está oculto.

Devido ao fato de que neste PC não há Visual Studio instalado, nem somos capazes de fazê-lo, procurei outra solução para encontrar o verdadeiro motivo.

Em uma primeira abordagem, reduzi cada vez mais o meu pequeno aplicativo apenas lendo atentamente a mensagem de exceção, compare-o com o código e tente & erro para chegar à linha de problema concreta. Mas isso não ajudaria a obter todas as informações sobre quais são os valores atuais de todas as variáveis usadas etc.

Então eu procurei por outroMelhor maneira de obter as informações necessárias. Eu já li sobreLixões eMinidumps por um longo tempo, mas nunca precise deles, porque até agora eu sempre podia reproduzir o cenário descrito pelo usuário no meu desenvolvedor ou máquina de teste.

Mas desta vez parece haver apenas um PC com o problema e, infelizmente, mudar a máquina completa ou instalar tudo de novo, não há uma opção.

Para me familiarizar sobre como trabalhar com despejos, acabei de escrever um aplicativo de teste c # simples, contendo um único botão que não faz nada além dethrow new ArgumentException("Test");

Agora eu preciso criar um arquivo de despejo mágico depois de pressionar o botão malicioso, lê-lo no Visual Studio 2008 Professional e parecer com ele um aplicativo em execução normal no VS, exceto queEtapa seguinteetc. não funcionará.

Tanto quanto eu sei, a melhor ferramenta para criar um despejo em um momento específico éprocdump, devido à possibilidade de definir quando um ou vários despejos são executados.

Então eu simplesmente baixei e comecei chamandoprocdump -o -e MyApp.exe d:\MyApp.dmp. Alega queMyApp.exe não existe. Ok, minha culpa. Basta iniciar o MyApp primeiro e depois procdump.

O Procdump está sendo executado agora, mostrando todas as opções que ele usa e parece aguardar uma exceção não tratada. Nada mais fácil do que isso, eu simplesmente pressiono meu botão malicioso ... e nada acontece no procdump.

Em vez disso, aparece uma janela do meu aplicativo que explica que ocorreu uma exceção não tratada (surpresa, surpresa) e o que eu gostaria de fazer (Detalhes, Continuar, Sair). Mas não importa o que eu selecione, o procdump não poderá criar um arquivo de despejo automaticamente.

Se eu for e apenas ligarprocdump -o MyApp.exe d:\MyApp.dmp quando a caixa de diálogo está mostrando o arquivo de despejo parece inútil, porque, depois de abri-lo no VS, a pilha de chamadas fica pendurada em algum lugarntdll.dll mas em nenhum lugar do meu código (eu acho que esse é o MessageQueue da caixa de diálogo aguardando alguns cliques do mouse).

Se eu der uma olhada mais de perto nos detalhes, você encontrará algumas informações sobre como delegar a exceção não tratada em um depurador JIT. Mas eu não quero um depurador JIT, gostaria de travar o aplicativo para obter o arquivo de despejo.

Após essas tentativas, encontreiClrDump, mas isso não produziu despejos melhores (se eu carregá-lo no VS e dar uma olhada na pilha de chamadas).

Com essas informações levadas em conta, agora você (espero) pode me fornecer uma solução (funcional) para meu aplicativo .Net:

A (curta) pergunta

Como posso criar um arquivo de despejo quando ocorre uma exceção sem tratamento em um aplicativo .net, que consigo carregar arquivos .pdb do MyApp e ver em quais circunstâncias a exceção foi lançada?

A resposta

Com a ajuda de Naveen e Lex Li, pude ter um pouco mais de insight sobre como funciona a depuração com despejos de memória. E agora eu só gosto de recapitular todas as coisas necessárias para fazê-lo funcionar:

Sempre que desejar obter um despejo de um processo, você pode selecionar entre várias ferramentas para realizar o trabalho:

Procdumpferramenta de linha de comando fácil que pode criar despejos em cenários complicados, masnão trabalhar para capturar .net exceções sem tratamento.DebugDiagferramenta gráfica fácil que pode criar despejos em falhas (mesmo exceções .net), mas não pode criar despejos em cenários avançados como o Procdump.

Como você pode ver, você terá duas ferramentas capazes de criar despejos em diferentes circunstâncias, portanto, ambos são mais parceiros do que rivais na criação de despejos no momento necessário.

Depois de criar um despejo com uma das ferramentas acima, é hora de analisar o despejo para descobrir o motivo do problema. Para analisar, você pode pegar o WinDbg. Faz parte doFerramentas de depuração para Windows e pode ser obtido na Microsoft. Infelizmente, a barreira de entrada do WinDbg é bastante alta, mas é realmente poderosa. Talvez dê uma olhadaeste blog para entender melhor como usar essa ferramenta.

Se você possui um aplicativo .Net 4 e usa o Visual Studio 2010, também pode usá-lo para analisar. É muito mais fácil de usar, devido à melhor interface gráfica do usuário, mas não possui o poder do WinDbg. Para obter uma comparação melhor, você deve examinarEste artigo.

Por último, mas não menos importante, você também pode usar o sos.dll no Visual Studio 2008.Aqui está o artigo descrevendo o que você pode fazer com isso.