0 - Introduction
Quand Windows rencontre une condition qui peut compromettre le système d'exploitation, le système s'arrête. Cette condition est appelée bug check ou contrôle d'anomalie. Elle est également désignée par le nom d'arrêt du système, d'erreur de noyau, ou d'erreur stop.
Si des vidages de mémoires sur incident sont paramétrés sur le système, un fichier dump ou core dump est généré.
Si un débogueur de noyau (kernel) est actif, le système provoque une rupture. Ainsi le débogueur peut être utilisé pour analyser l'erreur.
Si aucun débogueur n'est actif, un écran bleu est alors affiché avec des informations sur l'erreur. le système est arrêté. Cet écran s'appelle blue screen ou écran bleu (Blue Screen of the Death, BSOD, Écran bleu de la mort, ou encore Malédiction de Bill pour faire drôle !), bug check screen ou écran de contrôle d'anomalie, ou Stop screen, écran d'arrêt .
L'apparence exacte de l'écran bleu dépend de la cause de l'erreur. Ce qui suit est un exemple d'un écran bleu possible signalant une erreur du noyau (le kernel) et du hal avec vidage de la mémoire physique donc création d'un dump :
Dans d'autres circonstances, quelques écrans bleus ressemblent à ceci, signalant le type d'erreur mais sans vidage de la mémoire physique. Il n' y donc pas de génération de dump probablement parce que ce vidage n'a pas été paramétré sur le système :
Le code hexadécimal qui suit le mot "STOP" s'appelle "bug check code " ou "Stop code" (code de contrôle d'anomalie). C'est l'élément le plus important sur l'écran et c'est ce code qu'il va falloir noter pour effectuer d'éventuelles recherches. Il est composé de huit chiffres hexadécimaux après le "0x". Dans les exemples ci-dessus, ces codes sont, pour le premier écran "0x00000079" ou tout simplement "0x79" et pour le second "c000021a" qui est en réalité "0xc000021a".
Chaque "bug check code" possède quatre paramètres associés. Dans le premier écran bleu indiqué ici, chacun des quatre paramètres est affiché après le code de contrôle d'anomalie alors que dans le deuxième exemple d'écran bleu, ces paramètres ont été permutés dans le texte explicatif. Indépendamment de la mise en page, ils apparaîtront toujours de manière séquentielle. Si moins de quatre paramètres sont indiqués, on peut en conclure que les paramètres restants ont la valeur "zéro".
Le reste du texte sur l'écran bleu fournit des informations supplémentaires. Pour quelques "bug check codes", on peut avoir une explication de ce qui s'est produit ou des suggestions sur la façon dont il faut traiter le problème. Mais c'est hélas, rarement le cas.
Dans certaines conditions (heureusement exceptionnelles), Windows affichera seulement la première ligne d'un écran bleu. Cela peut se produire si des services vitaux requis pour l'affichage ont été affectés par l'erreur.
Chaque "bug check code" a également un nom symbolique associé. Habituellement ces noms symboliques n'apparaissent pas sur l'écran bleu. Dans les exemples ci-dessus, le premier écran indique le code d'erreur "0x79" dont le nom symbolique est "MISMATCHED_HAL" (erreur produite par une corruption du fichier "ntoskrnl.exe" ou " hal.dll"), et le deuxième "0xC000021A" dont le nom est "STATUS_SYSTEM_PROCESS_TERMINATED " (erreur dans un sous-système du mode utilisateur tel que Winlogon par exemple).
Partant des indications ci-dessus, nous pouvons définir le dump comme suit :
Et puisque nous serons appelés à en parler, voici d'autres définitions utiles :
Kernel : C'est le noyau et le cœur du système. C'est lui qui fait l'interface entre vos applications et votre matériel. Par exemple, il gère la mémoire, donne l'ordre d'exécution des tâches sur le(s) processeur(s), interagit avec vos périphériques via les pilotes matériels (souris, claviers, etc), s'occupe du réseau etc. Le noyau est composé d'une partie statique à laquelle on peut dynamiquement greffer des modules. La partie statique est utilisée lors du démarrage de votre ordinateur et sera toujours chargée en mémoire, tandis que les modules peuvent être chargés seulement une fois la machine démarrée et uniquement en cas de besoin.
HAL : Non ! Ce n'est pas le Super Ordinateur "HAL" du film "2001 : l'Odyssée de l'Espace ! Il désigne le "Hardware Abstraction Layer", la couche d'abstraction matériel qui est une spécification et un utilitaire logiciel qui traque les périphériques du système. Le but du HAL est d'éviter aux développeurs d'implémenter manuellement le code spécifique à un périphérique. A la place, ils peuvent utiliser une couche connectable qui fournit des informations à propos du dit périphérique, tel que cela se passe par exemple lorsqu'un utilisateur branche ou débranche un périphérique USB.
Hexadécimal : Le système hexadécimal est un système de numération utilisant la base 16, c'est à dire 16 chiffres à partir de "0".
Il utilise les 10 premiers chiffres arabes puis les 6 premières lettres de l'alphabet latin : 0 1 2 3 4 5 6 7 8 9 A B C D E F.
L'usage en fut imposé mondialement par l'entreprise IBM qui commença à l'utiliser en 1963. Actuellement, c'est "Le" standard reconnu. Ci après, les correspondances entres les 3 systèmes principaux :
| Décimal, base 10 : 0 à 9 | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Hexadécimal, base 16 : 0 à F | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | A | B | C | D | E | F |
| Binaire, base 2 : 0 à 1 | 0000 | 0001 | 0010 | 0011 | 0100 | 0101 | 0110 | 0111 | 1000 | 1001 | 1010 | 1011 | 1100 | 1101 | 1110 | 1111 |
Pour ne pas confondre les nombres exprimés en hexadécimal avec ceux pouvant être textuellement identiques en décimal, ils sont généralement précédés du symbole "#". "#10" en hexa équivaut donc à "16" en décimal ! Tout cela est bien entendu conventionnel et le but demeure l'accessibilité humaine car l'ordinateur quant à lui ne comprend que le "binaire". "0" quand le courant électrique ne passe pas et "1" quand il passe. "0" est égal à "faux" et "1" à "vrai" ! Shématiquement bien sûr !
Voila pour la sémantique et désormais nous parlerons le même langage. Dès lors, la question qui se pose est celle de la méthode. Comment faire en sorte pour qu'à chaque crash un dump soit créé, comment analyser ce dump et avec quels outils ?
D'après ce que nous venons de voir, il serait donc intéressant d'avoir à sa dispositions un "crash dump" à analyser si d'aventure il faudra faire face à un BSOD. Nous allons pour cela demander à Windows d'en écrire un en cas de plantage. Pour réaliser cette opération il suffit de modifier quelques paramètres dans les propriétés du poste de travail. La procédure est la suivante :
Une fois arrivé aux paramètres :
Et c'est terminé ! A partir de ce moment, si vous croisez un écran bleu de la mort, vous disposerez d'un dump qui vous permettra de savoir ce qui s'est réellement passé !
Comment ?
Le "Seigneur des fenêtres" Monsieur Bill Gates, nous fournit, et sans bourse délier, deux outils indispensables
pour analyser nos
dump : "Windbg" avec une interface graphique et "kd" en ligne de commande.
Nous utiliserons Windbg, téléchargeable sur le site Microsoft
http://www.microsoft.com/whdc/devtools/debugging/installx86.mspx. Dans la rubrique "Download the Debugging Tools
for Windows", choisissez la dernière version et pensez à visiter régulièrement ce site car les mises à jour sont fréquentes. Installez
les outils (il y en a plusieurs dont "windbg.exe"). L'installation par défaut s'effectue dans
"C:\Program Files\Debugging Tools for Windows".
Afin de pouvoir analyser nos dump, Windbg a besoin d'un bibliothèque de codes, les "symboles"
qui sont également disponibles en ligne.
Nous avons le choix entre télécharger ces symboles en package et les télécharger à la demande. Nous opterons pour la la seconde méthode en laissant l'initiative
du choix des symboles à récupérer à Windbg car ces derniers varient non seulement en fonction des systèmes
d'exploitation mais aussi des Services Pack et des hotfix (vous savez, tous ces patchs et correctifs
de Microsoft du type KB837704 etc.) surtout quand on ne connaît pas les hotfix installés. Ce qui est le cas de l'écrasante
majorité des utilisateurs.
Laissons donc faire Windbg mais il faut lui indiquer où aller les chercher et où les stocker. Procédure :
Ainsi, vous n'avez pas à vous tracasser pour choisir les bons symboles car Windbg va charger automatiquement ceux dont il a besoin et les stocker dans le répertoire "c:\symbols". En fonction de la connexion Internet, le téléchargement peut être plus ou moins long, les fichiers symboles étant très gros (près de 200 Mo).
Pour passer à l'exercice d'analyse des dump, il va falloir attendre l'apparition d'un BSOD (écran bleu de la mort), sinon, et dans le cas où vous éprouvez le besoin de vous familiariser avec Windbg, il est possible d'en provoquer un, soit en utilisant un utilitaire externe soit en suivant la procédure décrite par Microsoft dans son article 244139 du 13 octobre 2006. Cette méthode de génération de BSOD nécessitant une intervention sur la base de registre, la plus grande prudence est requise. Sauvegardez votre BDR avant toute manipulation !.
On peut dormir tranquilles ! Si "Stop screen" il y a, Windows va nous écrire un dump et Windbg va nous servir pour le décortiquer et ainsi corriger le problème ! Vous êtes prêts ? Prenez une pause café (ou un cachet d'aspirine comme le suggérait récemment un internaute dans un forum !) puis Sabre au clair et à l'assaut !
Créer régulièrement des sauvegardes ne coûte rien, juste un peu de temps ... mais cela peut rapporter gros !