Heisenbug: programa Winapi falhar em alguns computadores

Question

ajuda por favor! Eu estou realmente no final meu juízo. Meu programa é um pouco gerente de notas pessoais (google para "CintaNotes"). Em alguns computadores (e, claro, eu próprio nenhum deles) deixa de funcionar com uma exceção não tratada logo após começar. Nada de especial sobre esses computadores poderia ser dito, exceto que eles tendem a ter processadores da AMD.

Ambiente:. Windows XP, Visual C ++ 2005/2008, Winapi matéria

Aqui está o que é certo sobre isso "Heisenbug":

1) O acidente acontece apenas na versão Release.

2) O acidente vai embora assim que eu remover todo o material GDI-relacionado.

3) BoundChecker não tem queixa-se.

4) Escrevendo um registro mostra que o acidente acontece em uma declaração de uma variável int local! Como poderia ser? corrupção de memória?

Todas as idéias serão muito apreciados!

UPDATE: Eu consegui obter o aplicativo depurado em um PC "defeituoso". Os resultados:

"Exceção não tratada no 0x0044a26a em CintaNotes.exe: 0xC000001D:. Instrução ilegal"

e quebras de código em

0044A26A cvtsi2sd XMM1, PTR DWORD [esp + 14h]

Assim, parece que o problema estava na competição "Geração de Código / Ativar Conjunto de instruções avançado" opção do compilador. Foi definido como "/ arch: SSE2" e foi batendo nas máquinas que não suportam SSE2. Eu definir essa opção com "Set Não" eo bug está desaparecido. Ufa!

Obrigado a todos muito para ajudar !!

Answer 1

Por isso doesnnt falhar quando configuração é configuração de depuração? Há muitas coisas diferentes que um configruation RELEASE: 1.) Inicialização de globais 2.) máquina real código gerado etc ..

Então, primeiro passo é descobrir quais são as configurações exatas para cada parâmetro no modo de LIBERAÇÃO em comparação com o modo de depuração.

-AD

Answer 2

4) Writig um registro mostra que o acidente acontecer em uma declaração de uma variável int local! como poderia ser? corrupção de memória?

O que é o código subjacente no executável / montagem? Declaração de int é nenhum código em tudo, e como tal pode não falhar. Você inicializar o int de alguma forma?

Para ver o código onde o acidente aconteceu, você deve executar o que é chamado de uma análise post-mortem.

Relatório de Erros do Windows

Se você quer analisar o acidente, você deve obter um despejo de memória. Uma opção para isso é para se inscrever para o Relatório de Erros Windows - requer algum dinheiro (você precisa de uma digital de assinatura de código ID) e alguma forma de enchimento. Para mais informações visite https://winqual.microsoft.com/ .

Obter o despejo de memória destinado a WER diretamente do cliente

Outra opção é entrar em contato bruxa algum usuário que está tendo o acidente e obter um despejo de memória destinado a WER dele diretamente. O usuário pode fazer isso quando ele clica sobre os detalhes técnicos antes de enviar o acidente para Microsoft -. A localização do arquivo de despejo de memória pode ser verificada há

Seu próprio minidump

Outra opção é registrar o seu próprio manipulador de exceção, tratar a exceção e escrever um lugar minidump desejar. descrição detalhada pode ser encontrada no Código Projeto Post-Mortem Debugging sua aplicação com Minidumps e Visual Studio. NET artigo .

Answer 3

1) O acidente acontece apenas na versão Release.

Isso é geralmente um sinal de que você está confiando em algum comportamento que não é garantido, mas passa a ser verdadeiro na compilação de depuração. Por exemplo, se você esquecer de inicializar suas variáveis, ou acessar um array fora dos limites. Certifique-se de que você tenha ativado todos os compilador cheques (/ RTCsuc). Verifique também coisas como contando com a ordem de avaliação dos parâmetros da função (o que não é garantido).

2) O acidente vai embora assim que eu remover todo o material GDI-relacionado.

Talvez isso é um indício de que você está fazendo algo de errado com o material relacionado GDI? Você está usando alças depois de terem sido libertados, por exemplo?

Answer 4

Faça o download do ferramentas de depuração para o pacote do Windows . Defina os caminhos de símbolo corretamente, em seguida, executar o aplicativo sob WinDbg. Em algum momento, ele vai quebrar com uma violação de acesso. Em seguida, você deve executar o comando "! Analyze -v", que é bastante inteligente e deve dar-lhe uma dica sobre o que está errado acontecendo.

Answer 5

A maioria dos heisenbugs / bugs só de libertação são devido a qualquer fluxo de controle que depende lê da memória uninitialised / ponteiros obsoletos / end passado de buffers, ou condições de corrida, ou ambos.

Tente substituir seus allocators para que eles zerar a memória ao alocar. Será que o problema desaparecer (ou tornar-se mais reprodutível?)

Writig um registro mostra que o acidente acontece em uma declaração de uma variável int local! Como poderia ser? corrupção de memória?

estouro de pilha! ;)

Answer 6

4) Writig um registro mostra que o acidente acontecer em uma declaração de uma variável int local! Como pode ser isso? corrupção de memória

Eu encontrei a causa de inúmeras "falhas estranhas" para ser dereferencing de um this quebrado dentro de uma função membro do referido objeto.

Answer 7

O que a palavra acidente? Violação de acesso ? Exceção? Essa seria a maior pista para resolver isso com

Certifique-se de não ter precedente corrupções de memória utilizando PageHeap.exe

Certifique-se de que você não tem estouro de pilha (array CBig [1000000])

Certifique-se de que você não tem memória inicializado-un.

Além disso, você pode executar a versão de lançamento também no interior do depurador, uma vez que você gerar símbolos de depuração (não o mesmo que criar versão de depuração) para o processo. Percorrer e ver se você está recebendo qualquer aviso na janela de traço depurador.

Answer 8

"4) Escrevendo um registro mostra que o acidente acontece em uma declaração de uma variável int local! Como pode ser isso? Corrupção de memória?"

Este poderia ser um sinal de que o hardware é de fato defeituoso ou sendo empurrado demasiado duro. Descubra se eles overclock seu computador.

Answer 9

Quando eu obter esse tipo de coisa, eu tento executar o código através gimpels PC-Lint (análise estática de código) como ele verifica diferentes classes de erros para BoundsChecker. Se você estiver usando boundschecker, ligue as opções de envenenamento memória.

Você menciona AMD CPUs. Você investigou se existe uma versão gráficos semelhantes cartão / condutor e / ou configuração no lugar nas máquinas que acidente? Será que ela sempre falhar nessas máquinas ou apenas ocasionalmente? Talvez executar a ferramenta Informações do sistema nessas máquinas e ver o que eles têm em comum,

Answer 10

soa como corrupção de pilha para mim. Minha ferramenta favorita para acompanhar aqueles para baixo é IDA Pro . Claro que você não tem que o acesso à máquina do usuário.

Algumas damas de memória têm um tempo difícil pegando corrupção de pilha (se de fato isso). O caminho certo para obter aqueles que eu acho que é a análise de tempo de execução.

Isso também pode ser devido à corrupção em um caminho de exceção, mesmo se a exceção foi tratada. Você depurar com 'captura exceções de primeira chance' ligado? Você deve contanto que você pode. Ele faz ficar chato depois de um tempo em muitos casos.

Você pode enviar esses usuários uma versão verificada a sua aplicação? Confira Minidump Handle essa exceção e escrever uma lixeira. Em seguida, use WinDbg para depuração em sua extremidade.

Outro método está escrevendo registros muito detalhados. Criar uma opção "Log cada ação", e pedir ao utilizador transformar isso em e enviá-lo, você também. Despejar memória para os logs. Confira '_CrtDbgReport ()' no MSDN.

Boa sorte!

EDIT:

Em resposta ao seu comentário: Um erro em uma declaração de variável local não é surpreendente para mim. Eu já vi isso muito a. É geralmente devido a uma pilha corrompido.

Alguns variável na pilha pode estar correndo sobre ela está fronteiras, por exemplo. Ele explodir depois disso. Então declarações pilha variáveis ??jogar erros de memória aleatórios, tabelas virtuais corrompidos, etc.

Sempre que eu vi aqueles que por um período prolongar de tempo, eu tive que ir para a IDA Pro. em detalhes de tempo de execução desmontagem depuração é a única coisa que eu sei que realmente fica aqueles confiável.

Muitos desenvolvedores usar WinDbg para este tipo de análise. É por isso que eu também sugeridas Minidump.

Answer 11

Tente Rational PurifyPlus (IBM). Ele pega um monte de erros que BoundsChecker não.