Quaisquer configurações VC++ recomendadas para melhor análise de PDB em compilações de lançamento

Question

Há alguma configuração do VC++ que eu deva conhecer para gerar arquivos PDB melhores que contenham mais informações?

Eu tenho um sistema de análise de crash dump baseado no projeto crashrpt.

Além disso, meu servidor de compilação de produção possui o código-fonte instalado em D:\, mas minha máquina de desenvolvimento possui o código-fonte em C:\.Insirai o caminho de origem nas configurações do VC++, mas ao examinar a pilha de chamadas de uma falha, ele não salta automaticamente para meu código-fonte.Acredito que se eu tivesse o código-fonte da minha máquina de desenvolvimento no D:\, funcionaria.

Answer 1

"Existe alguma configuração do VC++ que eu deva conhecer"

Certifique-se de desligar a omissão do ponteiro do quadro.O blog de Larry Osterman tem os detalhes históricos sobre o fpo e os problemas que ele causa na depuração.

Os símbolos foram carregados com sucesso.Ele mostra a pilha de chamadas, mas clicar duas vezes em uma entrada não me leva ao código-fonte.

Qual versão do VS você está usando?(Ou você está usando Windbg?) ...no VS, ele definitivamente deve solicitar a fonte na primeira vez se não encontrar o local.No entanto, ele também mantém uma lista de fontes que 'não foram encontradas', para que não solicite isso todas as vezes.Às vezes a lista de não olhar é uma dor...para recuperar o prompt, você precisa ir para o explorador de soluções/nó de solução/propriedades/propriedades de depuração e editar a lista de arquivos no painel inferior.

Finalmente, você pode estar usando 'símbolos despojados'.Esses são arquivos pdb gerados para fornecer informações de depuração para percorrer a pilha de chamadas além do FPO, mas com os locais de origem removidos (junto com outros dados).Os símbolos públicos para componentes do sistema operacional Windows são pdbs removidos.Para o seu próprio código, isso simplesmente causa dor e não vale a pena, a menos que você forneça seus pdbs para terceiros.Como você teria um desses horríveis pdbs despojados?Você pode tê-los se usar "binplace" com o comando -a.

Boa sorte!Uma história de mini dump adequada é uma dádiva de Deus para a depuração de produção.

Answer 2

Se você construir diretamente do seu sistema de gerenciamento de código-fonte, você deverá anotar seus arquivos pdb com as origens do arquivo.Isso permite que você busque automaticamente os arquivos de origem exatos durante a depuração.(Este é o mesmo processo usado para recuperar o código-fonte da estrutura .Net).

Ver http://msdn.microsoft.com/en-us/magazine/cc163563.aspx Para maiores informações.Se você usa o subversion como seu SCM, você pode conferir o projeto SourceServerSharp.

Answer 3

Você poderia tentar usar o MS-DOS substituto comando para atribuir seu diretório de código-fonte ao D:dirigir.

Answer 4

Este é o procedimento que usei após alguns problemas semelhantes ao seu:

a) Copiou para o servidor de produção todos os arquivos EXE e DLL que foram construídos, cada um com seu PDB correspondente para o mesmo diretório, iniciou o sistema e esperou que o travamento acontecesse.

b) Copiei todos os arquivos EXE, DLL e PDB para a máquina de desenvolvimento (para uma pasta temporária) junto com o minidespejo (na mesma pasta).Usei o Visual Studio para carregar o minidespejo dessa pasta.

Como o VS encontrou os arquivos fonte onde foram originalmente compilados, sempre foi capaz de identificá-los e carregá-los corretamente.Assim como você, na máquina de produção o drive usado não foi o C:, mas na máquina de desenvolvimento foi.

Mais duas dicas:

• Uma coisa que fiz com frequência foi copiar um EXE/DLL reconstruído e esquecer de copiar o novo PDB.Isso arruinou o ciclo de depuração, o VS não seria capaz de me mostrar a pilha de chamadas.

• Às vezes, recebia uma pilha de chamadas que não fazia sentido no VS.Depois de um pouco de dor de cabeça, descobri que o windbg sempre me mostrava a pilha correta, mas o VS muitas vezes não.Não sei por quê.

Answer 5

Caso alguém esteja interessado, um colega de trabalho me respondeu a esta pergunta por e-mail:

Artem escreveu:

Existe uma bandeira para MinidumpWritedump () que pode fazer melhor deposições de falhas que permitirão ver o estado completo do programa, com todas as variáveis ​​globais, etc.Quanto às pilhas de chamadas, duvido que possam ser melhores por causa de otimizações ...A menos que você desligue (talvez algumas) otimizações.

Além disso, acho que desativar as funções embutidas e a otimização de todo o programa ajudará bastante.

De fato, existem muitos tipos de despejo, talvez você possa escolher um pequeno o suficiente, mas ainda tendo mais informações http://msdn.microsoft.com/en-us/library/ms680519(VS.85).aspx

Esses tipos não ajudarão na pilha de chamadas, eles afetam apenas a quantidade de variáveis ​​que você poderá ver.

Percebi que alguns desses tipos de despejo não são suportados no dbghelp.dll versão 5.1 que usamos.No entanto, poderíamos atualizá -lo para a mais recente versão 6.9, acabei de verificar o EULA para obter ferramentas de depuração do MS - o mais novo dbghelp.dll ainda está ok para redistribuir.

Answer 6

O Visual Studio está solicitando o caminho para o arquivo de origem?Se não for, ele não acha que possui símbolos para a pilha de chamadas.Definir o caminho de origem deve funcionar sem a necessidade de mapear o local original exato.

Você pode saber se os símbolos estão carregados observando a janela 'módulos' no Visual Studio.

Supondo que você esteja construindo um PDB, não acho que existam opções que controlem diretamente a quantidade de informações no PDB.Você pode alterar o tipo de otimizações executadas pelo compilador para melhorar a capacidade de depuração, mas isso custará desempenho - como seu colega de trabalho aponta, desabilitar inline ajudará a tornar as coisas mais óbvias no arquivo de falha, mas custará em tempo de execução.

Dependendo da natureza da sua aplicação eu recomendaria trabalhar com arquivos de dump completos se possível, eles são maiores, mas fornecem todas as informações sobre o processo...e com que frequência ele trava de qualquer maneira :)

Answer 7

O Visual Studio está provocando você para o caminho para o arquivo de origem?

Não.

Se não for, então não acha que ele tem símbolos para a pilha de chamadas.Definir o caminho de origem deve funcionar sem precisar mapear o local exato original.

Os símbolos foram carregados com sucesso.Ele mostra a pilha de chamadas, mas clicar duas vezes em uma entrada não me leva ao código-fonte.É claro que posso procurar nos arquivos a linha em questão, mas isso é um trabalho árduo :)