C'est l'étape la plus importante et la plus délicate. Pour analyser le dump, lancez "windbg.exe".
A partir de là, que va faire Windbg ?
Enfin, il ouvre une nouvelle fenêtre résumant le succès de cette opération et une première information sur le crash :
4/1 - La commande "!analyze -v"
Nous voyons tout de suite que Windbg, quand il a chargé le dump, a relevé une faute commise par un fichier "i8042prt.sys". Le problème semble cerné dans ce cas. Mais souvent ce n'est pas si évident que cela. Il faut donc demander à Windbg de parler un peu plus. La commande "!analyze -v" qu'i faut saisir en bas de la fenêtre après "kd >" va permettre d'avoir des informations supplémentaires et savoir par exemple qui a généré la faute. Laissons tomber notre "crash" manuel et volontaire et voyons ce qui peut se passer dans des cas réels.
Une fois la commande "!analyze -v" lancée, nous avons une première indication et si vous avez bien suivi ce que nous rapportions dans la page précédente, vous aurez compris que :
Dans ce cas précis, nous sommes face à un driver (pilote) qui a tenté d'utiliser une adresse invalide. Si vous venez juste d'installer ou de mettre à jour un pilote, vous n'êtes pas loin de la solution du problème ! Mais pas de précipitation ! Voyons ce que "!analyse -v" nous dit en plus :
Ce sont les 4 arguments du "bug check code" (voir page précédente). Le driver en question a tenté d'accéder à l'adresse mémoire 0x00000004 (Arg1 : 00000004) en demandant une interruption de haute priorité (Arg2 : 00000002), échec d'écrire (Arg3 : 00000001) dans un espace mémoire dont l'adresse est f832035c (Arg4 : f832035c) ! Visiblement ce pilote n'est pas bon car il ne respecte pas les règles ! Le BSOD l'aurait indiqué ainsi :
Nous ne détaillerons pas tous les champs qui suivent vu leur caractère plus ou moins technique et qui sont de peu d'utilité pour le dépannage. Nous allons par conséquent dérouler les infos pour arriver à :
Il s'agit d'un driver (pilote) puis à :
qui nous identifie le fautif : un port USB dont le pilote est "USBPORT.SYS". Nous tenons le coupable ! Et Windbg va plus loin encore puisqu'en affichant :
et si vous êtes connectés à Internet, le débogueur essaye d'atteindre une base de données de résolutions des problèmes connus mises à jour par Microsoft et contenant des centaines de pages Web. Si une solution est trouvée pour votre problème, il vous en indique l'URL qui, dans ce cas est : "http://oca.microsoft.com/resredir.asp?sid=62&State=1 ". Il n'y a plus qu'à aller récupérer l'information ou le hotfix. Dans le cas contraire, il faudra chercher ... Nous verrons comment dans la partie "Correction du problème".
4/2 - La commande "!process"La recherche peut encore être poussée plus loin si on souhaite trouver un processus associé à ce pilote. On utilise la commande "!process" qui permet de voir les processus présents en mémoire. En les listant tous il devient possible de repérer celui qui nous intéresse. Pour cela les paramètres à fournir "!process" sont nuls, ce qui donne "!process 0 0", comme le montre l'exemple ci-dessous :
Pour chaque processus listé, nous disposons alors des informations permettant de l'identifier avec précisons. Prenons comme exemple le processus surligné en bleu dans le tableau ci-dessus et relevons ce qui peut être utile :
Le processus obtenu on peut encore développer les informations le concernant, toujours à l'aide de "!process" mais cette fois en précisant les indicateurs. Au lieu de "!process 0 0", nous mentionnerons, à la place du premier "0", soit son adresse, soit son PID soit son nom. Le deuxième "0" est généralement fixé à "7" pour obtenir un maximum d'informations. Par exemple : "!process 809258e0 7", "!process 0044 7" ou encore "!process spoolss.exe 7".
Voilà pour notre analyse. Elle vous aidera dans pas mal de cas et quasiment systématiquement pour les problèmes de driver.
Notre très sympathique Windbg a cerné le nom du pilote à l'origine du problème et éventuellement un processus associé mais il n'a pas trouvé de correctif chez Microsoft. Il ne dit pas non plus à quoi peut correspondre ce driver. Pour quand même rétablir la situation, plusieurs solutions possibles à tenter successivement :
5/1 - recherche dans les disques :Faire une recherche dans les disques pour connaître l'emplacement du pilote. Démarrer, Rechercher puis Tous les fichiers et tous les dossiers. Saisir le nom du pilote "usbport.sys" et "Rechercher" ! Une fois trouvé, clic droit dessus puis "Propriétés".
Une visite sur le site du fabriquant permet de savoir s'il existe une mise à jour ou un patch.
5/2 - Recherche dans le Gestionnaire de périphériques :Poste de travail, Propriétés, Matériel, Gestionnaire de périphériques. En règle générale, si un pilote fonctionne mal, le gestionnaire de périphérique le signale. Si c'est le cas, vérifier et éventuellement réinstaller. Si Windows ne parvient pas à réinstaller, recueillir les informations sur le matériel. Un exemple :
Sélectionner un matériel, clic droit puis "Propriétés", "Pilote" et "Détails du pilote".
Munis de ces informations, aller sur le site du fabriquant et télécharger la bonne version, la mise à jour ou le patch.
5/3 - Appel à Microsoft
Le problème peut également être soumis aux techniciens de Microsoft. Sur le site "http://oca.microsoft.com", il est possible de déposer ses minidump's. Ils seront analysés et une réponse pertinente est proposée. Suite à un crash, Windows XP affiche généralement une boîte de dialogue demandant d'envoyer le rapport d'erreur à Microsoft. Il est judicieux de le faire car non seulement cela permet à Microsoft de savoir d'où vient le problème et le corriger, mais aussi de demander aux constructeurs de matériels d'améliorer leurs drivers.
5/3 - Recherche sur le NetSi enfin le sort s'acharne et qu'il s'avère impossible de savoir à quoi correspond le pilote signalé fautif par Windbg, le dernier recours c'est la recherche sur Google qui fournira obligatoirement une réponse.
Utiliser les dump's pour résoudre les problèmes rencontrés sous Windows XP n'est pas, comme nous venons de le voir, une opération insurmontable. Elle reste à la portée de tous, moyennant un peu d'attention et de méthode. Mais mieux vaut prévenir que guérir et la règle à observer consiste à ne mettre dans sa machine que des périphérique de bonne qualité et compatibles Windows XP. De nombreux problèmes seront ainsi évités.
Le constat à faire c'est que tout est facile (ou du moins possible ...) à partir du moment où l'on peut accéder à ses disque. Que ce soit pour lancer la console de récupération ou pour analyser un dump, il est obligatoire d''être sur les lieux du crime pour pouvoir mener son enquête et arrêter le coupable. Il faut également être en possession de l'armement nécessaire, en l'occurrence le CD d'installation de Windows XP !
Mais, direz-vous, tout cela me rebute, c'est trop compliqué et en plus, je n'ai pas de CD Windows XP ! Alors ? C'est "fichu" ?
Rassurez vous ! Ce n'est pas encore "fichu" ! Il existe d'autres moyens pour vous éviter une reinstallation avec formatage et donc perte de données ! Nous verrons cela dans d'autres chapîtres à venir.
Créer régulièrement des sauvegardes ne coûte rien, juste un peu de temps ... mais cela peut rapporter gros !