none
Outils de debug Windows pour erreur ntdll.dll RRS feed

  • Question

  • Bonjour,

    je cherche un outil permettant de cibler une erreur aléatoire se produisant lors de l'utilisation d'un programme écrit en vb6 et utilisant de multiples DLL écrites en Visual C++ 2005.

    Lorsque que cette erreur se produit un message d'erreur Windows apparait mais il est peu explicite. Existe-t-il un outil, et si oui lequel, qui permettrait de figer le système au moment de l'erreur pour savoir quel est le composant posant problème ?

    merci d'avance pour vos éventuelles réponses.

     

     

    lundi 18 avril 2011 07:37

Réponses

  • Il est peut-être peu explicite pour vous, ce message d'erreur, mais il pourrait ne pas l'être pour nous. ;-)

    Pouvez-vous nous donner plus d'information pour vous aider plus efficacement ?

    Je vais donc être assez large et donc imprécis dans ma réponse.

    Soit vous arrivez "facilement" à reproduire le problème sur une machine ayant un Visual Studio ou un autre débuggeur graphique, la machine d'un développeur est ce type de machine par exelence, et là vous n'avez qu'à demander à Windows de proposer le choix d'un débuggeur sur plantage d'un programme.

     

    Regardez la section "Dr Watson" du lien suivant : http://franck.kiechel.free.fr/dbr_fre/Crash.htm

    -> HKLM \SOFTWARE \Microsoft \Windows NT \CurrentVersion \AeDebug\Debbuger

    Soit vous n'arrivez pas à reproduire le problème sur ce type de machine, et là, il vous reste une pléiade d'outils qui ont tous comme objectifs de générer un fichier de dump ".dmp" de l'exécutable lors d'un plantage.

    Avec ce fichier .dmp et les fichiers .pdb, .dbg et .sym nécessaires, vous pourrez déterminer la fonction précise dans une dll précise où le problème c'est produit, vous la ligne du source si c'est sur une machine ayant les source du module binaire en erreur. Il vous faudra simplement l'ouvrir dans un WinDbg ou un Visual Studio correctement configuré. C'est une simple session de debugging post-mortem qui vous attend, comme sur un bon vieux coredump et gdb sous UNIX.

    http://msdn.microsoft.com/en-us/windows/hardware/gg463009

    Moi, comme un vieux cow-boy de Western qui ne quitte jamais son vieux colt, j'utilise toujours le bon vieux ADPLUS pour générer ces fichiers dmp. Ce n'est pas forcement le plus simple, mais il est puissant et ça fait longtemps que j'ai gravi sa courbe d'apprentissage. Il est aussi dans http://msdn.microsoft.com/en-us/windows/hardware/gg463009.

    Mais, il y a aussi, Dr Watson, gflags, procdump. http://technet.microsoft.com/en-us/sysinternals/dd996900


    Paul Bacelar, Ex - MVP VC++
    lundi 18 avril 2011 19:04
    Modérateur

Toutes les réponses

  • Il est peut-être peu explicite pour vous, ce message d'erreur, mais il pourrait ne pas l'être pour nous. ;-)

    Pouvez-vous nous donner plus d'information pour vous aider plus efficacement ?

    Je vais donc être assez large et donc imprécis dans ma réponse.

    Soit vous arrivez "facilement" à reproduire le problème sur une machine ayant un Visual Studio ou un autre débuggeur graphique, la machine d'un développeur est ce type de machine par exelence, et là vous n'avez qu'à demander à Windows de proposer le choix d'un débuggeur sur plantage d'un programme.

     

    Regardez la section "Dr Watson" du lien suivant : http://franck.kiechel.free.fr/dbr_fre/Crash.htm

    -> HKLM \SOFTWARE \Microsoft \Windows NT \CurrentVersion \AeDebug\Debbuger

    Soit vous n'arrivez pas à reproduire le problème sur ce type de machine, et là, il vous reste une pléiade d'outils qui ont tous comme objectifs de générer un fichier de dump ".dmp" de l'exécutable lors d'un plantage.

    Avec ce fichier .dmp et les fichiers .pdb, .dbg et .sym nécessaires, vous pourrez déterminer la fonction précise dans une dll précise où le problème c'est produit, vous la ligne du source si c'est sur une machine ayant les source du module binaire en erreur. Il vous faudra simplement l'ouvrir dans un WinDbg ou un Visual Studio correctement configuré. C'est une simple session de debugging post-mortem qui vous attend, comme sur un bon vieux coredump et gdb sous UNIX.

    http://msdn.microsoft.com/en-us/windows/hardware/gg463009

    Moi, comme un vieux cow-boy de Western qui ne quitte jamais son vieux colt, j'utilise toujours le bon vieux ADPLUS pour générer ces fichiers dmp. Ce n'est pas forcement le plus simple, mais il est puissant et ça fait longtemps que j'ai gravi sa courbe d'apprentissage. Il est aussi dans http://msdn.microsoft.com/en-us/windows/hardware/gg463009.

    Mais, il y a aussi, Dr Watson, gflags, procdump. http://technet.microsoft.com/en-us/sysinternals/dd996900


    Paul Bacelar, Ex - MVP VC++
    lundi 18 avril 2011 19:04
    Modérateur
  • Bonjour, mrZeby,

    Est-ce que les explications de Paul sont ce que vous cherchez ou vous avez besoin de plus des informations sur ce sujet ? Merci pour partager vos résultats avec nous, afin que d'autres personnes avec le même problème puissent profiter de cette solution.

    Cordialement,

    Cipri


    Suivez MSDN sur Twitter   Suivez MSDN sur Facebook


    Ciprian DUDUIALA, MSFT  
    •Nous vous prions de considérer que dans le cadre de ce forum on n’offre pas de support technique et aucune garantie de la part de Microsoft ne peut être offerte.

    vendredi 22 avril 2011 08:48
  • Bonjour,

    désolé pour le manque de réponse de ma part mais des changements de priorités ont détourné mon attention du problème que je signalais et sur lequel je n'ai pas eu le temps de refléchir. A ma connaissance, les problèmes ont été supprimés en supprimant une série de développement soupsonnés à l'origine du problème.

    Les problèmes en question se produisaient sur une machine de développement sur laquelle les environnements de travail (vs 2005 c++ et visual studio 98) fonctionnaient en mode débug mais aucune erreur n'a jamais pu être ciblée d'avantage.

    mardi 4 décembre 2012 15:01