Pergunta

Desenvolvi um programa para um cliente que está vivenciando uma determinada operação.Isso não acontece sempre no mesmo local e nos mesmos dados e, além disso, não está acontecendo nem na minha máquina de desenvolvimento local nem na minha Máquina Virtual de teste (que está livre de todos os equipamentos de desenvolvimento).

Dadas essas condições, decidi compilar com o MAP (habilitado em Configurando Propriedades-> Linker->Depurador com a opção /MAP) para ver qual função está causando o travamento.

Se bem entendi, quando o programa trava tenho que verificar o erro de offset e depois pesquisar no meu MAP na coluna RVA+BASE:

     Address                         Publics by Value                                      Rva+Base       Lib:Object
 0001:00037af0       ?PersonalizzaPlancia@CDlgGestioneDatiProgetto@MosaicoDialogs@@IAEXXZ 00438af0 f   DlgGestioneDatiProgetto.obj
 0001:00038000       ?SalvaTemporanei@CDlgGestioneDatiProgetto@MosaicoDialogs@@IAEXXZ 00439000 f   DlgGestioneDatiProgetto.obj

Na verdade, minha falha acontece no deslocamento:

00038C90
Então, devo pensar que está em algum lugar do método:

MosaicoDialogs::CDlgGestioneDatiProgetto::PersonalizzaPlancia

mas isso não é absolutamente possível, então, supondo que o computador não possa estar errado, sou eu quem está fazendo isso mal.

Alguém pode me explicar como ler o MAP da maneira correta?

Foi útil?

Solução

Leitura de arquivos de mapa para descobrir o local de travamento é explicado bem neste artigo de projeto de código.

http://www.codeproject.COM / articles / 3472 / Encontrando-Crash-Informação - Usando-o-arquivo

espero ajuda.

Outras dicas

não se preocupe - em vez disso, crie o projeto com os símbolos ativados e coloque-os em um arquivo pdb.

Modifique um pouco o programa, para escrever um minidespejo quando ele travar usando um manipulador de exceções não tratadas

Entregue o programa recém-compilado ao cliente e, quando ele travar, chame MiniDumpWriteDump.

Peça ao cliente para enviar este arquivo .dmp para você e, em seguida, basta carregá-lo no Visual Studio (ou WinDbg) e ele corresponderá os símbolos ao programa e também ao código.Você deverá conseguir ver a linha exata do código e algumas das variáveis ​​envolvidas.(se estiver usando VS, quando você carregar o arquivo .dmp, o canto superior direito terá uma opção para "iniciar a depuração", clique nele, pois ele 'iniciará a depuração' no ponto da falha)

Experimente primeiro localmente - coloque um erro div por zero em algum lugar do seu programa e veja se você consegue depurar o dump após sua execução.Observe que você deve manter exatamente o mesmo arquivo de símbolos para cada compilação do seu programa - eles correspondem exatamente.Você não pode esperar que um arquivo de símbolo de uma construção corresponda a outra construção, mesmo que nada tenha mudado.

Existem tutoriais para esse tipo de coisa, como este do CodeProject parece que descreve o que você precisa.

Para depuração pósMortem, há uma alternativa que não é exigiu o uso de um arquivo de mapa. Em vez disso, isso exigiria que você criasse um simples script de registro para ativar alguns wer (relatório de erros do Windows) sinalizadores para prender o arquivo de despejo de falha. Primeiro, construa sua inscrição com símbolos de depuração. Em seguida, siga as instruções para coleta Despesos do modo de usuário . Basicamente, você cria uma chave sob a tecla "localdumps". Esta sub-chave deve ser o nome do seu aplicativo, por exemplo, "myApplication.exe". Em seguida, crie os "DumpCount", "Dumptype" e "DumpFolder" chaves / valores. Peça ao usuário que execute o script de registro. Isso permitirá capturar o despejo localmente. Em seguida, faça o usuário forçar a falha a coletar o arquivo de despejo. O usuário pode enviar o arquivo de despejo para depurar usando os símbolos que você criou anteriormente. Por fim, você precisará criar um script de registro que remova as teclas / valores que você adicionou ao registro.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top