Processus de démarrage de Windows NT
# Processus de démarrage de Windows NT

Le processus de démarrage de Windows NT est le processus par lequel Windows NT 3.1, 3.5, 4.0, 2000, XP, et 2003 s'initialisent.

Pour Windows Vista (NT 6.0) et les successeurs, le processus est substantiellement différent.

## Phase de chargement à l'amorçage

La phase du chargeur d'amorçage (bootloader en anglais) dépend de la plate-forme concernée. Puisque les premières phases ne sont pas techniquement dépendantes du système d'exploitation, le processus d'amorçage est considéré commencé quand :

* Pour x86 et x64 : quand le code du secteur d'amorçage est exécuté en mode réel et charge NTLDR
* Pour Itanium : quand le programme EFI IA64ldr.efi est exécuté

À partir de ce point, le processus d'amorçage suit les étapes suivantes :

    x86 x64 Itanium Quand le contrôle est passé à NTLDR, le processeur est en mode réel. La première action de NTLDR est de passer en mode protégé, ce qui permet l'accès à la mémoire 32-bits et donc de créer la table des pages mémoires initiale et d'activer la pagination mémoire. Cela fournit les fonctionnalités de base pour le reste de l'amorçage, puis, dans les étapes ultérieures pour le système d'exploitation lui-même. NTLDR inclut des fonctionnalités de base pour l'accès au(x) disque(s) IDE partitionné NTFS ou FAT, via le BIOS. Si le disque d'amorçage est SCSI et n'est pas accessible avec le micrologiciel du BIOS, alors, un fichier additionnel, Ntbootdd.sys est chargé pour gérer les accès disque à la place des routines par défaut. C'est une copie de ce même miniport SCSI qui sera utilisé quand Windows s'exécutera. Le chargeur d'amorçage lit alors le fichier boot.ini pour localiser l'emplacement du disque système. À cette étape, l'écran est effacé. Dans les versions de NTLDR ou IA64ldr.efi qui supportent la mise en veille (c'est-à-dire Windows 2000 et versions ultérieures), le fichier de mise en veille est cherché dans le volume système (volume défini par boot.ini). Si le fichier est trouvé, s'il est positionné comme actif et s'il y a assez de mémoire vive, alors, le contenu de ce fichier est chargé en mémoire et le contrôle est transféré au noyau Windows au point exact de la mise en veille. Le fichier est immédiatement marqué comme non-actif. Le but est de se protéger contre les conséquences d'un arrêt brutal de l'ordinateur (par l'utilisateur ou par suite d'un problème logiciel ou matériel) : ainsi, lorsque l'utilisateur tentera un deuxième reboot, NTLDR lui donnera le choix entre un boot normal ou une tentative de reprise sur l'état d'avant la mise en veille. Si le fichier boot.ini contient plus d'une entrée, un menu de boot est affiché, permettant à l'utilisateur de choisir quel système d'exploitation doit être chargé. CAS 1 L'utilisateur sélectionne un système d'exploitation non NT tel que Windows 98 (spécifié par un chemin type MS-DOS, par exemple C:\), alors NTLDR charge le fichier secteur de boot spécifié dans boot.ini (par défaut, c'est le fichier bootsect.dos si aucun nom de fichier n'est spécifié), puis NTLDR passe le contrôle de l'exécution à ce fichier. CAS 2 L'utilisateur sélectionne un système d'exploitation basé sur NT NTLDR exécute ntdetect.com qui réunit les informations basiques sur le matériel (ces informations proviennent du BIOS). À cette étape, NTLDR efface l'écran et affiche une barre de progression vide : Windows 2000 affiche une simple barre de texte au bas de l'écran accompagnée par les mots Démarrage de Windows Sur XP et 2003, il n'y a pas de texte, mais une barre de progression, qui n'est pas forcément vue par l'utilisateur car elle s'initialise très vite. Si l'utilisateur appuie sur la touche F8, un menu de boot avancé est affiché. Ce menu propose à l'utilisateur de booter selon différents modes en "mode sans échec (voir (en) safe mode) avec la dernière bonne configuration connue avec le Mode débogage activé le mode restauration des services d'Active Directory (ce mode n'a un intérêt que sur un serveur Windows 2003 ou 2000 utilisé comme serveur Active Directory) Une fois qu'un mode de boot est choisi et si la touche F8 n'a pas été enfoncée, le boot continue. Si une version x64 de Windows a été bootée (Windows XP Professional x64 Edition ou Windows Server 2003 x64 Editions), alors le processeur passe en mode long et l'adressage 64-bit est activé

Ensuite, NTLDR ou IA64ldr charge le Noyau windows NT et la couche d'abstraction matérielle (hal.dll) en mémoire. Si NTLDR ou IA64ldr échoue à charger ces fichiers, un message indiquera que Windows ne peut commencer parce que le fichier est corrompu $_{Enfait,lelibelléd'erreurprêteàconfusion:endehorsdelacorruptiond'undeces2fichiers,d'autreserreurs(temporairesoudéfinitives)peuventprovoquercemessage.}Sur$ ce message d'erreur, le processus de boot se fige.

Si de multiples configurations matérielles sont définies dans la base de registre, un menu est proposé à l'utilisateur pour les choisir.

La prochaine tâche de NTLDR ou IA64ldr est de charger (mais pas d'initialiser) tous les pilotes en mémoire. Cette information est stockée sous l'arborescence HKey_Local_Machine\SYSTEM du registre, dans un sous-arbre du registre appelé ControlSet. De multiples ControlSet sont conservés ; il y en a au minimum deux : celui en cours et le dernier qui a permis un boot complet. HKey_Local_Machine\SYSTEM contient des ControlSet nommésControlSet001, ControlSet002, etc., ainsi que CurrentControlSet. En fonctionnement normal, Windows utilise CurrentControlSet pour lire et écrire des informations. CurrentControlSet est une simple référence : pour déterminer quel est le ControlSet qui servira de ControlSet courant, NTLDR ou IA64ldr utilisera les valeurs qui sont sousHKey_Local_Machine\SYSTEM\Select:

* Default sera la valeur choisie si aucune autre n'est indiquée
* Si la valeur de clé Failed correspond à Default, alors NTLDR ou IA64ldr affiche un message d'erreur, indiquant que le dernier boot a échoué, et propose à l'utilisateur de réessayer ou d'utiliser la dernière bonne configuration connue.
* Si l'utilisateur a choisi dernière bonne configuration connue, le controlSet indiqué par LastKnownGood est utilisé au lieu de Default.

Quand un ControlSet est choisi, la clé Current est positionnée pour pointer dessus. La clé Failed est aussi positionnée à la même valeur que Current jusqu'à la fin du processus de boot. La clé LastKnownGood est aussi positionnée à Current si le boot se déroule complètement et avec succès.

NTLDR détermine quels seront les pilotes boot-time qui seront nécessaires au tout début de l'exécution du noyau.

NTLDR ou IA64ldr passe le contrôle au noyau Windows. Windows affiche alors l'écran bleu qui liste le nombre de processeurs, la quantité de mémoire installée, les switch de boot.

Voir Boot.ini : Les switch du noyau

## Phase de chargement du noyau Windows

L'initialisation du noyau et du sous-système exécutif de Windows se fait en deux phases.

Durant la première phase, des structures de base de la mémoire sont créées, et chaque processeur est initialisé. Le gestionnaire de mémoire est initialisé, créant les structures nécessaires pour

* le cache des systèmes de fichiers
* les pools de mémoire paginée et non-paginée,
* le gestionnaire d'objet ,
* le jeton de sécurité initial (voir (en) security token) pour l'assignation du premier processus du système
* le gestionnaire de processus.

Le Processus inactif du système (voir (en) System idle process) et le gestionnaire du système sont créés à cette étape.

$_{NB:Leprocessusinactifdusystème(Systemidleprocess)asonéquivalentsousunix/linux:ils'agitdelatâcheinvisiblequiaunPIDde0etquilancelatâcheinitdontlePIDesttoujours1.}$

La seconde phase initialise les pilotes qui ont été identifiés par NTLDR ou IA64l comme pilote boot-time.

Durant le chargement de ces pilotes, une barre de progression est affichée au bas de l'écran sur Windows 2000 ; dans Windows XP et Windows Server 2003, cette barre a été remplacée par une barre animée qui ne représente pas la progression. Cette phase est plus courte avec XP et les versions postérieures car l'initialisation des pilotes se fait en parallèle, en asynchrone (au lieu de les faire un par un, les uns après les autres, en synchrone).

## Gestionnaire de session (smss.exe)

Une fois que les pilotes de boot et les pilotes système ont été chargés, le noyau (thread système) lance le Session Manager SubSystem (smss.exe). SMSS est un des plus importants composants de Windows.

SMSS.exe lit la clé BootExecute (dans HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\). La valeur par défaut de cette clé indique de faire un autochk sur toutes les partitions de disque ( ). Plus précisément, Autochk monte tous les pilotes de stockage et vérifie qu'ils ont été arrêtés proprement. C'est l'équivalent du fsck de linux.

À cette étape, l'écran est très différent selon les différentes versions de Windows.

Après cette étape, smss.exe peut ouvrir les différents fichiers nécessaires pour effectuer les actions suivantes :

* Crée les variables d'environnement (HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment : %PATH%, %PATHEXT%, %TEMP%, %TMP%, %WINDIR%, %OS%, %COMSPEC% (voir (en) ComSpec, %NUMBER_OF_PROCESSORS, %PROCESSOR_ARCHITECTURE%, %PROCESSOR_IDENTIFIER%, ...etc.
* Commence le sous-système Win32 en mode noyau (win32k.sys). Cela permet à Windows de passer en mode graphique.
* Crée les fichiers de pagination mémoire virtuelle (Les paramètres de configuration sont dans HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory managment)
* Effectue les renommages (ou effacements) de fichiers en attente (Spécifiés par la clef de registre HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\PendingFileRenameOperations). Cela permet le remplacement de fichiers pendant le démarrage (par exemple bibliothèques système qui sont normalement utilisés en permanence et ne peuvent pas être effacées ni remplacées pendant le fonctionnement normal.)

Il lance :

* Le Windows Logon Manager (winlogon.exe). Winlogon gère le logon interactif (local ou distant). La bibliothèque GINA (voir (en) Graphical Identification And Authentication) est chargée et utilisée par le processus winlogon

S'il y a plusieurs sessions ouvertes (c'est-à-dire plus d'un utilisateur connecté), alors SMSS.exe lance à chaque fois un processus winlogon .exe supplémentaire.

## Winlogon

* voir (en) en:Windows NT Startup Process#Winlogon
* Le premier winlogon.exe lance
   * Le service sécurité locale lsass.exe (Local Security Authority Subsystem Service)
   * Le gestionnaire de services services.exe qui pilote le démarrage des autres services système (spouleur d'imprimante, audio, connexion réseau, etc.)

Winlogon réalise l'identification et l'authentification d'un utilisateur via

* Le service lsass.exe
* Une bibliothèque GINA (conçue pour l'authentification et l'identification), voir (en) GINA (Graphical Identification aNd Authorization). La plupart des utilisateurs se servent de la bibliothèque GINA fournie par Microsoft, par défaut.

Si l'utilisateur est identifié et authentifié, alors

* Lancement de userinit.exe
* Lancement du shell de l'utilisateur (par défaut, c'est l'Explorateur Windows (explorer.exe)

Si plus d'une session est ouverte (c'est-à-dire plusieurs utilisateurs connectés en même temps), alors il y aura plusieurs

* winlogon.exe (1 par utilisateur connecté)
* csrss.exe (1 par utilisateur connecté)

## Logon Phase

* voir (en) en:Windows NT Startup Process#Logon Phase
   * HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Runonce
   * HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\policies\Explorer\Run
   * HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
   * HKCU\Software\Microsoft\Windows NT\CurrentVersion\Windows\Run
   * HKCU\Software\Microsoft\Windows\CurrentVersion\Run
   * HKCU\Software\Microsoft\Windows\CurrentVersion\RunOnce
   * All Users ProfilePath\Start Menu\Programs\Startup\ (Sur une version de Windows anglophone)
   * Current User ProfilePath\Start Menu\Programs\Startup\ (Sur une version de Windows anglophone)

## Installation et boot à distance

* Le service BINL (Boot Information Negotiation Layer) permet l'installation à distance de Windows pour des ordinateurs équipés de carte(s) réseau PXE (Preboot Execution Environment).

Voir aussi RIS (Remote Installation Services)

Voir (en) Description of PXE Interaction Among PXE Client, DHCP, and RIS Server

## Informations additionnelles

HKEY_Local_Machine\HARDWARE

* voir (en) en:Windows NT Startup Process#Loading the Windows NT kernel
