J’ai dernièrement fait quelques recherches sur la génération de fichiers de diagnostiques et préparé un article sur le sujet. Nous avons ensuite ajouté cette fonction dans un de nos programmes. L’objectif étant de générer automatiquement un fichier MiniDump lorsque certains types d’exception se produisent. Le fichier MiniDump est ensuite compressé et joint au message d’erreur qui est envoyé à notre système de suivi. C’est génial! Sauf qu’à partir de ce moment, plus personne ne pouvait nous envoyer de message d’erreur.
En effet, dix minutes après l’installation de la mise à jour, quelqu’un a essayé de nous envoyer un rapport d’erreur. L’erreur concernait un objet nul ce qui provoquait la création d’un fichier de mémoire. Tout se passait comme prévu jusqu’au moment où on débute la création du fichier de mémoire. Le logiciel plantait à nouveau à ce moment ce qui repartait le processus de gestion d’erreur et on tournait en rond.
J’ai ensuite découvert que la fonction System.Runtime.InteropServices.Marshal.GetExceptionPointers peut retourner un objet IntPtr.Zero au lieu de d’un pointeur correctement formé dans quelques cas assez rares. Évidemment, on a rencontré un de ces cas dix minutes après avoir installé la mise à jour. Le correctif est bien expliqué dans cet article :
http://blogs.msdn.com/b/dondu/archive/2010/10/24/writing-minidumps-in-c.aspx
Nous avons testé la modification et tout va beaucoup mieux.
La morale de l’histoire? Il faut toujours se garder sous la main quelques ordinateurs avec des configurations différentes pour tester nos applications.
P.S.
L’image est tiré d’un article sur Grace Hopper une des pionnières de l’informatique. Son histoire est très intéressante et nous ramène à un époque où débugger un ordinateur pouvait littéralement vous électrocuter.
Information générée par une source non certifiée 