Comment devenir Sherlock Holmes et diagnostiquer des exceptions comme un pro en .Net

J’utilise dans mes projets depuis assez longtemps une classe d’exception personnalisée qui capture le maximum d’informations lorsqu’une erreur se produit pour m’aider à la diagnostiquer.  Certains types d’erreurs sont notoires pour être résistants à l’identification tel que le fameux La référence d’objet n’est pas définie à une instance d’un objet.  Dans ce cas, le contexte de l’exception fourni une description précise de la méthode contenant la référence nulle mais reste peu bavard sur l’objet concerné.

La méthode habituelle pour trouver le problème débute par tenter de reproduire l’erreur.  Ce qui marche quelques fois, après tout avec un peu de chance et d’observation on peut tomber sur la bonne ligne de code.  Si on est moins chanceux, la correction du problème peut être difficile et il peut être nécessaire de se fier à la mémoire de l’utilisateur qui est normalement une source peu fiable après cinq minutes.


Si vous utilisez Windows depuis un petit bout de temps, vous avez sûrement vécu un des fameux écran bleu de la mort.  Lorsqu’un écran bleu arrive, Windows génère un fichier contenant une partie de la mémoire et le joint avec un rapport d’erreur qui est envoyé au service technique.  Il est possible d’utiliser le même processus pour améliorer la gestion d’erreur dans nos applications assez facilement surtout si le processus de compilation est automatisé.

La première étape se passe lors de la compilation d’une nouvelle version du logiciel.  À ce moment, il faut compiler l’application en mode Release tout en générant les symboles de débogage (PDB).  Les symboles de débogage vont permettre d’analyser le fichier de mémoire préparé lors de la création du rapport d’erreur.  Les symboles ne seront pas remis au client pour sauver de l’espace et il n’en ont pas besoin de toute façon.

En résumé, on doit conserver les fichiers suivants pour chaque version produite du logiciel:

  • tous les fichiers exécutables (exe)
  • toutes les librairies (dll)
  • les fichiers de débogage (pdb)
  • le code source bien évidemment

La deuxième phase est de générer le fichier de mémoire plus communément appelé minidump.  Une bonne classe de base pour se partir peut être trouvé sur le blog de Jochen Kalbach.  Il reste à l’intégrer dans notre code ce qui va donner quelque chose ressemblant au code ci dessous.


try
{
    Object test = null;
    test.ToString();
}
catch (Exception exception)
{
    // Générer le fichier de mémoire minidump
    MiniDumper.Write(@"c:\CrashDump.dmp", MiniDumper.Typ.MiniDumpNormal);
    // Capturer le maximum d'informations sur l'erreur
    // Transmettre le rapport d'erreur avec le fichier de mémoire
}

La dernière phase est maintenant l’analyse du rapport d’erreur. Le meilleur outil que je connaisse pour le faire est celui que la plupart des programmeurs en .Net connaissent bien : Visual Studio.  Il faut mettre dans le même répertoire le fichier compilé (exe ou dll), les symboles de débogage (pdb) correspondant et le fichier de mémoire (dmp).

En ouvrant le fichier de mémoire avec Visual Studio vous aurez accès à la pile d’exécution contenue dans le rapport d’erreur.  Il ne reste qu’à configurer quelques options pour rendre le tout plus facile à comprendre.  Voici ce qui a bien fonctionné pour moi.

  1. Configurez les chemin d’accès aux symboles de débogage au répertoire où se trouve les symboles de débogage pour le fichier en cours d’analyse (pdb).
  2. Démarrez le débogage avec Debug with mixed.
  3. Attendez que le logiciel s’arrête.
  4. Retournez dans l’écran de configuration des chemins d’accès et chargez tous les symboles.  Visual Studio va demander de créer un répertoire pour la cache.  Il est supposé les charger automatiquement mais ça ne semble pas marcher dans mon cas.
  5. Validez que le code l’option Show external code est activée dans la fenêtre Call stack sinon votre code ne sera peut-être pas visible.

La ligne précise de l’erreur sera affichée avec un MiniDumpNormal.  Un léger décalage de ligne peut avoir lieu suite à des optimisations faites par le compilateur mais la ligne indiquée est normalement assez proche.  Un fichier plus détaillé permet d’examiner les variables et plusieurs autres informations.  Bon débogage !

Publicités