par Mark Russinovich
Même si Windows 2000 est en net progrès par rapport à Windows NT 4.0 sur la stabilité,
vous pouvez encore subir des plantages. L'analyse des fameux "écrans bleus" rencontrés
en cas de défaillances peut vous éviter certains crashes ou des heures de réinstallation.Indiscutablement, Windows 2000 apporte à Windows un niveau de fiabilité inconnu
jusqu'ici. Avec la réécriture par Microsoft du code de base du système d'exploitation,
afin de traiter les situations inhabituelles, l'énorme effort de test entrepris
par l'éditeur, et l'introduction du nouvel outil DriverVerifier, les écrans bleus
vont se raréfier dans les systèmes Windows 2000. Mais beaucoup d'entreprises dépendent
encore largement de Windows NT 4.0. De plus, bien que les pilotes de périphériques
accompagnant Windows 2000 subissent des tests complets à charge élevée, ainsi
qu'une validation de conformité pour obtenir la certification WHQL (Windows Hardware
Quality Labs) de Microsoft, des bugs non détectés peuvent encore se produire.
En outre, si des applications contenant des pilotes non destinés à du matériel,
par exemple des détecteurs de virus, des utilitaires de gestion de quotas, ou
des progiciels de chiffrements, sont installées, le système Windows 2000 peut
se retrouver avec des drivers n'ayant pas subi les tests WHQL, même si la stratégie
de signature des drivers du système est configurée pour empêcher les drivers non
testés. Ainsi, même s'ils vont se raréfier dorénavant, les écrans bleus peuvent
malgré tout encore surgir occasionnellement et, dans ce cas, les informations
nécessaires pour les analyser prendront toute leur importance. La différence est,
dans ce cas, entre quelques minutes pour désinstaller une application ou plusieurs
heures pour réinstaller complètement le système d'exploitation.
Beaucoup d'administrateurs systèmes s'abstiennent d'explorer les options de vidage
sur incident de Windows 2000 et Windows NT 4.0, estimant leur utilisation trop
complexe. Bien que la documentation de Microsoft sur le débogage se soit améliorée
l'an dernier, elle reste tout de même orientée vers les développeurs de pilotes
de périphériques. Mais même si un vidage sur incident sur cinq seulement contient
des informations utiles, il vaut vraiment la peine d'en savoir un peu plus sur
l'analyse du vidage sur incident.
Cet article facilitera l'apprentissage de cette fonction. Il commence par les
bases de configuration d'un système pour sauvegarder un vidage sur incident en
cas de plantage du système, puis explique comment se procurer les outils nécessaires
pour examiner un vidage sur incident, et se termine par des astuces pour glaner
les informations utiles, sans oublier la présentation d'un outil d'analyse de
vidage automatisée en constante évolution, Kanalyse (Kernel Memory Space Analyzer).
Comprendre les raisons des plantages
La première étape d’une analyse de vidage sur incident consiste à garantir un
vidage de la mémoire en cas de plantage d’un système. L’accès aux options de vidage
sur incident de Windows NT 4.0 se fait par l’onglet Démarrage/Arrêt de l’applet
Système du Panneau de configuration. La Figure 1 montre la page Démarrage/Arrêt,
dans laquelle doit être cochée la case Ecrire des informations de débogage et
doit être saisi le nom du fichier où sera enregistré le vidage. Les autres options
de la page dirigent le comportement du système dans sa réaction à un incident
et assurent la consignation d’un événement dans le Journal du système, avec l’envoi
d’une alerte administrative et une réinitialisation automatique.
 |
Les fichiers de vidage sur incident de Windows NT 4.0 comprennent une copie du
contenu de la mémoire physique d’un ordinateur. Il convient donc de s’assurer
que le système possède l’espace-disque adéquat pour sauvegarder et restaurer un
vidage. Il faut commencer par configurer un fichier d’échange dans le volume d’initialisation
(contenant le répertoire \winnt). Ce fichier doit être suffisamment grand pour
stocker la mémoire du système, plus 1 Mo. Le volume qui stocke le fichier d’échange
(qui est aussi par défaut le volume d’initialisation) doit avoir légèrement plus
d’espace disque libre que la mémoire physique de l’ordinateur.
Les fichiers de vidage sur incident de Windows NT 4.0 comprennent une
copie du contenu de la mémoire physique d’un ordinateur
Ces exigences sont dues à la mise en oeuvre, par le noyau, de la fonction de vidage
sur incident. Pendant le processus d’initialisation, le système d’exploitation
vérifie les options de vidage sur incident du registre dans la sous-clé HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl.
Si une ou plusieurs options sont activées, le système génère une topographie des
blocs de disques occupés par le fichier d’échange du volume d’initialisation et
la sauvegarde en mémoire. Le système détermine aussi le pilote de périphérique
qui gère le volume d’initialisation et calcule un total de contrôle de l’image
en mémoire du pilote et les structures de données qui doivent être intactes pour
permettre au pilote d’effectuer les E/S disque. En cas d’incident, le noyau vérifie
l’intégrité de la topographie du fichier d’échange, le programme de gestion du
disque et les structures de contrôle du programme de gestion du disque. Si celles-ci
sont intactes, le noyau appelle des fonctions d’E/S du programme de gestion de
disque, spécifiquement chargées de vider la mémoire en cas de plantage du système.
Ces fonctions d’E/S sont autonomes et ne dépendent pas de services du noyau, puisque
le code lié au vidage sur incident ne doit faire aucune supposition sur les éléments
du noyau ou les pilotes de périphériques susceptibles d’avoir été compromis par
la situation ayant entraîné l’incident. Le noyau enregistre le contenu de la mémoire
dans la topographie du secteur du fichier d’échange, pour éviter de dépendre des
pilotes de système de fichier. Le noyau vérifie l’intégrité de chaque composant
impliqué dans le processus de vidage avant de continuer, parce que l’enregistrement
directement dans les secteurs d’un disque risque de détruire des données, si ces
secteurs se trouvent à l’extérieur du fichier d’échange. Un fichier d’échange
doit avoir 1 Mo de plus que la mémoire physique, car quand le noyau enregistre
le vidage, il enregistre aussi un en-tête contenant la signature d’un vidage sur
incident et les valeurs de plusieurs variables essentielles du noyau. Bien que
l’en-tête soit nettement plus petit qu’un Mo, le système dimensionne un fichier
d’échange par mégaoctets.
Lors de l’initialisation d’un système, le processus de gestion des sessions (\winnt\system32\smss.exe)
initialise les fichiers d’échange du système avec la fonction native NtCreatePagingFile
pour créer chaque fichier. NtCreatePagingFile détermine si le fichier d’échange,
qu’il initialise, existe et, dans le cas contraire, s’il a un en-tête de vidage.
En présence d’un en-tête de vidage, NtCreatePagingFile renvoie un code spécial
au gestionnaire de session. Ainsi, lorsque ce dernier exécute le gestionnaire
de connexion (\winnt\system32\winlogon.exe) pour lancer le processus Winlogon,
il informe ce dernier de l’existence d’un vidage sur incident. Winlogon exécute
alors l’application SaveDump (\winnt\system32\savedump.exe), qui examine l’en-tête
du vidage pour décider des actions de réaction à mener en cas d’incident. Si l’en-tête
indique la présence d’un vidage de mémoire, SaveDump copie le contenu du fichier
d’échange dans le fichier de vidage sur incident spécifié dans le dialogue de
démarrage et d’arrêt. Pendant l’enregistrement du fichier de vidage par SaveDump,
le système n’utilise pas la partie du fichier d’échange contenant le vidage sur
incident. Du coup, la quantité de mémoire virtuelle disponible pour le système
et les applications diminue de la taille du vidage et les messages contextuels
de la boîte de dialogue peuvent signaler que le système est à court de mémoire
virtuelle. Son exécution terminée, SaveDump informe le gestionnaire de mémoire
qu’il a fini de sauvegarder le vidage et ce dernier rend alors pour l’utilisation
générale la partie du fichier d’échange contenant le vidage. Après la sauvegarde
d’un fichier de vidage, SaveDump effectue les autres options spécifiées pour le
traitement de l’incident, comme, par exemple, l’envoi d’une alerte à un administrateur
ou la consignation d’un événement dans le journal du système.
La copie du contenu de la mémoire du système au moment d’un incident contient
souvent des informations inutiles pour l’analyse d’un vidage sur incident. Comme
un incident résulte toujours d’un problème survenant pendant l’exécution en mode
kernel, les données des applications en mode utilisateur ne sont pas généralement
pertinentes pour le diagnostic. La mémoire du mode kernel comprend toutes les
structures de données du système d’exploitation et des pilotes, ainsi que le code
exécutable pour les pilotes de périphériques et le noyau. C’est pourquoi Windows
2000 introduit une option de vidage sur incident qui permet de ne sauvegarder
que la mémoire du mode kernel. Cette option peut réduire significativement la
taille d’un fichier de vidage, qui devient ainsi plus rapide à générer et à copier
et plus pratique à stocker et à échanger avec le personnel du support technique.
Un système ordinaire à 128 Mo de mémoire peut très bien n’avoir que 40 Mo de vidage
de mémoire du mode kernel. La Figure 2 montre la boîte de dialogue des options
d’incident : Démarrage et Récupération de Windows 2000, à laquelle on accède en
cliquant sur l’onglet Avancé de l’applet Système Démarrage et récupération.
 |
Windows 2000 comporte aussi une option minidump. Les minidumps, que la liste déroulante
Enregistrer les informations de débogage de la boîte de dialogue Démarrage et
récupération appelle Petits vidages de mémoire, sont des vidages sur incident
de 64 Ko, qui stockent un minimum d’informations potentiellement utiles, comme
le code d’incident de l’écran bleu, une liste des pilotes chargés, des informations
sur le process et le thread en cours d’exécution au moment de l’incident, et une
photographie instantanée de la pile (c’est-à -dire un historique des dernières
fonctions appelées). Les données des mini-vidages, qui sont pratiquement les mêmes
que celles affichées par Windows NT 4.0 sur les écrans bleus, contiennent parfois
suffisamment d’informations pour identifier la cause d’un incident. Les mini-vidages
sont petits et n’écrasent pas les précédents. Leur nom a la forme minimmjjaann.dmp,
sachant que mm, jj et aa représentent respectivement le mois, le jour et l’année,
et nn un nombre unique distinguant les mini-vidages générés le même jour. Par
défaut, Windows 2000 sauvegarde les fichiers des mini-vidages dans le répertoire
\%systemroot%\minidump. Les mini-vidages s’analysent de la même façon que les
vidages complets et ceux du noyau seul. Toutefois, sur les systèmes possédant
l’espace-disque nécessaire, je recommande d’activer le vidage de la mémoire du
noyau.
Téléchargez cette ressource
Sécuriser votre système d’impression
Longtemps sous-estimée, la sécurisation d’un système d’impression d’entreprise doit être pleinement prise en compte afin de limiter le risque de fuite d’informations sensibles. Voici les 3 principales précautions à prendre.
Les articles les plus consultés
A travers cette chaîne
A travers ITPro
Les plus consultés sur iTPro.fr
- Facturation électronique : les craintes des entreprises liées à la réforme
- Cyber-assurances, priorité ou faux remède pour les TPE et PME ?
- Success Stories : 3 histoires et 3 Intelligences Artificielles
- NIS2: cauchemar des décideurs européens pour la conformité
- Fossé entre exigences professionnelles et compétences
