none
Faut-il, vraiment, le PDB original pour débugger un minidump sous VS debugger ? RRS feed

  • Question

  • Le contexte : un binaire myapp.exe se plante dans sa version debug en plateforme de production et génére un minidump. J'ai récupéré la bonne version du code source de myapp.exe. Malheureusement, je n'ai pas le PDB myapp.pdb correspondant.
    Comment exploiter un minidump pour explorer les fichiers sources d'un binaire à partir de la "Call Stack" sans le PDB original?

    J'ai re-compilé le binaire myapp.exe avec les mêmes sources pour obtenir un fichier myapp.pdb et myapp.exe mais
    le minidump reste inexploitable avec le nouveau pdb généré :
    l'erreur suivante dans la l'onglet output :
    'minidump_144c_2011-12-12_03-42-37-419_138c.dmp': Loaded 'D:\xxxx\Bin\myapp.exe', No symbols loaded.
    l'erreur suivante au niveau de l'onglet "Call Stack", Quand je double-click l'entrée juste avant le plantage:
    > myapp.exe!0047764c()
    "There is no source code available for the current location."

    Faut-il, vraiment, le PDB original pour débugger un binaire ou une dll sous VS debugger ?

    mercredi 14 décembre 2011 15:14

Réponses

  • Malheureusement oui, il faut absolument le PDB original pour deboguer un binaire avec le débogueur de Visual Studio.

    La raison est que deux compilations du même code peuvent générer un binaire différent. Par exemple dans une compilation, ce bloc de code placé avant cet autre partie de code parce que la compilation de ce fichier a été terminée un peu plus tard que la compilation de cet autre fichier.

    Du coup, par sécurité, Visual Studio vérifie que le timestamp du fichier pdb et du binaire associé sont bien égaux. Une description de ce problème est disponible (en anglais) sur ce blog MSDN http://blogs.msdn.com/b/jimgries/archive/2007/07/06/why-does-visual-studio-require-debugger-symbol-files-to-exactly-match-the-binary-files-that-they-were-built-with.aspx

    Dans votre cas c'est très gênant et il n'y a pas de moyen de contourner ce problème avec le débogueur de Visual Studio. Par contre il est possible d'utiliser le débogueur Windbg à la place du débogueur de Visual Studio. Ce débogueur permet de charger un autre PDB que le PDB original pour débogueur un programme. Le problème est que Windbg est beaucoup moins facile à utiliser que Visual Studio... mais c'est la seule solution !

    mercredi 14 décembre 2011 17:37
    Auteur de réponse

Toutes les réponses

  • Malheureusement oui, il faut absolument le PDB original pour deboguer un binaire avec le débogueur de Visual Studio.

    La raison est que deux compilations du même code peuvent générer un binaire différent. Par exemple dans une compilation, ce bloc de code placé avant cet autre partie de code parce que la compilation de ce fichier a été terminée un peu plus tard que la compilation de cet autre fichier.

    Du coup, par sécurité, Visual Studio vérifie que le timestamp du fichier pdb et du binaire associé sont bien égaux. Une description de ce problème est disponible (en anglais) sur ce blog MSDN http://blogs.msdn.com/b/jimgries/archive/2007/07/06/why-does-visual-studio-require-debugger-symbol-files-to-exactly-match-the-binary-files-that-they-were-built-with.aspx

    Dans votre cas c'est très gênant et il n'y a pas de moyen de contourner ce problème avec le débogueur de Visual Studio. Par contre il est possible d'utiliser le débogueur Windbg à la place du débogueur de Visual Studio. Ce débogueur permet de charger un autre PDB que le PDB original pour débogueur un programme. Le problème est que Windbg est beaucoup moins facile à utiliser que Visual Studio... mais c'est la seule solution !

    mercredi 14 décembre 2011 17:37
    Auteur de réponse
  • Il est toujours intéressant de connaître des outils comme WinDBG, mais l'utiliser avec un PDB potentiellement incorrecte, c'est un peu rude (très doux euphémisme).

    Je préfèrerais utiliser le débuggeur sans PDB qu'avec un pdb entièrement faussé par une modification/différence dans la configuration de VS la plus minime.

    A moins d'avoir une usine de fabrication pour générer les exe ET les PDB de manière contrôlé, je n'essayerai même pas. Si vous avez des notions d’assembleur utiliser WinDBG sans les PDB, si nécessaire.

     

    Si l'exe recompilé est bien identique à celui qui a planté, pourquoi ne pas l'utiliser pour refaire le plantage ?

    Il faut toujours générer ET archiver les pdb comme les exe produits, aussi bien en Release qu'en DEBUG.


    Paul Bacelar, Ex - MVP VC++
    vendredi 16 décembre 2011 17:18
    Modérateur