Como vejo o código C # que causou um crashdump em clr.dll?

Question

Eu tenho um aplicativo Windows Forms (.NET 4) que funciona bem na minha máquina de desenvolvimento, mas trava em duas outras máquinas de teste.Eu posso carregar o minidump que cria no VS2010.

Escolhendo "depurar com leads mistos" a aparentemente infinita (eu matei Devenv após cerca de 20 minutos) abuso da CPU pelo Visual Studio.

Quando eu "depurar apenas com nativo", não consegue encontrar a fonte (mesmo que eu tenha espelhado a origem na mesma pasta que na máquina de teste).Simplesmente diz:

.

Exceção não tratada em 0x793F5B8C em yourwinapp .exe.hdmp: 0xc0000409: 0xc0000409.

e depois me mostra

.

Chamada Stack Local: Clr.dll! 793F5B8C ()

Como descobriria o que está causando o pedido?Posso pegar um choque completo enquanto a caixa de diálogo "Notificar Microsoft" está sendo exibida e essa ajuda?

Answer 1

A depuração de minidump era supostamente melhorada no VS2010. Não vi muita evidência para mim ainda, a depuração de modo misto parece tão desajeitada quanto antes, quando fiz alguns testes rápidos. Não tome minha palavra por isso. Nativo só é, no entanto, mostrar-lhe uma pilha de chamadas gerenciadas.

Enfrente isso na fonte. Escreva um manipulador de eventos para appdomain.currentdomain.unhandledexception e registre-o no seu método principal (). Deixe exibir o valor de e.exceptionceptionobject.toString () em, digamos, uma caixa de mensagem. Que recebe o rastreamento de pilha gerenciado da exceção. Enquanto essa caixa de mensagem é exibida, você também pode encaixar o minidump, deveria te aproximar do local de travamento.

A exceção específica que você está recebendo é, no entanto, definitivamente apontando para o código nativo C / C ++. Um estouro do buffer que está corrompendo a pilha. Certifique-se de ter os arquivos .pdb para qualquer código nativo que seu aplicativo use. E configurar o servidor do Microsoft Symbol para obter uma boa pilha nativa traço do minidump.

Editar: o fato de que você não recebe desmarcamento acima definitivamente pontos para pilha de integridade da pilha no CRT. Foi projetado para não levantar uma exceção, mas encerrar o programa imediatamente. Comportamento necessário porque a pilha é comprometida, o código não pode supor que ele pode ser desenrolado com segurança. Dado o local de acidente, é provável que esta verificação seja efetivamente feita no código CLR. Eu sei que isso não foi feito em versões anteriores de CLR, mas isso pode ser diferente na versão CLR incluída no .NET 4.0

Isso vai torná-lo bastante difícil obter um traço de pilha gerenciado. Há muito que você pode engenheiro reverso a partir do traço de pilha não gerenciado, contanto que você configure o servidor de símbolos para obter nomes de identificadores dos quadros de pilha CLR. Poste que traço de pilha em sua pergunta se você quiser ajudar a interpretá-lo. Um bug no código CLR não é improvável BTW, você pode considerar chamar o suporte da Microsoft. Eles, no entanto, precisarão de um repro consistente. Eles podem fazer com que todos os traços de pilha importantes se o repro for difícil de encontrar. Configure o servidor de símbolos para obter um bom traço de pilha não gerenciado. Fácil em VS2010: Ferramentas + Opções, Depuração, Símbolos, Tick "Servidores Microsoft Symbol".

Answer 2

Você configura procdump para obter despejo de memória total se o aplicativotem exceção não tratada, que você pode depurá-lo em vs ou windbg

e o minidump tem informações de pilha de chamadas como baldes de Watson, aqui é um de CLR Equipe e eu escrevemos sobre o mesmo

Uma breve explicação sobre as informações do Bucket do Watson que você vê no Visualizador de Eventos para exceção não tratada

.
1. exefilename
2. versão de montagem exe
3. timestamp de montagem exe
4. nome completo
5. Versão de conjunto de falhas
6. Timestamp de montagem de falha
7. Método de montagem de falhas def
8. Método de falha Instrução IL que causou a exceção
9. Tipo de exceção