Le
processus de démarrage de Windows XP se déroule
de façon totalement transparente pour l'utilisateur.
Pourtant, derrière ce mécanisme se cache plusieurs
processus interdépendants qui dans certains cas lors
d'un fichier manquant, de problème matériel,
de fichier corrompu, ... peuvent empêcher le démarrage
de Windows. Pour l'utilisateur lambda, comprendre ce processus
ne lui est d'aucune utilité, par contre pour les informaticiens,
connaître les différentes étapes du processus
de boot de Windows permet de mieux cibler l'origine d'un problème
et donc de le résoudre avec plus d'efficacité.
2.
Le BIOS
1.
Le CPU exécute le code du BIOS contenu dans la ROM
2. Le BIOS réalise un POST (Power
On Self Test), c'est un test de base du matériel qui
est présent dans l'ordinateur et qui vérifie
son bon fonctionnement. (Toutes les erreurs qui se produisent
à ce moment seront rapportées au moyen de «
signal-code » ou bips)
3. Le BIOS lit les informations de configuration
stockées dans la CMOS
4. Après le POST, le BIOS essaye de
localiser un système d'exploitation. L'ordre que le
BIOS suit va dépendre de la séquence de boot
qui a été configuré. Le BIOS recherche
un disque amorçable. Si le lecteur d'amorçage
est A et qu'il contient une disquette amorçable, le
BIOS charge le premier secteur (le secteur de boot) en mémoire.
S'il contient une disquette qui n'est pas amorçable,
l'un des messages d'erreurs suivant apparaît :
Non-system
disk or disk error
Replace
and press any key when ready
5.
Si le BIOS ne trouve pas de disquette dans le lecteur, il
recherche alors un autre lecteur ayant un secteur amorçable.
Si aucun secteur amorçable n'existe une des erreurs
suivantes apparaît :
Invalid
partition table
Error
loading operating system
Missing
operating system
6.
Si un secteur amorçable est présent sur le disque
dur, le BIOS lit et exécute le premier secteur physique
du disque dur. Ce premier secteur est appelé le secteur
de démarrage principal (MBR – Master Boot Record).
3.
Le Master Boot Record
1.
Le MBR scanne alors la table de partition à la recherche
d'information sur la partition système. Quand l'information
de la partition système a été lue, il
charge le secteur 0* de la partition système en mémoire
et le démarre. Un programme de petite taille qui se
trouve au début de ce secteur (le bootstrap). Ce programme
utilise les informations de partition pour déterminer
quelle est la partition de démarrage et tente de démarrer
à partir de celle-ci
*Le
secteur 0 de la partition système peut être une
utilitaire, un programme de diagnostic, ou un secteur de boot
de partition qui contient le code de démarrage pour
le logiciel d'exploitation.
Remarque
: la partition système doit être sur
le premier disque physique et contenir les fichiers systèmes
de démarrage énumérés ci après
:
Nom
du fichier
Emplacement
Ntldr
Racine
du disque d'amorçage
Boot.ini
Racine
du disque d'amorçage
Bootsect.dos
Racine
du disque d'amorçage (système multi-boot)
Ntdetect.com
Racine
du disque d'amorçage
Hyberfil.sys
%systemdrive%
(C:\WINDOWS ou C:\WINNT)
Ntbootdd.sys
Racine
du disque d'amorçage (Pour la connectique
SCSI)
Ntoskrnl.exe
%systemroot%\System32
Hal.dll
%systemroot%\System32
Clés
de Registre systèmes
%systemroot%\System32\Config
Pilotes
de périphérique
%systemroot%\System32\Drivers
Cdldr
Racine
du disque d'amorçage
2. Le programme d’amorce (bootstrap)
charge ensuite NTLDR en mémoire et lui transfère
le contrôle. S'il ne parvient pas à trouver le
fichier NTLDR, le programme affiche le message d’erreur
suivant :
"Couldn't find NTLDR" si le système
de fichiers est FAT
ou
"A kernel file is missing from the disk" si le système
de fichiers est NTFS.
4.
Le processus NTLDR
1.
Tout d'abord NTLDR fait passer le processeur du mode
réel 16 bits en mode protégé sur 32 bits
puis active la pagination. NTLDR étant un programme
32 bits, il doit commuter le processeur en mode 32 bits de
sorte qu'il puisse continuer à charger le logiciel
d'exploitation
2. NTLDR démarre le système
de fichiers NTFS ou la table d'allocation de fichiers (le
système de fichiers FAT) 16 ou 32. Un code pour accéder
au système de fichiers approprié est inscrit
dans NTLDR.
3. NTLDR lit ensuite le contenu du fichier
Boot.ini puis affiche les options de démarrage,
s'ils en existent plusieurs ou bien démarre le système
d'exploitation par défaut. Si la ligne de boot.ini
se rapporte à une installation DOS, NTLDR lit le contenu
du fichier bootsect.dos
4.Ntdetect.com est chargé
et exécuté par NTLDR. Ntdetect.com est un programme
qui utilise le BIOS pour récupérer les informations
de base sur la configuration de l’ordinateur. Ces informations
incluent l’heure, la date stockée dans le CMOS,
les différents types de bus (par exemple, ISA, PCI
sur, EISA,…). Ces informations sont ensuite stockées
dans la clef HKLM\HARDWARE. Durant
la phase Ntdetect.com, si plusieurs profils matériel
ont été prédéfinis, un menu apparaît
pour pouvoir sélectionner le profil désiré.
Ntdetect.com transfert ensuite les informations à NTLDR
et lui redonne la main
5. Les 2 premiers fichiers qui composent
le noyau NT, Ntoskrnl.exe et Hal.dll
(répertoire %systemroot%\system32) sont chargés.
Si NTLDR ne parvient pas à charger l'un ou l'autre
de ces fichiers, il affiche le message suivant :
"Windows
NT could not start because the following file was missing
or corrupt", suivie du nom du fichier
6. NTLDR lit le contenu de la clé
HKLM\SYSTEM situé dans
le répertoire "C:\WINDOWS\system32\config\system"
puis insère les informations sur la configuration du
matériel qu'il a recueillies plus tôt, dans la
clé de Registre SYSTEM.
7. Les pilotes de périphérique
qui se trouvent dans la ruche HKLM\SYSTEM\CurrentControlSet\Services
ayant la valeur Start sont chargés
en mémoire, puis NTLDR
transfère le contrôle à ntoskrnl.exe.
5.
Le processus NTOSKRNL.exe
1.
Dès l'initialisation de Ntoskrnl.exe, ce dernier crée
la Clone control set, qui est une copie de la ruche
Current control set. La Clone control set
représente l’état de l’ordinateur
pendant sa configuration cette dernière n’est
pas changée ni modifiée. Ntoskrnl.exe va aussi
créer la ruche HARDWARE dans le registre
en utilisant les informations collectées précédemment
par ntdetect.com
2.
NTOSKRNL comporte 2 phases dans son processus de démarrage
la phase 0 et la phase 1. La phase 0 est orchestré
par une fonction appelée ExpInitializeExecutive
qui est chargée d'appelée la HAL pour préparer
et initialiser le contrôleur d'interruption, le gestionnaire
de mémoire, le gestionnaire d'objet, le moniteur de
référence de sécurité et le gestionnaire
de processus. La phase 1 commence quand la HAL est appelée
pour préparer le système à accepter les
interruptions de périphériques
3.
L'initialisation du gestionnaire d'Entrées/Sorties
commence le processus de chargement de tous les fichiers pilotes
systèmes. Ntoskrnl.exe va initialiser les pilotes de
périphériques chargés précédemment,
puis va scruter le registre à la recherche des pilotes
de périphériques qui ont comme valeur de démarrage
0x1
Remarque
: l’échec de chargement d’un pilote
peut provoquer le redémarrage de Windows pour tenter
de redémarrer en utilisant la dernière bonne
configuration connue
4.
À la fin de la phase 1, le noyau NT est totalement
opérationnel. Pour terminer la fonction lance le programme
SMSS.exe (Session Manager SubSystem situé dans le répertoire
C:\WINDOWS\system32).
6.
Le processus d'ouverture de session
1.
SMSS crée l'environnement en mode utilisateur qui fournit
l'interface Windows. C'est un processus système Windows,
il est responsable de la gestion des sessions sur le système
(création, gestion, et suppression des sessions utilisateurs).
C'est le premier processus exécuté au démarrage
en mode utilisateur. SMSS
ressemble à n'importe quel autre processus en mode
utilisateur, excepté pour deux choses : d'abord WINDOWS
le considère comme un processus de confiance, en second
lieu, SMSS est une application native. Puisque c'est un composant
de confiance de l’OS, SMSS peut effectuer des actions
que peu d'autres processus peuvent exécuter, comme
créer des jetons de sécurité
2.
Pendant sa phase d'initialisation SMSS traite en premier les
valeurs comprises dans la clé HKLM\SYSTEM\CurrentControlSet\Session
Manager\BootExecute. Cette valeur contient une commande
pour lancer l'utilitaire CHKDSK, qui vérifie
la cohérence du disque (il crée et affiche un
rapport sur l'état d'un disque donné en fonction
du système de fichiers. Chkdsk indique également
toutes les erreurs détectées sur le disque et
les corrige). Puis SMSS charge le contenu des clefs HKLM\sam,
HKLM\sam\security, et HKLM\software.
La clef HKLM\SYSTEM\CurrentControlSet\Control\Hivelist
permet de savoir ou sont situés les fichiers ruches
sur le disque (ces fichiers sont : le fichier SAM, SECURITY,
SOFTWARE, SYSTEM et le fichier NTUSER.dat qui lui est propre
à chaque utilisateur. Le contenu de ntuser.dat est
situé dans la branche HKEY_CURRENT_USER.
Ce fichier contient les paramètres qui définissent
l’environnement de travail de l’utilisateur qui
a ouvert une session)
3.
SMSS charge ensuite le pilote de périphérique
win32k.sys et détermine l'endroit où il se trouve
ainsi que les autres composants qu'il charge en recherchant
leurs chemins dans la clé HKLM\SYSTEM\CurrentControlSet\Session
Manager. Finalement, SMSS lance csrss.exe
et winlogon.exe. CSRSS sert à gérer
les fenêtres et les éléments graphiques
de Windows et Winlogon sert à gérer l'ouverture
et la fermeture des sessions
4.
WINLOGON.exe est chargé comme un service par le kernel
suivi par LSASS.exe (Local Security Authority Subsystem Service).
A ce moment la boîte d'ouverture de session apparaît.
(Après authentification de l'utilisateur, LSASS.exe
crée un jeton d'accès qui contient la liste
des groupes auxquels l’utilisateur appartient et les
droits qui lui sont attribués)
5.
Le contrôleur de services (screg.exe) va ensuite analyser
le registre à la recherche de services qui ont comme
valeur de démarrage 0x2 situées
dans la branche HKLM\SYSTEM\CurrentControlSet\Services\DriverName
et va les charger. Les services doivent être lancés
dans un certain ordre, en fonction de leurs dépendances
vis à vis d'autres services. Les dépendances
sont décrites dans les clés DependOnGroup
et DependOnService dans HKLM\SYSTEM\CurrentControlSet\Services\DriverName.
Les services marqués avec la valeur 0x3
sont démarrés manuellement et les services qui
ont la valeur 0x4 sont désactivés
6.
Enfin lors de l'ouverture de la session utilisateur le contenu
des clés suivantes est chargé :
6.
Un démarrage n'est pas considéré comme
ayant réussit tant que l'utilisateur n'a pas ouvert
de session. Après chaque ouverture de session réussie,
la Clone Control Set est copiée dans la clé
HKEY_LOCAL_MACHINE\SYSTEM\LastKnownGoodRecovery.
