Q. Quelle informations sont présentées dans l'ecran bleu de la mort ?

R. Le système NT a deux niveaux de bases ,le user (utilisateur) et le kernel (noyau) . L'utilisateur ne peut pas accéder directement aux ressources matérielles et, il est limité aux adresses utilisable en Ring 3 (Basse priorité) .Si  un programme tournant en mode utilisateura un problème , le système arrête le processus et génère un message d'erreur. Comme chaque application fonctionne dans son propre environnement cela n'affecte pas les autres processus en cours. Les composants utilisés couramment sont :

• Processus de connections
• Les sous-systèmes de sécurité.
• Les applications Win32 et leurs sous-systèmes.
• Les applications OS/2 et leurs sous-systèmes.
• Les applications POSIX et leurs sous-systèmes.

NT 4.0 a introduit un changement car le noyau fonctionne plus vite (il est en Ring 0) et que les pilotes d'affichages et d'impressions ont étés déplacer du mode utilisateur vers le mode noyau. Le  noyau est un processus privilégié et  il peut accéder directement aux ressources mémorielles et matérielles. Les erreurs du noyau ne sont donc pas récupérable et conduisent invariablement au redémarrage. L'ecran bleu de la mort est un mécanisme intégré qui arrête tous processus qui risque de corrompre le système ou les données.  Cela veut donc dire qu'un pilote graphique ou d'impressions ne peut pas planter NT . Les composant du noyau sont :

• Différents gestionnaire ,comme ceux des entrées-sorties , des objets , du graphismes et de la mémoire virtuelle.
• Le micro noyau qui fournit les commandes de base du système.
• La couche d'abstraction matérielle.
• les pilotes de périphériques.

Mais que montre les Écrans Bleu De La Mort ? Below is the basic structure of the BSOD, however what you see will differ and you may not have some of the sections as I'll explain below

--------------------------------------------------
Section 1: Debug Port Status Indicators
DSR CTS SND
--------------------------------------------------
Section 2: BugCheck Information
*** STOP: 0x0000000A (0x00000002,0x00000000,0xDB30442D)
IRQL_NOT_LESS_OR_EQUAL *** Address db30442d has base at db300000 - matrxmil.SYS

CPUID: GenuineIntel 5.2.4 irql:1f SYSVER 0xF0000565
--------------------------------------------------
Section 3: Driver Information

etc..
--------------------------------------------------
Section 4: Kernel Build and Stack Dump
Address dword dump Build [1381] -Name
xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx - matrxmil.SYS
xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx - ntoskrnl.exe
xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx - ntoskrnl.exe
etc..
--------------------------------------------------
Section 5: Debug Port Information
Restart and set the recovery options in the system control panel
or the /CRASHDEBUG system start option if this message reappears,
contact your system administrator or technical support group

OR if you system is started with /debug or /crashdebug

Kernel Debugger Using : Com2 (Port 0x2f8, Baud Rate 9600)
Beginning Dump of physical memory
Physical memory dump complete. Contact your system administrator or
technical support group

Section 1: Cette section ne sera affiché que si vous avez lancez le systeme en mode /debug ou /crashdebug .Pour savoir si votre débuggeur est actif, regarder lors du démarrage si le message [debugger enabled] est affiché. S'il ne l'est pas suivez les instructions suivantes :

1. Modifier le fichier boot.ini pour qu'il soit modifiable en tapant :
   attrib c:\boot.ini -r -s
2. Ouvrez le fichier et dans la section [operating systems] ajoutez /debug ou /crashdebug . les autres options sont /Debugport et /Baudrate qui fixe le port COM a utilisé et le débit de ce port .Par exemple :
   [operating systems]
   multi(0)disk(0)rdisk(0)partition(0)\WINDOWS="Windows NT" /debug /debugport=com3 /baudrate=9600
3. Enregistrer le fichier   
4. Redonnez a boot.ini ses attributs originaux :
   attrib c:\boot.ini +r +s

Section 2: Cette section contient le code de l'erreur (Ou BugCheck) avec les paramètres définis par les devellopeurs (Définit par l'appel a la fonction KeBugCheckEx() . Dans notre exemple BugCheck a pour valeur 0x0000000A IRQL_NOT_LESS_OR_EQUAL ce qui veut dire qu'un processus a essayer d'accèder a la mémoire paginée avec un priorité trop élevée. C'est générale dut a un pilote de périphérique.

Pour une liste des codes plus complete allez voir dans la base de connaissance a la question Q103059 .

Section 3: Elle liste tous les pilotes chargés au moment du crash . Elle est divisée en deux cotés , a trois colonnes chacun. La première colonne est le pointeur de temps exprime en secondes écoulé depuis le premier janvier 1970. On peut le convertir en temps plus appréciable avec le programme cvtime.exe (f$cvtime sur VMS :-) ).

Section 4: Elle montre le numéro de build du systeme et vidage de pile qui montre les adresses utilisés part le module défaillant.

Section 5: Elle ne sera affiché que si vous utilisez le mode /debug, mais on peut dire qu'elle montre les paramètres de communication et si un fichier .dmp a été crée.

Un commentaire , une précision ? Ecrivez nous.