watchdog relatórios Bater para quando meu aplicativo trava no computador do cliente

Question

Eu estou trabalhando com uma aplicação pouco fiáveis ??(Qt / windows), em parte escrito para nós por um terceiro (apenas tentando transferir a culpa lá). Sua última versão é mais estável. Tipo de. Nós estamos recebendo menos relatos de acidentes, mas estamos recebendo muitos relatos de que apenas pendurado e nunca mais voltar. As circunstâncias são variados, e com a pouca informação que pode reunir, não temos sido capazes de reproduzir os problemas.

Assim, idealmente, eu gostaria de criar uma espécie de cão de guarda que os avisos que o aplicativo travou, e ofertas para enviar uma volta relatório do acidente para nós. Boa idéia, mas há problemas:

• Como é que o cão de guarda conhecer o processo foi suspenso? Presumivelmente que instrumento a aplicação periodicamente dizer "tudo ok" para o cão de guarda, mas onde é que vamos colocar isso de tal forma que ele está guarenteed acontecer com frequência suficiente, mas não é provável que seja em um caminho de código que o aplicativo termina em quando é trancada.

• Que informações devem o relatório de vigilância, quando um acidente acontece? O Windows tem uma API de depuração decente, por isso estou confiante de que todos os dados interessante é acessível, mas eu não sei o que seria útil para rastrear os problemas.

Answer 1

Você quer uma combinação de um minidump (uso DrWatson para criar estes se você não quer adicionar seu próprio código de geração minidump) e userdump para desencadear uma criação de minidespejo em um pendurar.

A coisa sobre detectar automaticamente um jeito é que sua difícil decidir quando algumas coisas penduradas e quando é apenas lento ou bloqueado por IO espera. Eu pessoalmente prefiro para permitir que o usuário para travar o aplicativo deliberadamente quando pensam sua hung. Além de ser muito mais fácil (meus aplicativos não tendem a cair muitas vezes, se em tudo :)), que também ajuda-os a "ser parte da solução". Eles assim.

Em primeiro lugar, veja o clássico bugslayer artigo sobre crashdumps e símbolos, que também tem algumas informações excelente sobre o que está acontecendo com essas coisas.

Em segundo lugar, get userdump , que permite a criação de lixeiras, e instruções para configurá-lo para gerar despejos

Quando você tem o despejo, abri-lo no WinDBG, e você será capaz de inspecionar todo o estado do programa - incluindo tópicos e callstacks, registos, memória e parâmetros para funções. Acho que você vai ser particularmente interessado em usar o " ~ * mf < > / a" comando em WinDbg para obter a pilha de chamadas de cada fio, e os 'bloqueios' comando! mostrar todos os objetos de bloqueio. Eu acho que você vai descobrir que o jeito vai ser devido a um impasse de objetos de sincronização, que vai ser difícil de rastrear como os tópicos tendem a esperar por uma chamada WaitForSingleObject, mas olhar mais para baixo os callstacks para ver os tópicos de aplicação (em vez de tópicos 'quadro', como notificações de fundo e rotinas de rede). Uma vez que você estreitou-los para baixo, você pode ver o que as chamadas estavam sendo feitos, possivelmente, adicionar um pouco de instrumentação de registro para o aplicativo para tentar lhe dar mais informações pronto para a próxima vez que ele falhar.

Boa sorte.

Ps. Breve google me lembrou este: depuração impasses . (CDB é o equivalente da linha de comando windbg)

Answer 2

Você pode usar ADPlus de ferramentas de depuração da Microsoft para o Windows para identificar os trava. Ele vai anexar ao seu processo e criar um despejo (mini ou integral) quando os processo trava ou falhas.

WinDbg é portátil e não precisa ser instalado (você tem que configurar os símbolos, embora). Você pode criar uma instalação especial que vai lançar seu aplicativo usando um lote, que também será executado ADPlus após suas partidas de aplicativos (ADPlus é uma ferramenta de linha de comando, assim que você deve ser capaz de encontrar uma maneira de incorporá-lo de alguma forma).

BTW, se você encontrar uma forma de reconhecer o jeito internamente e são capazes de travar o processo, você pode registrar com Erro do Windows Relatórios para que o despejo de memória será enviado a você (o usuário deve permitir que ele).

Answer 3

Eu acho que um aplicativo separado para fazer o watchdogging é susceptível de produzir mais problemas do que resolve. Eu sugiro que em vez disso, você primeiro criar manipuladores para gerar minidumps quando as falhas de aplicativos, em seguida, adicione um fio de cão de guarda para o aplicativo, que deliberadamente falhar se o aplicativo vai fora dos trilhos. A vantagem para o segmento watchdog (vs um aplicativo diferente) é que ele deve ser mais fácil para o cão de guarda de saber com certeza que o aplicativo tenha saído dos trilhos.

Depois de ter as minidespejos, você pode picar ao redor para descobrir o estado do aplicativo quando ele morre. Isso deve lhe dar pistas suficientes para descobrir o problema, ou pelo menos para onde olhar em seguida.

Há algumas coisas em CodeProject sobre minidespejos , o que poderia ser um útil exemplo. MSDN tem mais informações sobre eles também.

Answer 4

Não se preocupe com um cão de guarda. Inscrever-se para Reproting erro do Windows da Microsoft (winqual.microsoft.com). Eles vão recolher os stacktraces para você. Na verdade, é bastante provável que eles já estão fazendo isso hoje; eles não compartilhá-los até que você se inscrever.