Administration de Windows
Dans le noyau de Windows Vista : 2ème partie
Mark Russinovich
Vue d'ensemble:
- Gestion de la mémoire
- Démarrage et arrêt
- Gestion de l'alimentation
Le mois dernier, dans le premier article de cette série en trois épisodes, j'ai présenté les améliorations du noyau de Windows Vista au niveau des processus et d'E/S.
Cette fois, je vais aborder les avancées dans la façon dont Windows Vista gère la mémoire, ainsi que les améliorations majeures du démarrage et de l'arrêt du système, ainsi que de la gestion de l'alimentation (1e partie).
Chaque version de Windows® améliore l'évolutivité et les performances, et Windows Vista™ n'échappe pas à la règle. Le gestionnaire de mémoire de Windows Vista présente de nombreuses améliorations, telles qu'une utilisation plus étendue de techniques de synchronisation sans verrouillage, un verrouillage plus fin, une compression supérieure des structures de données, des E/S d'échange plus grandes, la prise en charge d'architectures de mémoire de cartes vidéo modernes et une utilisation plus efficace du tampon de traduction matériel. De plus, la gestion de la mémoire de Windows Vista offre maintenant une allocation de l'espace d'adressage dynamique pour les exigences de charges de travail différentes.
Quatre fonctionnalités d'amélioration des performances qui utilisent de nouvelles technologies sont utilisées pour la première fois dans un système d'exploitation sur Windows Vista : SuperFetch, ReadyBoost, ReadyBoot et ReadyDrive. Je les étudierai en détail plus loin dans cet article.
Espace d'adressage du noyau dynamique
Windows et les applications qui s'exécutent dessus ont dû faire face aux limites d'espace d'adressage des processeurs 32 bits. Le noyau Windows est limité par défaut à 2 Go, ou à la moitié de l'espace d'adressage virtuel 32 bits total, l'autre moitié étant réservée au processus dont le thread s'exécute actuellement sur le processeur. Dans sa moitié, le noyau doit se mapper, mapper les pilotes de périphérique, le cache du système de fichiers, les piles du noyau, les structures de données de code par session et les tampons à la fois non paginés (verrouillés dans la mémoire physique) et paginés alloués par les pilotes de périphérique. Avant Windows Vista, le gestionnaire de mémoire déterminait au moment du démarrage la quantité d'espace d'adressage à attribuer à ces objectifs différents, mais cette rigidité provoquait parfois des situations dans lesquelles l'une des zones devenait pleine alors que les autres possédaient encore plein d'espace disponible. L'épuisement d'une zone peut entraîner des échecs d'application et empêcher les pilotes de périphérique de terminer les opérations d'E/S.
Dans Windows Vista 32 bits, le gestionnaire de mémoire gère l'espace d'adressage du noyau de façon dynamique, en allouant et en libérant de l'espace pour diverses utilisations en fonction des exigences de la charge de travail. Ainsi, la quantité de mémoire virtuelle utilisée pour stocker des tampons paginés peut augmenter lorsque les pilotes de périphérique en ont besoin et rétrécir lorsque les pilotes la libèrent. Windows Vista pourra donc gérer une plus grande variété de charges de travail et, de la même manière, la version 32 bits du prochain Windows Server® au nom de code « Longhorn », sera en mesure de gérer davantage d'utilisateurs de Terminal Server.
Bien sûr, sur les systèmes Windows Vista 64 bits, les contraintes d'espace d'adressage ne constituent pas actuellement une limitation pratique et ne nécessitent donc pas de traitement spécial puisqu'elles sont configurées à leur maximum.
Priorités de mémoire
Tout comme il ajoute des priorités d'E/S (comme je l'ai expliqué dans le dernier article), Windows Vista implémente également des priorités de mémoire. Pour comprendre comment Windows utilise les priorités de mémoire, il faut comprendre comment le gestionnaire de mémoire implémente son cache de mémoire, appelé Liste En attente. Sur toutes les versions de Windows antérieures à Windows Vista, lorsqu'une page physique (dont la taille est généralement de 4 Ko) appartenant à un processus était récupérée par le système, le gestionnaire de mémoire la plaçait généralement à la fin de la liste En attente. Si le processus souhaitait accéder à nouveau à la page, le gestionnaire de mémoire prenait la page dans la liste En attente et la réaffectait au processus. Lorsqu'un processus souhaitait utiliser une nouvelle page de la mémoire physique et qu'il n'y avait pas de mémoire disponible, le gestionnaire de mémoire donnait au processus la page figurant au début de la liste En attente. Ce schéma traitait toutes les pages en attente de la même façon, en utilisant uniquement l'heure à laquelle elles avaient été placées dans la liste pour les trier.
Sur Windows Vista, chaque page de mémoire a une priorité comprise entre 0 et 7, et donc le gestionnaire de mémoire divise la liste En attente en huit listes qui contiennent chacune des pages d'une priorité particulière. Lorsque le gestionnaire de mémoire veut prendre une page dans la liste En attente, il commence par prendre les pages à priorité basse. La priorité d'une page reflète habituellement la priorité du thread qui entraîne son allocation à l'origine. (Si la page est partagée, elle reflète la priorité de mémoire la plus élevée des threads en partage). Un thread hérite sa valeur de priorité de page du processus auquel il appartient. Le gestionnaire de mémoire utilise des priorités basses pour les pages qu'il lit à partir du disque en spéculant lorsqu'il anticipe des accès à la mémoire d'un processus.
Par défaut, les processus ont une valeur de priorité de page de 5, mais des fonctions permettent aux applications et au système de modifier les valeurs de priorité de page des processus et des threads. Il n'est possible de réaliser la véritable puissance des priorités de mémoire que lorsqu'on comprend les priorités relatives des pages à un niveau macro, ce qui est le rôle de SuperFetch.
SuperFetch
La façon dont le gestionnaire de mémoire gère la mémoire physique représente un changement important. La gestion de la liste En attente utilisée par des versions antérieures de Windows a deux limites. Premièrement, la priorisation des pages repose uniquement sur le comportement antérieur récent des processus et elle ne prévoit pas leurs besoins de mémoire futurs. Deuxièmement, les données utilisées pour la priorisation sont limitées à la liste des pages appartenant à un processus à un moment donné. Ces lacunes peuvent entraîner des scénarios du type « syndrome post-déjeuner » (quand vous vous absentez de votre ordinateur pendant un moment et qu'une application de système sollicitant beaucoup de mémoire est exécutée (par exemple, une analyse antivirus ou une défragmentation du disque). Cette application remplace le code et les données que vos applications actives avaient mis en cache dans la mémoire par les activités sollicitant la mémoire. À votre retour, vous trouvez que les performances sont ralenties étant donné que les applications doivent récupérer leurs données et code sur le disque.
Windows XP a introduit une prise en charge de prérécupération qui améliorait les performances de démarrage et de lancement des applications en exécutant de grandes E/S de disque pour précharger la mémoire avec le code et les données de système de fichiers attendues, en fonction des redémarrages et lancements d'applications précédents. Windows Vista va encore plus loin avec SuperFetch, un mode de gestion de la mémoire qui améliore l'approche de l'accès le moins récent avec des informations historiques et une gestion proactive de la mémoire.
SuperFetch est implémenté dans %SystemRoot%\System32\Sysmain.dll en tant que service Windows qui s'exécute dans un processus Hôte de service (%SystemRoot%\System32\Svchost.exe). Ce mode s'appuie sur la prise en charge du gestionnaire de mémoire pour récupérer les historiques d'utilisation des pages, ainsi que pour demander au gestionnaire de mémoire de précharger des données et du code à partir de fichiers du disque ou d'un fichier de pagination de la liste En attente et attribuer des priorités aux pages. Le service SuperFetch étend en fait le suivi des pages aux données et au code qui étaient auparavant dans la mémoire, mais que le gestionnaire de mémoire a réutilisés pour faire de la place à de nouvelles données et du nouveau code. Il stocke ces informations dans des fichiers de scénario ayant une extension .db dans le répertoire %SystemRoot%\Prefetch, en compagnie des fichiers de prérécupération standard utilisés pour optimiser le lancement des applications. Grâce à cette connaissance approfondie de l'utilisation de la mémoire, SuperFetch peut précharger les données et le code lorsque la mémoire physique devient disponible.
Lorsque de la mémoire se libère (par exemple, lorsqu'une application se ferme ou qu'elle libère de la mémoire), Superfetch demande au gestionnaire de mémoire d'extraire les données et le code qui viennent d'être expulsés. Ceci se produit à un rythme de quelques pages par seconde avec des E/S de priorité très basse pour que le préchargement n'ait aucun impact sur l'utilisateur ou d'autres applications actives. Par conséquent, si vous quittez votre ordinateur le temps d'aller déjeuner et qu'une tâche d'arrière-plan sollicitant beaucoup de mémoire entraîne l'expulsion du code et des données de vos applications actives de la mémoire pendant votre absence, SuperFetch peut souvent les ramener, ou en ramener la majeure partie, dans la mémoire avant votre retour. SuperFetch inclut également une prise en charge des scénarios spécifique pour la veille prolongée, la veille, le changement rapide d'utilisateur et le lancement d'application. Lorsque le système passe en mode de veille prolongée, par exemple, SuperFetch stocke les données et le code dans le fichier de veille prolongée qui, selon ses estimations (en fonction des veilles prolongées précédentes), sera consulté au cours de la reprise à venir. Par comparaison, lorsque vous reprenez Windows XP, les données qui avaient été mises en cache doivent être relues à partir du disque lors du référencement.
Consultez l'encadré « Observation de SuperFetch » pour un aperçu de l'impact de SuperFetch sur la mémoire disponible.
Observation de SuperFetch
Après avoir utilisé un système Windows Vista pendant un moment, vous verrez un numéro peu élevé pour le compteur de mémoire physique libre sur la page des performances du gestionnaire des tâches. Cela est du au fait que SuperFetch et la mise en cache Windows standard utilisent toute la mémoire physique disponible pour mettre en cache les données du disque. Par exemple, lors du premier démarrage, si vous exécutez tout de suite le Gestionnaire des tâches, vous devriez remarquer que la valeur de la mémoire libre diminue à mesure que la valeur de la mémoire mise en cache augmente. Autre exemple : si vous exécutez un programme sollicitant beaucoup de mémoire et que vous le fermez ensuite (n'importe quel logiciel gratuit « optimisateur de RAM » allouant de grandes quantités de mémoire et libérant ensuite la mémoire fera l'affaire) ou que vous copiez simplement un très gros fichier, la valeur de la mémoire libre augmentera et le graphique d'utilisation de la mémoire physique chutera lorsque le système récupèrera la mémoire libérée. Toutefois, SuperFetch réalimente progressivement le cache avec les données qui ont été expulsées de la mémoire, de sorte que la valeur de mise en cache augmentera et celle de la mémoire disponible déclinera.
Observation de la mémoire(Cliquer sur l'image pour l'agrandir)
ReadyBoost
La vitesse des processeurs et de la mémoire sont en train de dépasser rapidement celles des disques durs, si bien que les disques constituent un goulot d'étranglement courant des performances du système. Les E/S de disque aléatoires sont particulièrement chères car les temps de recherche des têtes de disques sont de l'ordre de 10 millisecondes, une éternité pour les processeurs de 3 GHz d'aujourd'hui. La mémoire vive est idéale pour mettre en cache les données de disque, mais elle est relativement chère. La mémoire flash, en revanche, est généralement meilleur marché et propose les lectures aléatoires jusqu'à 10 fois plus vite qu'un disque dur classique. Windows Vista inclut donc une fonctionnalité appelée ReadyBoost qui tire parti des périphériques de stockage à mémoire flash en créant sur eux une couche de mise en cache intermédiaire qui repose logiquement entre la mémoire et les disques.
ReadyBoost consiste en un service implémenté dans %SystemRoot%\System32\Emdmgmt.dll qui s'exécute dans un processus Hôte de service et un pilote de filtre de volume, %SystemRoot%\System32\Drivers\Ecache.sys. (Emd est l'abréviation de External Memory Device, périphérique de mémoire externe, le nom de ReadyBoost pendant son développement). Lorsque vous insérez un périphérique flash tel qu'une clé USB dans un système, le service ReadyBoost étudie le périphérique pour déterminer ses caractéristiques de performances et stocke les résultats de son test dans HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\Currentversion\Emdmgmt, illustré à la figure 1.
Figure 1** Résultats du test du périphérique réalisé par ReadyBoost dans le Registre **(Cliquer sur l'image pour l'agrandir)
Si vous n'utilisez pas déjà un périphérique pour la mise en cache et que la taille du nouveau périphérique est comprise entre 256 Mo et 32 Go, qu'il a un taux de transfert de 2,5 Mo/s ou plus pour des lectures aléatoires de 4 Ko et que son taux de transfert est de 1,75 Mo/s ou plus pour des écritures aléatoires de 512 Ko, ReadyBoost vous demandera si vous souhaitez consacrer jusqu'à 4 Go du stockage pour la mise en cache du disque. (Bien que ReadyBoost puisse utiliser le système NTFS, il limite la taille maximale du cache à 4 Go pour tenir compte des restrictions FAT32). Si vous acceptez, le service crée un fichier de mise en cache appelé Readyboost.sfcache dans la racine du périphérique et demande à SuperFetch de préremplir le cache en arrière-plan.
Une fois que le service ReadyBoost a initialisé la mise en cache, le pilote de périphérique Ecache.sys intercepte toutes les lectures et écritures vers des volumes du disque dur local (C:\, par exemple) et copie toutes les données écrites dans le fichier de mise en cache que le service a créé. Ecache.sys compresse les données, généralement avec un taux de compression de 2:1. Un fichier de cache de 4 Go contiendra donc habituellement 8 Go de données. Le pilote chiffre chacun des blocs écrits à l'aide d'un chiffrement AES (Advanced Encryption Standard) en utilisant une clé de session générée de façon aléatoire par démarrage afin de garantir la confidentialité des données dans le cache si le périphérique est supprimé du système.
Lorsque ReadyBoost voit des lectures aléatoires qui peuvent être satisfaites à partir du cache, il les gère à partir de cet endroit, mais comme les disques durs ont un meilleur accès en lecture séquentiel que la mémoire flash, il laisse les lectures qui font partie de modèles d'accès séquentiel atteindre le disque directement, même si les données sont dans le cache.
ReadyBoot
Windows Vista utilise la même prérécupération de démarrage que celle que Windows XP utilisait si le système possédait moins de 512 Mo de mémoire, mais si le système possède 700 Mo de mémoire vive ou plus, il utilise un cache dans la mémoire vive afin d'optimiser le processus de démarrage. La taille du cache dépend du total de mémoire vive disponible, mais il est assez grand pour créer un cache raisonnable tout en laissant au système la mémoire dont il a besoin pour démarrer facilement.
Après chaque démarrage, le service ReadyBoost (même service que celui qui implémente la fonctionnalité ReadyBoost qui vient d'être décrite) utilise le temps d'inactivité du processeur pour calculer un plan de mise en cache pour le démarrage suivant. Il analyse les informations de suivi de fichier des cinq démarrages précédents et identifie les fichiers qui ont été consultés et leur emplacement sur le disque. Il stocke les suivis traités dans %SystemRoot%\Prefetch\Readyboot sous la forme de fichiers .fx et enregistre le plan de mise en cache sous HKLM\System\CurrentControlSet\Services\Ecache\Parameters dans des valeurs REG_BINARY nommées en fonction des volumes de disque internes auxquels elles se rapportent.
Le cache est implémenté par le pilote de périphérique qui implémente la mise en cache ReadyBoost (Ecache.sys), mais le remplissage du cache est guidé par le service ReadyBoost lors du démarrage du système. Tandis que le cache de démarrage est compressé de la même façon que le cache ReadyBoost, une autre différence entre ReadyBoost et la gestion de cache ReadyBoot réside dans le fait que, dans le mode ReadyBoot, le cache ne change pas pour refléter les données qui sont lues ou écrites pendant le démarrage (sauf pour les mises à jour du service ReadyBoost). Le service ReadyBoost supprime le cache 90 secondes après le début du démarrage ou si d'autres demandes de mémoire le justifient, et enregistre les statistiques du cache dans HKLM\System\CurrentControlSet\Services\Ecache\Parameters\ReadyBootStats, comme illustré à la figure 2. Les tests de performances de Microsoft montrent que ReadyBoot fournit des améliorations de performances d'environ 20 % de plus que la prélecture Windows XP héritée.
Figure 2** Statistiques de performances de ReadyBoot **(Cliquer sur l'image pour l'agrandir)
ReadyDrive
ReadyDrive est une fonctionnalité de Windows Vista qui tire parti des nouveaux disques durs hybrides appelés H-HDD. Un H-HDD est un disque avec une mémoire flash non volatile intégrée (également appelée NVRAM). En général, les H-HDD comprennent entre 50 Mo et 512 Mo de cache, mais la limite de cache de Windows Vista est de 2 To.
Windows Vista utilise des commandes ATA-8 pour définir les données de disque à conserver dans la mémoire flash. Par exemple, Windows Vista enregistre les données de démarrage dans le cache lorsque le système s'arrête, pour permettre un redémarrage plus rapide. Il stocke également des portions des données du fichier de veille prolongée dans le cache lorsque le système est mis en veille prolongée pour que la reprise ultérieure soit plus rapide. Comme le cache est activé même lorsque le disque est mis en veille, Windows peut utiliser la mémoire flash comme un cache d'écriture sur disque, ce qui évite de se servir du disque lorsque le système fonctionne sur batterie. De cette façon, vous pouvez économiser une grande partie de l'énergie consommée par le lecteur de disque en temps normal.
Base de données de configuration du démarrage
Windows Vista a amélioré plusieurs aspects du démarrage et de l'arrêt. Le démarrage s'est amélioré grâce à l'introduction de la Base de données de configuration du démarrage, qui permet de stocker la configuration du système et du démarrage du système d'exploitation, d'un nouveau flux et d'une nouvelle organisation des processus de démarrage du système, d'une nouvelle architecture d'ouverture de session et de la prise en charge de services de démarrage automatique retardé. Les modifications de l'arrêt dans Windows Vista incluent une notification de pré-arrêt pour les services Windows, le tri des arrêts de services Windows et une modification significative de la façon dont le système d'exploitation gère les transitions de l'état d'alimentation.
L'une des modifications du processus de démarrage les plus notables réside dans l'absence de Boot.ini dans la racine du volume système. Cette absence est due au fait que la configuration du démarrage, qui pour les versions antérieures de Windows était stockée dans le fichier texte Boot.ini, est maintenant stockée dans la base de données de configuration du démarrage. Windows Vista utilise la base de données de configuration du démarrage notamment parce qu'elle unifie les deux architectures de démarrage actuelles prises en charge par Windows : Master Boot Record (MBR) et Extensible Firmware Interface (EFI). L'architecture MBR est généralement utilisée par les systèmes de bureau x86 et x64, tandis que l'architecture EFI est utilisé par les systèmes Itanium (toutefois, les ordinateurs de bureau seront sans doute bientôt touts fournis avec une prise en charge EFI). La base de données de configuration du démarrage fait abstraction du microprogramme et présente d'autres avantages par rapport à Boot.ini, par exemple la prise en charge des chaînes Unicode et d'autres exécutables de pré-démarrage.
La base de données de configuration du démarrage est en fait stockée sur le disque dans une ruche de registre qui se charge dans le Registre Windows pour un accès via les API du Registre. Sur les PC, Windows la stocke dans \Boot\Bcd sur le volume système. Sur les systèmes EFI, elle se trouve sur la partition système EFI. Lorsque la ruche est chargée, elle apparaît sous HKLM\Bcd00000000, mais son format interne n'est pas documenté donc, pour la modifier, il convient d'utiliser un outil tel que %SystemRoot%\System32\Bcdedit.exe. Des interfaces de manipulation de la base de données de configuration du démarrage sont également disponibles pour les scripts et les éditeurs personnalisés par le biais de Windows Management Instrumentation (WMI), et vous pouvez utiliser l'utilitaire de configuration de système Windows (%SystemRoot%\System32\Msconfig.exe) pour modifier ou ajouter des paramètres de base, par exemple des options de débogage du noyau.
La base de données de configuration du démarrage distingue les paramètres de démarrage de la plate-forme, tels que la sélection du système d'exploitation par défaut et l'expiration du menu de démarrage, des paramètres spécifiques au système d'exploitation, tels que les options de démarrage du système d'exploitation et le chemin du chargeur de démarrage du système d'exploitation. Par exemple, la figure 3 montre que, lorsque vous exécutez Bcdedit sans aucune option de ligne de commande, il affiche les paramètres de plate-forme dans la section Gestionnaire de démarrage Windows en haut du résultat, suivis par les paramètres spécifiques au système d'exploitation dans la section Chargeur de démarrage Windows.
Figure 3** Paramètres affichés dans BCDEdit **(Cliquer sur l'image pour l'agrandir)
Lorsque vous démarrez une installation Windows Vista, ce nouveau mode divise les tâches qui étaient gérées par le chargeur du système d'exploitation (Ntldr) sur les versions antérieures de Windows en deux exécutables différents : BootMgr et %SystemRoot%\System32\Winload.exe. Bootmgr lit la base de données de configuration du démarrage et affiche le menu de démarrage du système d'exploitation, tandis que Winload.exe gère le chargement du système d'exploitation. Si vous exécutez un démarrage propre, Winload.exe charge les pilotes de périphérique du démarrage et les fichiers de base du système d'exploitation, notamment Ntoskrnl.exe, et transfère le contrôle au système d'exploitation. Si le système reprend après une veille prolongée, il exécute %SystemRoot%\System32\Winresume.exe pour charger les données de la veille prolongée dans la mémoire et reprendre le système d'exploitation.
Bootmgr inclut également une prise en charge d'exécutables de pré-démarrage supplémentaires. Windows Vista est fourni avec le diagnostic de mémoire Windows (\Boot\Memtest.exe) préconfiguré en tant qu'option pour vérifier l'état de la RAM, mais les fournisseurs tiers peuvent ajouter leurs propres exécutables de pré-démarrage en tant qu'options qui s'afficheront dans le menu de démarrage de Bootmgr.
Processus de démarrage
Dans les versions antérieures de Windows, la relation entre divers processus système n'était pas intuitive. Par exemple, lorsque le système démarre, le gestionnaire d'ouverture de session interactive (%SystemRoot%\System32\Winlogon.exe) lance le service LSASS (Local Security Authority Subsystme) (Lsass.exe) et le Gestionnaire de contrôle des services (Services.exe). Par ailleurs, Windows utilise un conteneur d'espace de noms appelé Session pour isoler les processus s'exécutant dans différentes sessions d'ouverture de session. Mais avant Windows Vista, l'utilisateur connecté à la console partageait la Session 0, la session utilisée par les processus système, ce qui créait des problèmes de sécurité potentiels. L'un de ces problèmes survenait, par exemple, lorsqu'un service Windows mal écrit exécuté dans la Session 0 affichait une interface utilisateur sur la console interactive, permettant ainsi aux logiciels malveillants d'attaquer la fenêtre avec des techniques comme les attaques destructrices (Shatter) et éventuellement de s'accaparer des privilèges administratifs.
Pour résoudre ces problèmes, plusieurs processus système ont été restructurés dans Windows Vista. Le gestionnaire de session (Smss.exe) est le premier processus de mode utilisateur créé pendant le démarrage comme dans les versions antérieures de Windows, mais, dans Windows Vista, le gestionnaire de session se lance une deuxième fois pour configurer la session 0, qui est uniquement consacrée aux processus système. Le processus du Gestionnaire de session pour la session 0 lance l'application de démarrage Windows (Wininit.exe), un processus de sous-système Windows pour la session 0 et il se ferme ensuite. L'application de démarrage Windows poursuit en démarrant le Gestionnaire de contrôle des services, le sous-système d'autorité de sécurité locale et un nouveau processus, le Gestionnaire de session locale (Lsm.exe), qui gère les connexions aux serveurs terminaux pour l'ordinateur.
Lorsqu'un utilisateur se connecte au système, le Gestionnaire de session initial crée une nouvelle instance de lui-même pour configurer la nouvelle session. Le nouveau processus Smss.exe démarre un processus de sous-système Windows et un processus Winlogon pour la nouvelle session. Le fait que le Gestionnaire de session primaire utilise des copies de lui-même pour initialiser de nouvelles sessions n'offre aucun avantage sur un système client, mais sur les systèmes « Longhorn » de Windows Server servant de serveurs terminaux, plusieurs copies peuvent s'exécuter simultanément pour permettre une connexion plus rapide de plusieurs utilisateurs.
Avec cette nouvelle architecture, les processus système, notamment les services Windows, sont isolés dans la session 0. Si un service Windows, qui s'exécute dans la session 0, affiche une interface utilisateur, le service de Détection de services interactifs (%SystemRoot%\System32\UI0Detect.exe) notifie les administrateurs connectés en lançant une instance de lui-même dans le contexte de sécurité de l'utilisateur et en affichant le message illustré à la figure 4. Si l'utilisateur sélectionne le bouton « Afficher le message », le service fait passer le Bureau en Bureau de service Windows, où l'utilisateur peut interagir avec l'interface utilisateur du service, avant de revenir à son propre Bureau. Pour en savoir plus sur le déroulement du démarrage, consultez l'encadré « Affichage des relations des processus de démarrage ».
Figure 4** Le service a affiché une fenêtre **(Cliquer sur l'image pour l'agrandir)
Affichage des relations des processus de démarrage
Vous pouvez utiliser Process Explorer de Sysinternals (microsoft.com/technet/sysinternals) pour voir l'arborescence de démarrage des processus de Windows Vista.
La capture d'écran comprend la colonne Session, que vous pouvez ajouter par le biais de la boîte de dialogue de colonne de Process Explorer. Le processus mis en surbrillance est le Smss.exe initial. En dessous se trouvent le Csrss.exe et le Wininit.exe de la session 0, qui sont justifiés à gauche puisque leur processus parent, l'instance de Smss.exe ayant configuré la session 0, s'est refermé. Les trois enfants de Wininit sont Services.exe, Lsass.exe et Lsm.exe.
Process Explorer identifie une série de processus exécutés dans la Session 1, c'est-à-dire la session à laquelle je suis connectée via une connexion Bureau à distance. Process Explorer affiche les processus exécutés dans le compte que lui avec une surbrillance bleue. Pour finir, la Session 2 a été initialisée pour une préparation à la connexion d'un utilisateur sur la console et la création d'une nouvelle session de connexion. C'est dans cette session que Winlogon s'exécute et utilise LogonUI pour donner l'instruction suivante aux nouveaux utilisateurs de la console : « Appuyez sur CTRL+ALT+SUPPR pour ouvrir une session ». C'est aussi dans cette session que Logonui.exe demandera à l'utilisateur ses informations d'identification.
Processus de démarrage et informations sur la session(Cliquer sur l'image pour l'agrandir)
Fournisseurs d'informations d'identification
Même l'architecture d'ouverture de session a été modifiée dans Windows Vista. Dans les versions antérieures de Windows, le processus Winlogon chargeait la DLL GINA (Graphical Identification and Authentication) spécifiée dans le registre pour afficher une IU d'ouverture de session qui demandait aux utilisateurs leurs informations d'identification. Malheureusement, le modèle GINA est soumis à plusieurs limitations, notamment le fait que seul une GINA peut être configurée, l'écriture d'une GINA complète est difficile pour les tiers et les GINA personnalisées qui ont des interfaces utilisateur non standard modifient l'expérience de l'utilisateur Windows.
Au lieu d'une GINA, Windows Vista utilise la nouvelle architecture des fournisseurs d'informations d'identification. Winlogon lance un processus séparé, l'hôte de l'interface utilisateur d'ouverture de session (Logonui.exe), qui charge les fournisseurs d'informations d'identification configurés dans HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\Currentversion\Authentication\Credential Providers. Logonui peut héberger plusieurs fournisseurs d'informations d'identification simultanément. En fait, Windows Vista est fourni avec des fournisseurs interactifs (Authui.dll) et de cartes à puce (Smart-cardcredentialprovider.dll). Pour garantir une expérience utilisateur uniforme, LogonUI gère l'interface utilisateur qui s'affiche aux utilisateurs finaux, mais il permet également aux fournisseurs d'informations d'identification de spécifier des éléments personnalisés tels que le texte et les icônes et de modifier des contrôles.
Services de démarrage automatique retardé
Si vous vous êtes déjà connecté à un système Windows tout de suite après son démarrage, vous avez sans doute été confronté à des retards avant que votre bureau ne soit entièrement configuré et que vous puissiez interagir avec le shell et toute application lancée. Pendant que vous ouvrez une session, le Gestionnaire de contrôle des services démarre les nombreux services Windows qui sont configurés en tant que services à démarrage automatique et qui s'activent donc au moment du démarrage. De nombreux services réalisent des initialisations sollicitant le processeur et le disque en même temps que vos activités d'ouverture de session. Pour tenir compte de ceci, Windows Vista introduit un nouveau type de démarrage de service appelé démarrage automatique retardé, que les services peuvent utiliser s'ils ne doivent pas forcément être actifs tout de suite après les démarrages de Windows.
Le Gestionnaire de contrôle des services démarre les services configurés pour le démarrage automatique retardé une fois que les services à démarrage automatique ont fini de démarrer et il définit la priorité de leur thread initial sur THREAD_PRIORITY_LOWEST. En raison de ce niveau de priorité, toutes les E/S de disque réalisées par le thread ont une priorité d'E/S très basse. Lorsqu'un service a fini de s'initialiser, le Gestionnaire de contrôle des services définit sa priorité sur normal. La combinaison du démarrage retardé, de la priorité basse du processeur et de la mémoire et la priorité du disque en arrière-plan réduit considérablement les interférences avec une ouverture de session d'utilisateur. De nombreux services Windows, notamment le service de transfert intelligent en arrière-plan, le client Windows Update et Windows Media® Center, utilisent le nouveau type de démarrage pour aider à améliorer les performances des ouvertures de session après un démarrage.
Arrêt
Un problème qui a tourmenté les auteurs des services Windows est le fait que, pendant un arrêt de Windows, ils ont, par défaut, vingt secondes maximum pour exécuter un nettoyage. Les versions de Windows antérieures à Windows Vista ne prenaient pas en charge un arrêt propre attendant la fermeture de tous les services parce qu'un service bogué peut empêcher l'arrêt indéfiniment. Certains services, comme ceux dont certaines opérations d'arrêt sont liées au réseau ou ceux qui doivent enregistrer de grandes quantités de données sur le disque, pourraient avoir besoin de plus de temps. C'est pour cette raison que Windows Vista permet aux services de demander une notification de pré-arrêt.
Lorsque Windows Vista s'arrête, le Gestionnaire de contrôle des services commence par notifier les services demandant une notification de pré-arrêt. Il attendra indéfiniment que ces services se ferment, mais s'ils ont un bogue et qu'ils ne répondent pas aux requêtes, le Gestionnaire de contrôle des services renonce et poursuit sur sa lancée au bout de trois minutes. Une fois que tous ces services sont fermés ou que le délai a expiré, le Gestionnaire de contrôle des services procède à l'arrêt des services de type hérité pour le reste des services. La stratégie de groupe et les services Windows Update inscrivent la notification de pré-arrêt dans une nouvelle installation de Windows Vista.
La stratégie de groupe et les services Windows Update utilisent également une autre fonctionnalité des services Windows Vista : le tri des arrêts. Les services ont toujours pu spécifier les dépendances de démarrage que le Gestionnaire de contrôle des services honore pour démarrer des services dans un ordre qui les satisfait, mais avant Windows Vista, ils étaient incapables de spécifier les dépendances d'arrêt. À présent, les services qui s'inscrivent pour recevoir une notification de pré-arrêt peuvent également s'insérer dans la liste stockée dans HKLM\System\CurrentControlSet\Control\PreshutdownOrder pour que le Gestionnaire de contrôle des services les ferme en fonction de leur ordre. Consultez l'encadré « Identification d'un démarrage automatique retardé et d'un service de pré-arrêt » pour en savoir plus sur ces services.
Gestion de l'alimentation
La veille et la veille prolongée sont d'autres formes d'arrêt et la mauvaise gestion de l'alimentation dans les pilotes et les applications gâchait la vie des personnes mobiles depuis l'introduction par Windows 2000 de la gestion de l'alimentation dans la gamme des systèmes d'exploitation Windows basés sur Windows NT®. De nombreux utilisateurs s'attendaient à ce que leur système portable s'interrompe ou se mette en veille prolongée lorsqu'ils le refermaient avant d'entreprendre un voyage, mais, à leur arrivée, ils étaient surpris de trouver leur étui chaud, leur batterie morte et certaines de leurs données disparues. C'est parce que Windows a toujours demandé l'accord des pilotes de périphérique et des applications pour changer d'état et il suffisait qu'un seul pilote ou une seule application ne réponde pas pour que la transition soit empêchée.
Dans Windows Vista, le gestionnaire de l'alimentation du noyau informe toujours les pilotes et applications des changements d'état de l'alimentation pour qu'ils puissent s'y préparer, mais leur autorisation n'est plus demandée. De plus, le gestionnaire de l'alimentation attend, pendant 20 secondes au maximum, une réponse des applications aux notifications de changements, plutôt que les deux minutes des versions antérieures de Windows. Par conséquent, les utilisateurs de Windows Vista peuvent être plus confiants que leurs systèmes respectent les veilles prolongées et s'interrompent.
À venir
Comme mentionné plus haut, il s'agit du second volet d'une série en trois épisodes. La première partie concernait les améliorations du noyau Windows Vista dans les domaines des E/S et des processus. Cette fois, j'ai parlé des améliorations de Windows Vista dans les domaines de la gestion de la mémoire, du démarrage et de l'arrêt. La prochaine fois, je conclurai la série en décrivant les modifications du noyau dans les domaines de la fiabilité et de la sécurité.
Identification d'un service de démarrage automatique retardé et de pré-arrêt
La commande SC intégrée est mise à jour dans Windows Vista pour montrer les services configurés en tant que services à démarrage automatique retardé :
Utilisation de SC pour afficher le type de démarrage(Cliquer sur l'image pour l'agrandir)
Malheureusement, la commande SC ne signale pas les services qui ont demandé une notification de pré-arrêt, mais vous pouvez utiliser l'utilitaire PsService de Sysinternals pour voir si un service accepte la notification de pré-arrêt :
Affichage de l'état de pré-arrêt(Cliquer sur l'image pour l'agrandir)
Mark Russinovich est technicien dans le service responsable des plates-formes et services chez Microsoft. Coauteur de l'ouvrage intitulé Microsoft Windows Internals (Microsoft Press, 2004), il participe fréquemment à des conférences pour informaticiens et développeurs. Il a rejoint récemment rejoint nos équipes lorsque Microsoft a racheté Winternals Software, la société dont il était le cofondateur. Il a également créé la société Sysinternals qui a publié les utilitaires Process Explorer, Filemon et Regmon.
© 2008 Microsoft Corporation et CMP Media, LLC. Tous droits réservés. Toute reproduction, totale ou partielle, est interdite sans autorisation préalable.