Configurando uma condição "! stoponexception" para windbg via linha de comando / script de inicialização?

1

Eu tenho um problema com um aplicativo que fizemos, que às vezes falha com um StackOverflowException em algum código .NET.

Infelizmente, o aplicativo é parcialmente não gerenciado e parcialmente gerenciado e, por algum motivo, o problema só se exibe em máquinas que não são de desenvolvedor.

Meu plano atual é usar o WINDBG (parte das Ferramentas de Depuração para Windows da Microsoft), instalado nas máquinas do testador, posso obter o WINDBG para interceptar a criação da exceção em questão.

Como tal, posso fazer o seguinte:

sxe ld:mscorlib
g
.loadby sos clr
!stoponexception -create System.StackOverflowException
g
Infelizmente, como esse problema só ocorre a cada dois dias, e apenas a cada 50 ou mais execuções, eu prefiro evitar que os testadores tenham que digitar tudo ou parte disso toda vez que iniciarem esse aplicativo. / p>

Eu tentei colocar os comandos acima em um arquivo de texto e criei um atalho para eles assim:

"...\windbg.exe" -c "$<c:\windbg.txt" -o "...\app.exe"

Isso inicia o depurador WINDBG, mas infelizmente falha com esta mensagem de erro:

0:000> sxe ld:mscorlib
0:000> g
Command file caused an implicit wait
Command file execution failed, HRESULT 0x80004005
    "Unspecified error"

Portanto, aparentemente, g não é permitido nesse script de inicialização.

É possível fazer o que eu quero? Posso automatizar isso, ou preciso apenas preparar um arquivo de lote ou algo que use o autochamada que faz isso?

    
por Lasse Vågsæther Karlsen 10.09.2012 / 14:59

2 respostas

1

Embora seja tarde, mas eu queria fornecer uma solução alternativa, no entanto. Eu enfrentei o mesmo problema e me deparei com essa questão enquanto procurava a resposta. Mais tarde, descobri uma solução alternativa.

A solução alternativa é chamar o script usando $ > < ou $$ > < ou $$ > a < para que os comandos sejam condensados em um único bloco de comando.

Aqui está o doc de ajuda windbg

    
por 27.10.2017 / 04:44
0

Você pode tentar .dump /ma /u c:\app.dmp para obter um despejo de memória que pode ser copiado e analisado em sua máquina.

No entanto, em vez de tentar deixar o usuário executar o WinDbg em sua máquina, você pode fazer um despejo de memória automaticamente usando o WER, copiá-lo para sua máquina e, em seguida, analisá-lo sem pressão de tempo. Consulte Coletando dumps do modo de usuário para criar configurações no registro que armazenam o despejo no disco.

Em ambos os casos, você deve copiar de C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 (ou Framework64):

Caso contrário, pode acontecer que a sua versão do .NET seja diferente da sua versão e você não consiga analisar o erro.

    
por 09.01.2014 / 13:30