Que possibilidades existem para análise post mortem em .NET (por exemplo, depois de uma queda de um programa)?

Question

Vamos supor que existe um programa C #, que é usado como um serviço Windows. Vamos supor que o serviço tem ido selvagem e está consumindo CPU e memória como um louco. Ele precisa ser reiniciado em breve, porque é um sistema de produção. Então eu não tenho muito tempo para reunir informações de tempo de execução. Talvez um olhar rápido sobre o gerenciador de tarefas ... isso é tudo.

Depois disso, tudo o que tenho são arquivos de log log4net e log de eventos do Windows para análise post mortem.

Suponha que eu descobri a razão para o problema. Outra pessoa correções e talvez o programador acrescenta alguma log adicional, para que eu possa encontrar um problema semelhante mais rápido da próxima vez. No entanto: Eu ainda dependem da qualidade dos arquivos de log e de esperança que da próxima vez um problema de alguma forma reveil-se nos loggings

.

Existem também outras maneiras de fazer análise post mortem? Talvez algo como fio dumps (como em java), despejos de memória ou qualquer outra coisa, que podem ajudar na análise post mortem? Talvez alguns build-in .NET ferramenta de enquadramento pode ajudar?

Eu estou muito interessado em experiências do projeto real e como você iria tentar resolver esta questão de manutenção, o que eu acho que é muito real para a maioria dos programadores.

Answer 1

Como Marc diz WinDbg + SoS vai deixar você depurar um monte de problemas, você não pode realmente endereço no Visual Studio. Há alguns excelentes tutoriais neste blog .

Para problemas de memória, você pode também olhar para os contadores .NET desempenho no Perfmon. Você poderia olhar para onde os objetos estão localizados (que geração) e quanto tempo é gasto na coleta de lixo. Isso deve lhe dar algumas informações úteis. Se você quer saber por objeto não estão sendo coletados WinDbg e SOS é o caminho a percorrer. Para orientá-lo através de uma sessão simples os passos são:

1. Verifique a pilha usando !dumpheap -stat, olhar para o grande número de casos. Você provavelmente tem uma idéia do que você esperaria encontrar na pilha a qualquer momento, por isso, se algo parece fora do comum, olhar para isso.

2. Escolha exemplo aleatório e fazer um !gcroot no endereço da instância. Isso vai lhe dizer por que o objeto não está sendo coletada.

3. Repetir

candidatos prováveis ??para manter coisas vivas por mais tempo do que deveria são: eventos, estática e a fila finalizador para citar alguns.

Você também pode querer dar uma olhada na minha resposta para esta questão para ver mais coisas WinDbg.

Answer 2

Você pode fazer despejos de memória com .NET, e olhar para eles com o WinDbg / sos (e sosassist). Não é simples, mas funciona. Mas bastante hardcore. Pesquisas sobre "+ windbg + .NET" deve ser interessante.

Outras que - contadores de recursos? arquivos de log? Muitas coisas que você pode olhar que pode ser ativado com bastante facilidade.

Answer 3

Infelizmente eu tive que fazer uma quantidade razoável de presente - a melhor ferramenta que se deparam é cordbg que vem com o SDK (você vai precisar da versão correcta para a sua versão .net). http://msdn.microsoft.com/en-us/library/a6zb7c8d. aspx para mais detalhes.

anexar ao processo em execução em cordbg (a <[pid]>), anexar a cada segmento em execução (t <[tid]>), em seguida, despejar a pilha para cada thread (w).

Automatizar essa tarefa com um script vb pouco e, em seguida, despejar em um arquivo permitirá que você executar esta ferramenta uma série de vezes, capturando a saída para um arquivo. Comparando todas as pilhas de rosca lhe dará uma idéia muito boa de onde o aplicativo está gastando seu tempo.

A coisa agradável sobre esta abordagem, especialmente com automatizar as lixeiras, é que você pode rapidamente pegar todas as informações e obter o seu processo reiniciado no mais curto espaço de tempo.

Answer 4

Um grande recurso para análise post-mortem com WinDbg e SOS é Tess Ferrandez' série de entradas de blog sobre o assunto.

EDIT: link atualizado

Answer 5

Se o processo ainda está vivo, então você pode executar o Managed Stack Explorador contra-lo para obter uma visão rápida do que ele está fazendo. Você pode executar este sem uma explícita instalar.

Além disso, em seguida, um despejo completo + windbg + SOS dá-lhe o máximo de informações, mas chegando não é trivial.