Ce document est en cours de développement, est sujet à de nombreux changements, et vous est fourni en tant qu’aperçu. Le contenu et les instructions qui s’y trouvent ne doivent pas être considérés comme complets, et devraient être utilisés avec précautions.

Invitation à la découverte des capacités et performances du célèbre système d’exploitation, cet ouvrage décrit l’architecture et le fonctionnement interne de Microsoft Windows. Vous y trouverez le descriptif des technologies qui régissent ce système, ainsi que des informations sur la nature et le caractère global, pour comprendre pourquoi il se comporte comme il le fait, sur la programmation, pour appréhender quelles décisions sont les meilleures en matière de conception de logiciels, sur l’optimisation et le dépannage, pour que vos systèmes fonctionnent avec une efficacité maximale. Une version PDF est disponible.

Cet ouvrage a été rédigé dans le contexte de l’Epitech Innovation Hub, un espace dédié aux expérimentations et au développement de projets innovants.

Sommaire

Introduction

Ce livre invite le lecteur dans la nébuleuse des systèmes d’exploitation Microsoft Windows. Il s’adresse à un public de curieux : utilisateurs avancés, développeurs, administrateurs, professionnels expérimentés ; des profils hétéroclites, séduits par l’envers du miroir et les arcanes de Windows, qui souhaiteraient comprendre la façon dont ce système fonctionne. A l’issue de la lecture de cet ouvrage, vous devriez avoir acquis une bonne connaissance des points clés qui gouvernent (architecture générale et composants fondamentaux), des mécanismes centraux qui contrôlent (dispositifs et technologies), des structures de données et des algorithmes qui régissent la structure interne de ce système d’exploitation. Nous espérons que vous aurez plaisir à lire cet ouvrage autant que nous avons eu à l’écrire, et vous souhaitons bon voyage dans ces coulisses de Windows.

À qui s’adresse ce livre ?

Ce livre a pour vocation d’apporter un éclairage exhaustif en ce qui concerne les systèmes d’exploitation de la gamme Microsoft Windows. Il propose ainsi un ensemble de concepts, d’outils, et de méthodes se rapportant aux dynamiques fonctionnelles (comprendre les technologies en place et les dispositifs en oeuvre) de ces systèmes, et se veut donc au fond être une opportunité offerte à toute personne intéressée à ce sujet - étant donné le caractère multidimensionnel du propos, ces sujets. Les profils concernés incluent tout particulièrement étudiants, enseignants et formateurs, utilisateurs avancés, concepteurs de logiciels, administrateurs et ingénieurs systèmes.

L’axe scientifique de cet ouvrage pourrait vous avoir laissé croire que son contenu était seulement pensé pour un public restreint. Si nous comprenons les raisons à l’origine de cette perspective, vraie en premier lieu, notez que de nombreux efforts ont été faits pour rendre ce livre accessible et agréable y compris à un plus large lectorat. Résultat, surtout, d’une attitude de curiosité envers les systèmes d’exploitation, c’est à cette même démarche que nous invitons le lecteur.

Structure de ce livre

Cet livre s’articule autour de dix-neuf chapitres :

  • Chapitre 1, Concepts et outils Ce chapitre ouvre le bal en introduisant la terminologie et les concepts clé qui seront employés tout au long de l’ouvrage.

  • Chapitre 2, Architecture du système Ce chapitre effectue un tour d’horizon des caractéristiques structurales de Windows, définit les grandes lignes de sa structure interne, et examine les liens et interactions entre les composants clé du système d’exploitation.

  • Chapitre 3, Mécanismes système Ce chapitre décrit quelques-uns des mécanismes de contrôle principaux qu’emploie Windows.

  • Chapitre 4, Mécanismes de gestion, Ce chapitre couvre quelques-uns des mécanismes offerts par Windows en ce qui concerne l’administration et la configuration du système, y compris le registre, les services, et WMI (Windows Management Instrumentation).

  • Le chapitre 5, « Gestionnaire d’objets », traite de la manière dont Windows prend en charge le contrôle et le suivi des ressources systèmes.

  • Le chapitre 6, « Synchronisation », présente les dispositifs de synchronisation que fournit Windows en vue de contrôler les interactions entre threads, et de la sorte éliminer les conditions de concurrence critique.

  • Le chapitre 7, « Processus et threads », présente les notions fondamentales que sont les processus et les threads, et décrit les différents algorithmes qui y sont associés.

  • Chapitre 8, Communication inter processus

  • Chapitre 9, Gestion de la mémoire

  • Le chapitre 10, "Portable Executable", examine l’anatomie générale et fonctionnelle des modules Windows (programmes exécutables, bibliothèques, etc.) organisés suivant le format PE (Portable Executable).

  • Chapitre 11, Sécurité

  • Chapitre 12, Réseau

  • Chapitre 13, Système d’E/S Ce chapitre restitue l’exploration du modèle d’E/S Windows et de son rôle de médiation entre le système et les périphériques.

  • Chapitre 14, Gestion de l’alimentation

  • Chapitre 15, Gestion du stockage Ce chapitre s’intéresse aux dispositifs classique en matière d’organisation des informations et traite de différents principes selon lesquels les fichiers sous Windows peuvent être manipulés (FAT, NTFS, etc.)

  • Chapitre 16, Systèmes de fichiers Ce chapitre présente l’organisation et le fonctionnement interne de quelques systèmes de fichiers Windows.

  • Chapitre 17, Démarrage et arrêt Ce chapitre explique les procédures et les processus essentiels en oeuvre lors du démarrage et de l’arrêt de l’ordinateur.

  • Le chapitre 18, "Gestionnaire de cache", décrit les fonctionnalités de mise en cache que Windows met en oeuvre pour augmenter la réactivité de l’ordinateur.

  • Chapitre 19, Interceptions Ce chapitre s’intéresse à comment Windows met en oeuvre les interceptions, à savoir interruptions, exceptions et services système.

À propos de la licence

Ce livre est publié sous licence CC BY-NC-ND. Concrètement, ces termes d’utilisation vous donnent le droit de copier, distribuer et communiquer le matériel par tous moyens et sous tous formats. Ils excluent par contre, sans permission expresse de l’auteur, la possibilité de modifier cette oeuvre ou de l’utiliser à des fins commerciales. (De manière générale, chacune des conditions parmi les licences Creative Commons peut être levée via autorisation du titulaire des droits.) Si ces critères peuvent au premier lieu sembler restrictifs, notez qu’il s’agit essentiellement de faire obstacle à la reproduction massive et incontrôlée de cet ouvrage. Pour plus d’information sur les licences Creative Commons, consultez le site http://creativecommons.org.

Outils et licenses d’utilisation

Tout au long de ce livre, nous présentons différents logiciels que nous mettons à l’honneur à titre d’outils pédagogiques lors de toutes sortes de scénarios. Quelques-uns de ces utilitaires sont fournis avec le système d’exploitation (autrement dit intégrés à Windows, et de la sorte utilisables sans délai), tandis que d’autres sont des applications tierce partie disponibles sur Internet. Si nous nous efforçons de révéler toujours les adresses à partir desquels récupérer ces ressources, les liens web vont et viennent, leur pérennité n’est en conséquence pas garantie. De plus, une large majorité de ces logiciels implique que vous ayez lu et accepté pleinement les termes et conditions d’utilisation qui s’y rapportent. Veillez aussi dans ce contexte à comment vous comptez donner lieu à cet accord. Par exemple, les outils affiliés à Microsoft/Sysinternals affichent dans une boîte de dialogue un contrat de licence utilisateur final (CLUF) lors de leur première utilisation. Vous devez dès lors non seulement accepter le CLUF, mais, si vous exécutez l’outil dans un fichier de commandes sur un système où il n’a jamais été employé (comprendre que l’image exécutable idoine n’a pas été sollicitée une seule fois à ce stade), le faire en incluant l’option appropriée sur la ligne de commande. Dans le cas contraire, une fenêtre modale surgit, empêchant par nature l’accès à toutes les autres fonctionnalités de l’application.

Assistance

Tous les efforts ont été faits rendre cet ouvrage aussi complet et précis qu’on puisse le désirer, aussi exempt d’erreurs que possible. Cependant, si vous rencontrez des fautes (d’ordre technique ou tout simplement de syntaxe), des inexactitudes ou si certains passages vous semblent confus, n’hésitez pas à les signaler en écrivant à l’auteur : maillard.arnaud@gmail.com.

Si une maladresse que vous souhaitez souligner relève d’un caractère strictement technique, nous vous serions reconnaissant de montrer une preuve de la solidité de vos propos, soit via indication de quelles pistes vous ont guidées (routines de programmation, attributs de structures de données, ou tout autre élément susceptible de conduire à l’identification de l’erreur), ou mieux encore, et de façon plus tangible, en joignant à vos commentaires les démonstrations (extraits de logs, captures d’écran, simulations d’une expérience dans le débogueur noyau, etc.) nécessaires à l’éclaircissement des faits.

Pour une assistance technique sur les logiciels Microsoft, consultez le site http://support.microsoft.com. Pour obtenir de l’assistance sur Microsoft Windows, allez à http://www.microsoft.com/windows. Vous pouvez également vous connecter directement à la base de connaissance Microsoft et saisir une question concernant un problème en allant sur http://support.microsoft.com/search/.

Précisions sur le glossaire

Comme la plupart des oeuvres touchant à des domaines techniques très spécifiques, ce livre se termine par un glossaire. D’ordre général un recueil de termes associés à leurs définitions, nous employons en ce qui nous concerne le glossaire de façon plus large, et profitons en l’occurrence de cet espace afin de clarifier certaines des traductions qui ont été faites - le vocabulaire entourant Microsoft Windows (et, du reste, les systèmes d’exploitation en général), né de la culture anglo-saxonne, supportant quelquefois assez mal le passage au français. Quelques exemples : objet mutant, routines de diffusion, verrous rotatifs, et bien d’autres.

En ce qui concerne la lecture

Afin d’aider le lecteur à mieux se repérer parmi les moults informations procurées dans ce livre, chaque chapitre a été conçu de telle sorte à pouvoir être consulté indépendamment. Dans le même esprit, chaque section/segment tente, dans la mesure du possible, d’être en situation de suffisance vis à vis des autres.

Concepts et outils

Dans ce chapitre, nous allons introduire les principes ontologiques essentiels des systèmes d’exploitation en général, et de Microsoft Windows en particulier. Nous verrons dans un premier temps les notions de base relatives aux systèmes d’exploitation ; ce qu’ils proposent, ce qu’ils font, et pourquoi ils existent sous les formes qu’on leur connaît. L’étude se poursuivra sur l’évolution de Windows, dont le noyau et coeur opérationnel, s’il remonte aux années quatre-vingt, occupe depuis lors une place centrale dans le paysage informatique contemporain. Nous présenterons ensuite les concepts et termes fondamentaux de Microsoft Windows qui seront utilisés dans tout ce livre ; l’occasion de s’intéresser aux processus et aux threads, de découvrir les objets, voir comment utiliser les interfaces de programmation applicative (API), découvrir la base de registre, etc. Nous présenterons également les outils rendant possible l’exploration des coulisses du système, tels le débogueur noyau, la console Performances et d’autres utilitaires clé, tous la source de précieux enseignements sur les mécanismes internes de Windows.

Veillez à connaitre tout ce qui est décrit dans ce chapitre pour pouvoir comprendre le reste de cet ouvrage.

Systèmes d’exploitation

Windows étant une incarnation d’un système d’exploitation parmi d’autres - du reste ancrée dans le temps, par le biais des versions du logiciel, il nous a paru opportun avant de consacrer toute la lumière au thème central de cet ouvrage, d’accorder une place, quoique modeste, sur les processus par lesquels de tels logiciels étaient conçus, implantés et gérés. A titre informatif, notez que les notions passées en revue le sont dans une optique générale, déconnectée de tout système particulier - elles restent bien évidement valides dans le contexte de Microsoft Windows.

Ce qu’est un noyau

Pièce maîtresse dans le fonctionnement d’une grande majorité de systèmes d’exploitation, le noyau gère les ressources informatiques de base, incluant le matériel, le logiciel et les données, et ressemble à cet égard à un chef d’orchestre, dont le rôle est la coordination harmonieuse des éléments en place.

En tant que partie du système d’exploitation (il est est lui-même un logiciel), le noyau fournit des mécanismes d’abstraction du matériel, notamment de la mémoire, du (ou des) processeur(s), et des échanges d’informations entre logiciels et périphériques matériels.

Chaque noyau de système d’exploitation à un rôle et un usage. Ainsi, certains noyaux sont conçus dans l’optique de pouvoir fonctionner sur différentes plateformes matérielles, quelques-uns pour être particulièrement robustes, d’autres pour avoir des performances élevées, d’autres encore pour combiner, moyennant certains compromis, les trois. En parallèle, un noyau n’a d’existence que sur une architecture machine donnée, laquelle est la spécification fonctionnelle d’un processeur (jeu d’instructions, ensembles de registres visibles, organisation de la mémoire, etc.). C’est au final les capacités de l’architecture sous-jacente qui déterminent ce que peut faire le noyau, à lui de construire par dessus elle un environnement concret.

L’un des aspects les plus important des noyaux de système d’exploitation est la réalisation du concept d’abstraction, qui vise à représenter de manière commode (et surtout commune), la diversité des approches et des matériels. Cette façon de faire est avantageuse en plusieurs points : elle isole le matériel des applications (une application ne s’adresse au matériel qu’indirectement et sous l’aval du noyau) et les applications du matériel (les applications ne sont pas au fait du fonctionnement interne de la machine).

Différents types de noyaux

Un aspect incroyable des noyaux de système d’exploitation est la diversité des approches pour les concevoir. Il existe ainsi toutes sortes de noyaux, plus ou moins spécialisés. Certains spécifiques à une architecture, d’autres sont généralistes ; certains sont destinés aux ordinateurs personnels, d’autres aux serveurs, aux terminaux nomades ou aux consoles de jeux. L’ensemble de ces noyaux peut être divisé en deux démarches opposées d’architectures logicielles, les noyaux monolithiques et les micronoyaux, chacune définissant la manière d’aborder les fondamentaux du système.

  • Noyaux monolithiques non modulaires Dans un noyau monolithique non modulaire, les fonctions et extensions (pilotes) du système forment un seul bloc binaire généré à la compilation. De par la simplicité de leur concept, les noyaux monolithiques ont été les premiers à être développés et mis en œuvre.

  • Noyaux monolithiques modulaires Dans un noyau monolithique modulaire, seules les fonctions fondamentales du noyau sont gardées dans un bloc monolithique. Les pilotes de périphériques sont séparés sous la forme de module qui pourront être chargés à la demande.

  • Systèmes à micro-noyaux Les systèmes à micronoyaux cherchent à minimiser les fonctionnalités dépendantes du noyau en plaçant la plus grande partie des services du système d’exploitation à l’extérieur de ce noyau, c’est-à-dire dans l’espace utilisateur. Ces fonctionnalités sont alors fournies par des processus indépendants et autonome, ce dans l’optique de limiter - en théorie – l’impact des dysfonctionnements potentiels.

Ce que propose un système d’exploitation

Un système d’exploitation (OS, Operating System) est une collection de programmes qui joue le rôle d’intermédiaire entre l’utilisateur d’un ordinateur et ses programmes d’une part, et le matériel de l’ordinateur d’autre part.

Malgré les différences de point de vue, de forme, de taille et de type, un système informatique peut-être divisé grossièrement en quatre composants : le matériel, le système d’exploitation, les programmes applicatifs et les utilisateurs. Les programmes applicatifs - tels que les traitements de texte, les jeux vidéo, les tableurs et les navigateurs internet - définissent les mécanismes adéquats pour résoudre les problèmes informatiques des utilisateurs. Le matériel, composé des processeurs qui exécutent les instructions, de la mémoire centrale qui contient les données et les instructions à exécuter, de la mémoire secondaire qui sauvegarde les informations, et des périphériques d’entrées/sorties (clavier, souris, écran, etc.) pour introduire ou récupérer des informations, fournit les ressources informatiques de base. Le système d’exploitation contrôle et coordonne l’utilisation de ces ressources parmi les divers programmes applicatifs pour les divers utilisateurs. Il reçoit à ce titre de la part des programmes des demandes d’utilisation des capacités de l’ordinateur - capacité de stockage des mémoires (mémoire de masse et mémoire volatile), capacité de traitement de l’unité centrale (central processing unit ou processeur), capacité d’utilisation des périphériques connectés à la machine (dispositifs d’entrée/sortie).

Fonctions d’un système d’exploitation

Les systèmes d’exploitation modernes sont constitués de centaines de milliers, voire de millions de lignes de code. Ils ont comme rôle primordial la gestion des ressources informatiques de base (processeur, mémoire et périphériques) pour divers utilisateurs.

  • Gestion du processeur Le système d’exploitation contrôle et coordonne l’utilisation du processeur parmi les applications et les utilisateurs, ce sur la base d’un algorithme d’ordonnancement permettant à toute tâche de s’exécuter à un moment ou un autre.

  • Gestion de la mémoire vive Le système d’exploitation est chargé de gérer l’espace mémoire alloué à chaque application, et partant, chaque utilisateur. Comme la mémoire vive est généralement trop petite pour contenir toutes les données et tous les programmes, le système d’exploitation peut créer une zone mémoire auxiliaire sur le disque dur, et réaliser ce faisant le principe de mémoire virtuelle, qui permet de faire fonctionner des applications nécessitant plus de mémoire qu’il en existe de physiquement disponible sur le système. En contrepartie, cette mémoire est plus lente.

  • Gestion des processus Le système d’exploitation est chargé du déroulement des applications, gérant à ce titre et de façon optimale les ressources nécessaires à leur bon fonctionnement. Il organise et rend visible en parallèle nombre de dispositifs permettant aux programmeurs de concevoir des logiciels, et aux utilisateurs d’interagir avec ces derniers, par exemple fin à une application ne répondant plus correctement.

  • Gestion des droits Le système d’exploitation veille à la sécurité des programmes et à la confidentialité des données. Il empêche les applications de lui nuire, de compromettre d’autres applications, et garantit en sus que les ressources ne sont utilisées que par les programmes et utilisateurs possédant les droits adéquats.

  • Gestion des fichiers Le système d’exploitation permet l’enregistrement sur support de stockage (disque dur, SSD, CD-ROM, clé USB, disquette, etc.) de collections d’informations numériques, ce qui laisse la possibilité de traiter et de conserver des quantités importantes de données, ainsi que de les partager entre plusieurs programmes informatiques.

  • Gestion des entrées-sorties Le système d’exploitation contrôle les périphériques associés à l’ordinateur. Il régule l’accès des programmes aux ressources matérielles par l’intermédiaire des pilotes, et fait la gestion des flux de données en entrée comme en sortie.

Exemples de systèmes d’exploitation

Dans le secteur informatique, les systèmes d’exploitation les plus répandus sont Windows, dont Windows 10 est la déclinaison la plus récente ; Mac OS, pour les ordinateurs d’Apple, Linux et Unix. Pour les terminaux légers, on trouve Android, iOS et Windows Phone.

Mémoire virtuelle

Windows implémente un système de mémoire virtuelle qui donne à chaque processus l’illusion de disposer d’un très large espace d’adressage, et d’en être de surcroît le seul détenteur. En effet, pour un processus donné, tout se passe comme s’il possédait les adresses 0 à x, sachant que c’est dans cette configuration le système d’exploitation qui, par l’intermédiaire du matériel, se charge de faire une conversion des adresses virtuelles en adresses physiques. Par exemple, si l’on considère une adresse 32 bits, chaque processus se pense dépositaire de la mémoire depuis l’adresse 0 jusqu’à l’adresse 2^32-1, à quoi correspond un espace d’adressage maximal de 4 Go. C’est en définitive le rôle de la mémoire virtuelle de faire correspondre besoins réels en mémoire, adresses mémoire virtuelles utilisées par les processus, et mémoire physique réelle.

La mémoire virtuelle fournit une vue logique de la mémoire éventuellement décorrélée de sa disposition physique. Applications utilisateur et code système référencent des adresses virtuelles. Lors de l’exécution, le gestionnaire de mémoire, épaulé à cette fin par l’unité matérielle de gestion mémoire (MMU, Memory Management Unit), traduit ou mappe les adresses virtuelles en adresses physiques, lesquelles contiennent effectivement les données.

Telle que la mettent en oeuvre les systèmes et les équipements actuels, la mémoire virtuelle est le plus souvent basée sur un mécanisme de pagination, cela afin d’en augmenter la taille théorique maximale.

Les bases fondamentales sur lesquelles s’appuie la pagination se présentent sous les formes que voici : la mémoire centrale est découpée en cadres de taille identique (par exemple 4 Ko). L’espace d’adressage virtuel est quant à lui divisé en unité appelées pages. Chaque segment de la mémoire en cours d’exécution réside alors dans un certain nombre de pages. Une page est un ensemble d’octets qui peut résider dans un cadre. Au fur et à mesure qu’un processus demande de la mémoire, une page lui est allouée. Le nombre de pages alloués à l’ensemble des processus est souvent supérieur au nombre de cadres de la mémoire physique. C’est en l’occurence le disque dur qui permet de stocker les pages allouées en sus du nombre de cadres, cela par le biais d’un fichier d’échange.

La plupart des machines ayant beaucoup moins de mémoire physique que la mémoire virtuelle totale utilisée par les processus en cours d’exécution, le gestionnaire de mémoire transfère ou pagine une partie du contenu de la mémoire vers le disque. Cela signifie qu’à tout moment, un certain nombre de pages de mémoire allouées aux processus résident en mémoire centrale, le reste dans la mémoire secondaire (autrement dit le fichier d’échange). Quand un thread accède à une adresse virtuelle qui a été paginée vers le disque, le gestionnaire de mémoire recharge les données depuis le disque vers la mémoire centrale. Ce processus est transparent pour les applications.

L’approche employée pour choisir les pages à remiser dans le fichier d’échange s’appuie le plus souvent sur le nombre d’accès à une page (ce qui en préfigure la nécessité) et/ou sa dernière date d’accès. L’objectif de cette stratégie est de minimiser les défauts de page qui, s’ils font partie du fonctionnement normal de la mémoire virtuelle, n’en restent pas moins un handicap pour la rapidité d’exécution de l’ensemble du système.

Ainsi que nous l’avons déjà mentionné, la transformation adresse virtuelle/adresse physique est du ressort de l’unité matérielle de gestion mémoire (MMU). Si cette dernière se présentait autrefois sous la forme d’une puce spécialisée prenant place entre le processeur et la mémoire, les processeurs actuels l’intègrent nativement, cela pour des raisons de performance.

La taille de l’espace d’adressage virtuel varie selon la plateforme matérielle et la version de Windows qui l’anime. Généralement, sur les systèmes x86 32 bits, l’espace d’adressage virtuel total a un maximum théorique de 4 Go, dont 2 sont dévolus aux processus du mode noyau, et 2 autres aux processus du mode utilisateur. Dans l’éventualité où la machine dispose de suffisamment de mémoire physique (1 Go minimum), cette configuration peut évoluer de façon à donner aux processus exécutant des programmes spécialement calibrés pour la possibilité d’utiliser 3 Go d’adressage privé, laissant ainsi 1 Go au système d’exploitation.

Si une large majorité des processus se satisfont pleinement des quantités de mémoire dont nous avons parlé jusqu’à présent, quelques-uns manifestent à cet égard de plus gros besoin, par exemple les applications du genre serveur de base de données ou logiciel d’édition vidéo. Pour résoudre ce problème sur les systèmes 32 bits, dont les limites architecturales peuvent en ce qui concerne ces cas se révéler un véritable frein, Windows fournit un mécanisme appelé AWE (Address Windowing Extension) qui permet à une application 32 bits de manipuler une capacité de mémoire supérieure aux 2 ou 3 Go disponibles par le biais des dispositifs d’adressage standards.

Les systèmes 64 bits ouvrent la voie à un espace d’adressage particulièrement volumineux, à savoir 16 Eo (2^64). Dans la pratique, toutefois, les versions actuelles de Windows 64 bits ne vont pas au delà de 8192 Go de mémoire adressable.

Indépendamment de la taille jusqu’à laquelle peut aller l’espace d’adressage, Windows alloue (sauf configuration particulière) la moitié de cet espace (en l’occurence la moitié inférieure) aux processus du mode utilisateur (par exemple, les applications), leur procurant de cette manière un volume de stockage privé individuel relativement confortable, et utilise l’autre moitié (la moitié supérieure, donc) pour les processus du mode noyau (par exemple, le système d’exploitation et les pilotes). Alors que les mappages de la moitié inférieure évoluent pour refléter l’espace d’adressage virtuel du processus qui est en cours d’exécution, les mappages de la moitié supérieure sont immuables, et de la sorte visibles depuis tous les processus.

Ordonnancement

La sélection dans le temps des processus pouvant accéder aux ressources de l’ordinateur est un problème dit d’ordonnancement. Nous présentons dans cette section le cas général, les besoins, et décrirons différents algorithmes mettant en œuvre la politique générale d’ordonnancement dans divers systèmes d’exploitation.

Objectifs d’un ordonnanceur

Si la politique générale du système d’exploitation peut en intégrer d’autres, les objectifs les plus communs en matière d’ordonnancement visent en ce sens une utilisation harmonieuse des ressources entre tous les processus parmi l’ensemble des utilisateurs. Cette optique a généralement trait à plusieurs facteurs :

  • Maximiser l’utilisation du processeur le système doit faire en sorte que tout processus passe le moins de temps possible dans un état d’ordonnancement incompatible avec la possibilité d’être élu comme prochain (comprendre prochain processus à exécuter). Il doit pour ce faire être capable d’identifier les relations de dépendances entre les divers processus et, par exemple, prioriser ceux détenteurs d’une ressource afin que les attendeurs de la dite ressource puisse devenir des unités ordonnancables directement.

  • Présenter un temps de réponse acceptable L’expérience utilisateur au niveau des délais, avec laquelle sera en majorité jugé le système, ne doit souffrir d’aucune quelconque pénalité venue de décisions d’ordonnancement. Nombre de systèmes modernes atteignent cet objectif via un système de priorité assignant une plus haute aux threads faisant fonctionner des éléments graphiques.

  • Respecter l’équité entre les processus Selon le critère d’ordonnancement utilisé, les processus gérés par l’ordonnancement doivent généralement être traités à égalité. S’il existe des priorités, le privilège se limitera à elles.

  • S’assurer de l’absence de famine Les décisions issues de l’ordonnancement doivent autant que possible éviter de mettre les travaux gérés en famine, où un ou plus processus pourrait se voir refuser l’accès à une ressource pendant un temps indéterminé. L’algorithme doit ne pas créer ces situations, et encore savoir les éviter et comment les prévenir si elles ont lieu.

Critères d’ordonnancement

Un objectif majeur de toute stratégie d’ordonnancement est l’optimalité, établie via des algorithmes qui sont compromis entre sûreté et vivacité, et doivent en ce sens identifier quel processus conduira aux meilleures performances pour l’ensemble du système. Entrent pour ce faire en compte divers critères à l’importance relative variable. La liste qui suit passe en revue les critères les fréquemment utilisées.

  • Utilisation du processeur Pourcentage de temps pendant lequel un processeur exécute un processus. L’importance de ce critère varie généralement en fonction du degré de partage du système.

  • Rendement (throughput) Nombre de processus exécutés par unité de temps.

  • Temps de service (turnaround time) est le temps qui s’écoule entre le moment où un processus devient prêt à s’exécuter et le moment où il finit de s’exécuter (temps d’accès mémoire + temps d’attente dans la file des processus éligibles + temps d’exécution dans l’unité centrale + temps d’attente + temps d’exécution dans les périphériques d’entrée/sortie). On utilise en général un temps moyen de service calculé pour tous les processus mis en jeu pendant une période d’observation donnée. Il est inversement proportionnel au rendement.

  • Temps de réponse (response time) Temps qui s’écoule entre la soumission d’une requête et la première réponse obtenue. On utilise en général un temps moyen de réponse calculé pour tous les processus mis en jeu pendant une période d’observation donnée. Le temps de réponse est utile dans l’évaluation des systèmes de type transactionnel où il est intéressant de mesurer le temps qui s’écoule entre le moment où l’utilisateur formule une requête, et celui où la réponse lui parvient.

  • Equité Degré auquel tous les processus reçoivent une chance égale de s’exécuter.

  • Priorités Attribue un traitement préférentiel aux processus dont le niveau de priorité est supérieur.

  • Temps d’attente (waiting time) temps passé dans la file des processus éligibles. On utilise en général un temps moyen d’attente calculé pour tous les processus mis en jeu pendant une période d’observation donnée. Mesurer la performance par le temps de rotation présente un inconvénient : Le temps de production du processus accroît le temps de service ; Le temps d’attente représente donc une mesure plus précise de la performance.

Notez que ces critères étant plus ou moins mutuellement exclusifs, les comparaisons des différents algorithmes se fait donc non sur toutes mais sur une sélection de ces mesures.

Concepts et terminologie

Versions de Windows

Bien que ce livre se concentre principalement sur les dernières versions de Windows (à tout le moins celles postérieures à Windows Vista, lequel amorce la plupart des processus de transition vers ce que l’on connaît aujourd’hui), il est utile de revenir sur l’histoire des produits de la famille Microsoft Windows. Bon nombre d’aspects des systèmes de cette gamme ont en effet un héritage commun, à savoir Windows NT (NT pour New technology), conçu et développé par Microsoft à la fin des années 80, et dont on peut jusque dans les versions les plus récentes de Windows, percevoir l’écho.

Chaque version de Microsoft Windows est connue par le biais d’un nom, d’un numéro de version et d’un nom de code. Le nom de produit fait office de désignation générique (et surtout commode) diffusée auprès du grand public afin d’assurer au logiciel (voire à toute une gamme) une identité unique sur les marchés. Quelques exemples à cet égard : XP, Vista, 7, 10. Le numéro de version se rapporte à une numérotation interne mettant en évidence la version du noyau animant le système d’exploitation. Généralement, une nouvelle famille de système s’ouvre avec une évolution majeure du noyau, laquelle constitue sous cette perspective une réponse tangible aux besoins actuels du secteur. Enfin, un nom de code accompagne chaque produit avant la publication officielle, le temps pour Microsoft d’en annoncer un définitif.

Table 1. Versions de Windows
Nom de produit Numéro de version interne Nom de code Année de sortie

Windows NT 3.1

3.1

n/a

Juillet 1993

Windows NT 3.5

3.5

Daytona

Septembre 1994

Windows NT 3.51

3.51

n/a

Mai 1995

Windows NT 4.0

4.0

SUR (Shell Update Release), Cairo

Juillet 1996

Windows 2000

5.0

n/a

Décembre 1999

Windows XP

5.1

Whistler

Aout 2001

Windows Server 2003

5.2

Whistler Server

Mars 2003

Windows Vista

6.0 (Build 6000)

Longhorn

Janvier 2007

Windows Server 2008

6.0 (Build 6001)

Longhorn Server

Mars 2008

Windows 7

6.1

Blackcomb, Vienna

Octobre 2009

Windows Server 2008 R2

6.1

-

Octobre 2009

Windows 8

6.2

Jupiter

Janvier 2012

Windows Server 2012

6.2

Windows Server 8

Aout 2012

Windows 8.1

6.3

Blue

Octobre 2013

Windows Server 2012 R2

6.3

Windows Server 8

Octobre 2013

Windows 10

10.0

Threshold, Redstone

Juillet 2015

Windows Server 2016

10.0

Redstone Server

Septembre 2016

Examen de la version courante du système d’exploitation

Windows intègre nativement plusieurs applications et commandes par l’intermédiaire desquelles utilisateurs et administrateurs peuvent facilement se rendre compte de la version du système d’exploitation utilisé sur la station de travail. (Pour une vue programmatique du sujet, voir le chapitre Processus et threads.)

Si vous ne savez pas précisément quelle version de Microsoft Windows votre machine exécute, depuis une invite de commande ou le contrôle Exécuter, saisissez la commande winver puis validez. Une fenêtre devrait alors apparaître, affichant la version du système, par exemple 7, 8 ou 10, ainsi que d’autres détails.

Pour voir les détails de version, procédez comme suit : (1) cliquez sur Démarrer puis cliquez sur Paramètres, (2) dans la fenêtre des paramètres, cliquez sur Système, (3) à partir des onglets qui se trouvent sur la gauche, cliquez sur Informations système. Vous verrez à ce moment quelle version de Windows vous utilisez, votre numéro de version (par exemple 1511) et le type de système (32-bit ou 64-bit).

La commande ver constitue une méthode parmi les plus pratiques dans le but d’examiner les informations de version de Windows. Elle ne requiert aucun argument et produit un et un seul type de résultat, ce qui se prête particulièrement bien à un usage dans des scripts d’administration. Les précisions apportées par ladite commande incluent le nom, les numéros majeurs et mineur, et le numéro de fabrication (build) du système d’exploitation. Pour voir concrètement ces données, saisissez simplement ver depuis une fenêtre d’invite de commandes de commande. Vous devriez à ce moment voir quelque chose de similaire à ce qui suit.

Par comparaison avec les autres utilitaires que nous avons vus jusqu’ici, c’est sans doute WMI qui permet d’afficher le plus d’informations sur le système. Consultez dans ce cas les propriétés Caption, CSDVersion, OSArchitecture, et Version de la classe OS.

Une grande majorité des informations en lien avec la version de Windows employée sur le poste sont regroupés sous la clé HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion
    SystemRoot    REG_SZ    C:\WINDOWS
    BuildBranch    REG_SZ    th2_release
    CurrentBuild    REG_SZ    10586
    CurrentMajorVersionNumber    REG_DWORD    0xa
    CurrentMinorVersionNumber    REG_DWORD    0x0
    CurrentType    REG_SZ    Multiprocessor Free
    CurrentVersion    REG_SZ    6.3
    EditionID    REG_SZ    Core
    InstallationType    REG_SZ    Client
    InstallDate    REG_DWORD    0x566e53eb
    ProductName    REG_SZ    Windows 10 Home
    ReleaseId    REG_SZ    1511
    SoftwareType    REG_SZ    System
    UBR    REG_DWORD    0x24d
    PathName    REG_SZ    C:\WINDOWS
    Customizations    REG_SZ    ModernApps
    BuildLabEx    REG_SZ    10586.589.amd64fre.th2_release.160906-1759
    BuildLab    REG_SZ    10586.th2_release.160906-1759
    ProductId    REG_SZ    00326-10000-00000-AA115
    CurrentBuildNumber    REG_SZ    10586
    BuildGUID    REG_SZ    ffffffff-ffff-ffff-ffff-ffffffffffff
    RegisteredOrganization    REG_SZ    Hewlett-Packard Company
    RegisteredOwner    REG_SZ    arnaud
    InstallTime    REG_QWORD    0x1d13630855020eb
    .
    .
    .

La liste qui suit donne la signification des valeurs les plus importantes de cette clé.

Table 2. Valeurs sous CurrentVersion

Valeur

Description

BuildLab

Numéro de version complet de Windows

CurrentBuildNumber

Numéro de version de Windows

CurrentMajorVersionNumber

Numéro de version primaire

CurrentMinorVersionNumber

Numéro de version secondaire

CurrentVersion

Numéro de version du noyau

DigitalProductId

Numéro d’identification de Windows

InstallDate

Date à laquelle Windows a été installé (donnée en temps Unix, soit le nombre de secondes écoulées depuis le 1er janvier 1970).

InstallTime

Date à laquelle Windows a été installé (donnée, au contraire de la valeur InstallDate, en temps Windows).

PathName

Répertoire d’installation du système.

ProductId

ID de produit

ProductName

Nom du système d’exploitation tel qu’il a été distribué de façon commerciale

RegisteredOwner

Nom du propriétaire enregistré de la licence Windows, tel que spécifié lors du processus d’installation du système.

ReleaseId ID

ID de publication, Cette valeur, visible seulement à partir de Windows 10 et à quoi semble correspondre une date de sortie prévue, est généralement un code à 4 chiffres, dont les deux premiers donnent une année et les deux autres un mois.

Fonctions, services et routines

Comme pour certains termes du langage ordinaire, quelques-uns propres à l’écosystème Windows voient leur signification varier en fonction du contexte. Ainsi, hors d’un cadre précisément situé, un service peut désigner potentiellement une routine incorporée du système d’exploitation, un pilote de périphériques, ou un processus serveur. Face à ce problème, et afin que nous nous entendions dès le départ sur leur sens, la liste suivante chercher à préciser la définition de plusieurs termes utilisés dans l’ouvrage. (Notez que ces éclaircissements sont suggérés ici uniquement afin de parvenir à une bonne entente sur les concepts communs. S’ils ont tous un caractère simple et pratique, aucun ne devrait être considéré comme universel.)

  • Fonctions d’API Windows Sous-routines appellables depuis le mode utilisateur et incorporées au sein de diverses bibliothèques de liens dynamiques (DLL). Ces fonctions font partie intégrante du système d’exploitation Windows et permettent d’effectuer des tâches lorsqu’il s’avère difficile d’écrire des procédures équivalentes. Par exemple, Windows propose les fonctions nommées CreateProcess et ExitProcess, affiliées au module Kernel32.dll et avec lesquelles, respectivement, donner naissance et mettre fin à un processus. La plupart des fonctions de l’API Windows bénéficient d’une documentation complète incluant les objectifs, les paramètres d’appel et quelques remarques générales d’utilisation.

  • Services système natifs Sous-routines chargées de faire la liaison entre des fonctions du mode utilisateur et d’autres fonctions du mode noyau. L’invocation de telles routines tient à la fois de l’appel de procédure et du traitement d’interruption, dans la mesure où cela se traduit par un changement du mode d’exécution du processeur (bascule du mode mode utilisateur vers le mode noyau, et inversement à l’issue de l’exécution), et par un branchement à l’adresse d’une fonction implémentée au niveau de l’espace système. Ainsi, NtCreateProcess est le service système que la fonction Windows CreateProcess appelle pour créer un processus. Ces pièces de logiciel ayant un comportement susceptible d’être modifié à chaque itération de Windows, il est recommandé aux concepteurs de logiciels d’éviter leur utilisation, même si de récents efforts à ce niveau tendent à montrer la volonté de Microsoft de rendre publique la documentation idoine.

  • Fonctions (ou routines, ou interfaces) noyau Sous-routines appelables depuis le mode noyau qui mettent en oeuvre l’interface de programmation pour pilotes de périphériques et autres composants bas niveau. Par exemple, IoCreateDevice est la routine que les pilotes de périphérique utilisent pour créer ou ouvrir un objet périphérique représentant un équipement physique ou logique, ExAllocatePoolWithTag celle qu’ils appellent pour allouer de la mémoire à partir des tas système de Windows.

  • Routines de support noyau Sous-routines endogènes internes au système d’exploitation. Par exemple, KeReadStateMutant, via laquelle déterminer l’état (signalé ou non) d’un objet mutant (nom interne du mutex, à quelques variations techniques près), ou KeSetIdealProcessorThread, que le système (et normalement lui seul) emploie pour définir le processeur idéal d’un thread.

  • Services Windows Processus démarrés par le Gestionnaire de contrôle des services (SCM, Service Control Manager) effectuant diverses tâches pour le compte des utilisateurs de l’ordinateur ou du domaine. (La base de Registre définit les pilotes de périphérique Windows comme étant des services, ce que nous ne ferons pas dans cet ouvrage.) De telles applications fonctionnent en arrière-plan et n’interagissent généralement pas avec l’utilisateur. Les exemples de services Windows incluent le Planificateur de tâches, le gestionnaire automatique de réseaux sans fil, etc.

  • DLL (Dynamic Link Library) Collection de fonctions liées entre elles sous la forme d’un fichier binaire pouvant être chargé dynamiquement, ledit fichier étant relié à l’application lorsque celle-ci en a besoin. Les composants et applications Windows en mode utilisateur font un usage intensif des DLL, d’une part pour les interfaces de programmation que ces bibliothèques mettent en oeuvre, mais également pour de nombreuses extensions : boîtes de dialogue, widgets, polices de caractères, etc. Citons, par exemple, Kernel32.dll, qui héberge une bonne partie des fonctionnalités mises à disposition par l’API Windows, ou User32.dll, qui contient des fonctions associées à l’interface utilisateur. L’avantage des DLL par rapport aux bibliothèques statiques, dont le code est incorporé à chaque programme, est que les applications peuvent se partager les DLL, Windows faisant en sorte que le code d’une DLL ne soit chargé qu’une seule fois en mémoire même s’il est référencé par plusieurs applications.

Documentation

C’est en qualité de société éditrice que Microsoft s’emploie à documenter la plupart des services embarqués par son système d’exploitation. À ce seul niveau, la principale différence entre les fonctions publiques et celles privées est palpable avec l’engagement de Microsoft à fournir un écosystème dont les conditions d’utilisation sont pérennes, où la présence de documentation d’une fonction garantit à cette dernière une existence dans les versions futures de Windows. Cette discipline d’ingénierie, asseyant la confiance des développeurs en la portabilité de ce qu’ils conçoivent, est sans doute l’une des raisons du succès de Windows auprès des informaticiens créateurs de logiciels.

Documentation logicielle

La documentation logicielle est un texte écrit dont le but est d’expliquer comment le logiciel fonctionne, et/ou comment on doit l’employer. Si le terme peut avoir des significations différentes pour des personnes de différents profils, nous l’utilisons dans cet ouvrage dans le contexte le plus répandu. Par conséquent, nous disons d’une fonction qu’elle est documentée dans la mesure où un support adéquat est disponible auprès la société éditrice, ici en l’occurrence Microsoft. Toute autre source est disqualifiée. De plus, Windows étant un logiciel à source fermée, les détails d’implémentation ne sont, en principe, pas visible.

Microsoft rend visible la documentation des structures de données et des interfaces Windows sur le site web Microsoft Developer Network (MSDN). Il est vivement recommandé de s’en tenir au contenu de ce média, dont l’ensemble des éléments décrits bénéficie d’un support à long terme. Les API non documentées peuvent disparaître, changer de nom, voire de comportement, y compris dans les évolutions mineures de la même version du système (service pack). Hormis de rares situations, vous ne devriez considérer ces fonctions autrement que pour un usage pédagogique. Pour autant, cela ne veut pas dire qu’elles ne devraient pas susciter l’intérêt, du fait notamment, pour la plupart, de contenir les détails d’implémentation internes de Windows. Ce livre tend même à prouver que la connaissance de certains de ces détails est souvent important lors des phases de réalisation (programmation), d’analyse (retro ingénierie), ou de résolution des dysfonctionnement (débogage) de vos propres programmes.

En plus d’héberger les informations de l’API Windows, le site MSDN contient également un nombre important d’écrits sur les technologies du système d’exploitation. Il accueille par exemple une catégorie spéciale de documents, appelée Base de connaissances (KB, Knowledge Base), laquelle regroupe des articles publiés par l’équipe de support client Microsoft pour proposer des solutions de contournement à des problèmes connus.

Processus, threads et autres unités fonctionnelles

Les unités de base dans les systèmes à temps partagé modernes sont les programmes, les processus, les threads et les fibres. A cela s’ajoute, mais concerne Windows seulement, la notion de job.

Au plus haut niveau d’abstraction, un processus est constitué d’un programme en exécution ainsi que de son contexte. Chaque processus est de la sorte plus que le code du programme dont il résulte, et contient également l’activité courante, représentée par le contenu des registres du processeur, les données, et l’environnement tels que piles, pointeur de pile, valeur des variables internes, emplacement de lecture dans un fichier, etc.

Un processus est concrètement une zone mémoire contenant des ressources, parmi lesquelles :

  • Un espace d’adressage virtuel privé, qui est un ensemble d’adresses mémoire virtuelles utilisables par le processus

  • Un programme exécutable, hébergeant le code machine exécutable et le jeu de données nécessaires à ces opérations, qui est mappé dans l’espace d’adressage virtuel du processus

  • Une liste de handles ouverts sur différentes ressources système, telles que fichiers, ports de communication, primitives de synchronisation, etc.

  • Un contexte de sécurité, qui identifie l’utilisateur, les groupes de sécurité et les privilèges associés au processus

  • Des informations d’identification, qui permettent d’identifier sans ambiguïté un processus sur le système, et de le désigner par son nom ou au moyen d’un numéro unique (PID, process identifier)

  • Au moins un thread

Sous un jour plus large que celui structurel, un processus est une instance d’un programme en cours d’exécution. Tout système d’exploitation moderne étant multitâche, capable à ce titre d’entrelacer l’exécution de plusieurs processus en même temps (et surtout de le faire de façon harmonieuse), il est possible d’exécuter un nombre virtuellement infini de processus sur un même processeur.

Un processus peut créer un ou plusieurs processus qui, à leur tour, peuvent créer d’autre processus, le tout donnant naissance à structure arborescente. À l’exception, du reste particulièrement notable, du premier, initié par le système d’exploitation, tous les processus descendent directement ou indirectement d’un autre. Par analogie aux liens intrafamiliaux humains, on utilise quand il est besoin de les distinguer les notions de processus parent (ou père) et de processus enfant (ou fils).

Plusieurs processus peuvent exécuter parallèlement le même programme - ce que se traduit sous la forme d’un corollaire par le fait qu’un même programme peut être sollicité à maintes reprises en donnant lieu chaque fois à un processus différent.

Un programme est une suite d’instructions enregistrées au niveau de la mémoire auxiliaire, usuellement un disque dur. On désigne par ce biais généralement le fichier en langage machine obtenu après compilation (parlant auquel cas aussi de programme exécutable ou de binaire), mais aussi potentiellement le fichier source écrit dans un langage donné, par exemple un programme C, C++, Java. Si programmes et processus se ressemblent en surface, ils sont fondamentalement différents. Un programme est une entité statique qui décrit un traitement (une suite d’instructions), alors qu’un processus est une entité dynamique qui réalise un traitement. Un programme existe donc en dehors de toute utilisation. A l’inverse, un processus doit son existence à un programme, dont il est le direct représentant de la prise en charge par le système d’exploitation.

Une application est constituée d’un ou plusieurs processus coopérants. Typiquement, un éditeur de texte (Bloc-notes par exemple), un navigateur web (Edge ou Firefox), un lecteur multimédia (VLC), un jeu vidéo (Dark Souls), sont des applications. Vous pouvez voir toutes les applications et tous les processus en cours par le biais du gestionnaire des taches (task manager). Il est courant d’avoir une vingtaine de processus en même temps, même si vous avez ouvert un petit nombre d’applications.

Un processus possède un ou plusieurs unités d’exécution appelée(s) threads. Un thread est l’entité de base dont Windows coordonne l’exécution. Au plus haut niveau d’abstraction, un thread est similaire à un processus dans la mesure où tout deux représentent l’exécution d’un ensemble d’instructions du langage machine d’un processeur. Toutefois, là où chaque processus possède sa propre mémoire virtuelle, les threads d’un même processus se partagent l’espace d’adressage virtuel du processus auxquels ils appartiennent.

Sous un jour essentiellement pratique, la notion de thread n’a aucune signification matérielle ou physique au niveau du processeur, mais se concrétise par un ensemble de données dont il se dégage principalement deux grands thèmes : le contexte d’exécution et l’état. Un contexte d’exécution se compose d’un sous-ensemble des registres du processeur dont la sauvegarde est nécessaire permettre la suspension et la reprise ultérieure d’un thread donnée. À chaque thread est également associé un état. Les différents états possibles, de même que leur signification respective, sont propres à chaque système d’exploitation, mais incluent généralement les options Prêt pour l’exécution (le thread pourrait occuper le processeur si un autre ne le faisait pas déjà), En cours d’exécution (le thread s’exécute), Bloqué (le thread attend sur la disponibilité d’une ressource matérielle ou logique) et Terminé (le thread a terminé son exécution et ne devrait par tarder à être démantelé par le système).

Un thread ne peut appartenir qu’à un processus. Quand un processus commence, le système d’exploitation lui associe automatiquement un thread, appelé auquel cas thread principal ou thread primaire (main thread ou primary thread en anglais). Dans un processus Windows, un thread peut créer d’autres threads. Il n’y a pas de valeur maximale pour le nombre de threads par processus, une limitation naturelle s’établissant toutefois via la dépendance collective des threads via à vis des ressources mémoire disponibles.

Windows étend l’approche préemptive à base de priorités régissant l’ordonnancement des threads en y ajoutant la notion de fibre. Les fibres permettent à une application d’effectuer un traitement micro structurel de ses propres flux logistiques (multitâche coopératif). Dans ce scénario, chaque fibre doit pour commencer son exécution être manuellement sélectionnée, et pour se terminer passer le relais à une autre.

Un job permet à des groupes de processus d’être gérés et manipulées comme une entité unique. Les attributs et opérations typiques qu’un objet job peut effectuer ont des répercussions sur l’ensemble des processus associés au job. Par certains aspects, une telle approche vise à compenser l’absence dans les systèmes Windows d’une arborescence structurée de processus.

Gestionnaire des tâches

L’utilitaire prédéfini Gestionnaire des tâches (Task Manager) affiche des informations détaillées concernant les programmes, les processus et les services en cours d’exécution sur l’ordinateur. Il fournit des informations sur l’état du système en temps réel et couvre ainsi plusieurs aspects de sa performance.

Il peut également être utilisé pour définir la priorité des processus, de les arrêter, de basculer d’un programme à un autre, d’accéder aux fonctions de démarrage, de mise en veille et d’extinction du système, et de contrôler les informations de performances.

L’application Gestionnaire des tâches occupe les systèmes d’exploitation développés par Microsoft depuis Windows NT 4.0. Les versions précédentes incluaient une application nommée Task List dotée de beaucoup moins de fonctionnalités.

Vous pouvez démarrer le gestionnaire de plusieurs façons : (1) Appuyez sur le CTRL+ALT+SUPPR et cliquez sur le bouton Gestionnaire des tâches, (2) Ouvrez une fenêtre Executer (Windows+R) et tapez le nom du module sous-jacent au gestionnaire, à savoir taskmgr.exe. La vue initiale du gestionnaire montre seulement les processus auxquels sont associées des fenêtres visibles de premier niveau. Pour voir l’ensemble des processus, cliquez sur le bouton Plus de détails (More details). Dans ce mode de visualisation sont présentés les noms génériques des processus (par exemple, « Microsoft Word », ou « Hôte de la fenêtre de la console »), groupés en catégories : applications, processus d’arrière-plan et processus du système d’exploitation. Pour afficher les noms des images dont sont une instance ces processus, cliquez sur l’onglet Details. Pour afficher des informations supplémentaires à celles déjà présentes, faites un clic droit sur le bandeau supérieur, cliquez sur l’entrée Sélectionner les colonnes du menu contextuel qui vient d’apparaitre, puis sélectionnez les colonnes à afficher.

Le Gestionnaire des tâches se présente sous la forme d’une boite de dialogue à plusieurs onglets, chacun dévolu à une thématique.

  • L’onglet Processus affiche une vue simplifiée des processus en cours d’exécution, triés par catégories : Applications (qui disposent d’une fenêtre active), Processus en arrière-plan (applications et services), Processus Windows (processus critiques et services hébergés par SvcHost).

  • L’onglet performance offre une vue d’ensemble des données d’utilisation et de diagnostic se rapportant à divers équipements et fonctionnalités de l’ordinateur, par exemple l’unité centrale, les disques ou le réseau. Les informations montrées à ce niveau de l’interface peuvent se montrer extrêmement utile dès qu’il s’agit de détecter des anomalies, notamment une utilisation des ressources systèmes anormale, par exemple un nombre inhabituellement important d’E/S disque.

  • L’onglet Détails liste les processus en cours d’exécution ainsi qu’un certain nombre de compteurs relatifs à la consommation de ressources.

  • L’onglet Services liste les services présents sur le système ainsi que leur état démarré ou arrêté. Le lien Ouvrir les services en bas de la fenêtre procure un moyen d’accès rapide à l’outil d’administration Services, qui permet entre autres choses de modifier la configuration de démarrage des services.

  • L’onglet Démarrage liste les applications démarrés automatiquement lors de la procédure d’amorçage de Windows.

Par défaut, le Gestionnaire des tâches met à jour ses données toutes les deux secondes. Pour augmenter la fréquence à deux fois par seconde, choisissez Affichage, Fréquence d’actualisation et changez la fréquence de Normale à Haute. Pour réduire la fréquence de mise à jour à une fois toutes les quatre secondes, optez pour le paramètre Basse.

Registre

Il est à peu près entendu si vous lisez ce livre que vous ayez déjà entendu parler, voire même mis les mains sous le capot, du Registre, lequel tient lieu de dépôt central pour moult paramètres relatifs à Windows et aux logiciels de l’ordinateur, incluant les données d’amorçage et de configuration du système et les préférences des utilisateurs et de chacune de leurs applications. En lien avec le fonctionnement global de la machine, le Registre est de ce fait un incontournable pour qui s’intéresse aux mécanismes internes de Windows.

Parmi la myriade d’informations stockées dans le registre, un certain nombre concerne l’état courant du système (par exemple les pilotes qui sont chargés, les ressources qu’ils utilisent, etc.) et quelques-unes font passerelle vers les compteurs de performance de Windows. (S’ils ne pas directement directement intégrés dans le Registre, on accède à ces compteurs via des fonctions de registre.)

Apparue avec la version 3 de Windows, le registre se présente alors comme une méthode alternative aux fichiers INI utilisés dans les systèmes prédécesseurs pour l’enregistrement des paramètres de configuration (voir encadré plus loin). Sous cette forme, par ailleurs rudimentaire, le registre sert exclusivement à associer une extension de fichier à un logiciel permettant l’édition des données impliquées par ce format. En 1993, avec la première version de NT, le registre est étendu de sorte à inclure un ensemble de clés hiérarchiques et de valeurs. Windows 95, en 1995, est la première version de Windows orientée complètement autour de ce dispositif, de même que toutes les versions qui suivent, incluant Windows 7, 8 et 10.

Le registre est organisé selon une structure hiérarchique de sous-arborescences contenant des clés, des sous-clés et des entrées. Un ensemble de clés, de sous-clés et de valeurs qui figure en haut de la hiérarchie du Registre est appelé une ruche. Il existe plusieurs ruches distinctes pour les informations relatives à l’ordinateur local, les profils d’utilisateurs, l’installation des logiciels et la sécurité. Les informations de la ruche système étant nécessaires au démarrage du système, le gestionnaire de registre, ou plus précisément le gestionnaire de configuration, est implémenté comme un composant de l’exécutif.

Dans la plupart des scénarios, administrateurs et utilisateurs interagissent avec le registre par le biais d’applications intermédiaires, par exemple l’éditeur graphique du Registre fourni avec Windows (regedit.exe) ou l’outil en ligne de commande reg.exe. De plus, quelques utilitaires d’administration standard permettent de voir ou de modifier bon nombre des paramètres de configuration stockés dans le registre. Dans de nombreux cas, les changements apportés par l’utilisateur ou l’administrateur au registre se font en réalité au travers d’un programme d’installation (application, correctifs), modifiant le registre de façon transparente, et n’autorisant pas une interaction directe avec des clés et des valeurs particulières.

Comme nous l’avons déjà évoqué, le registre joue un rôle très important dans le fonctionnement du système d’exploitation, et contient à ce titre une kyrielle d’informations en ce qui en concerne le comportement, les performances et les données internes. (Notez dès à présent que si vous décidez de modifier des paramètres du registre, faites-le avec précaution, une manipulation maladroite pouvant dégrader les performances ou, pire encore, empêcher le démarrage du système.) Tout au long de ce livre, vous trouverez des références à diverses clés du registre relatives à tel ou tel composant.

Pour plus de détails sur le registre et sa structure interne, reportez-vous au chapitre Mécanismes de gestion.

Notation hongroise

La notation hongroise est une norme d’écriture utilisée en programmation informatique afin de donner un éclairage complémentaire sur les variables et les fonctions d’un programme. Elle renvoie de la sorte au premier lieu, comme par ailleurs n’importe quelle autre convention de nommage, à la lisibilité du code source, et a fortiori sa compréhension ainsi que sa maintenance. Ce standard est notamment utilisé par Microsoft pour les API Windows, ainsi que les dérivés programmatiques qui s’ensuivent.

Généralités

L’idée fondatrice sur laquelle repose la notation hongroise est de désigner toute donnée (variables, constantes, fonctions, procédures, etc.) d’après un schéma qui en accentue la nature ou la fonction. (Ainsi que vous le verrez plus loin, la distinction entre les deux n’est pas toujours facile à établir avec certitude.) Elle instaure à cet égard un corpus méthodologique relativement complet, animé par un ensemble de raisonnements, de catégorisations, de classifications, bref de mesures, chargées de régir la mise en forme des noms dans un programme, avec comme ambition centrale d’en améliorer l’ancrage interprétatif.

Une des caractéristiques marquantes, sinon la plus importante, de la notation hongroise est d’incorporer de l’information à même les identifiants logiciels (noms des éléments du programme). En pratique, cette approche s’exprime essentiellement par le biais de divers préfixes, dont l’ensemble se veut être une réponse au besoin d’un niveau de compréhension plus détaillé en ce qui les concerne les données en jeu et les procédés techniques mis en oeuvre.

On distingue en principe deux types de notation hongroise, chacun orienté par un axe de compréhension bien défini : la notation hongroise Apps, d’un côté, vise à mettre en avant l’usage des éléments qu’elle englobe ; la notation hongroise Systems, d’un autre côté, a pour but d’en souligner le type. Notez que si ces noms semblent cerner plusieurs choses distinctes, la notation hongroise Apps est essentiellement un calque des intentions originelles de l’auteur, l’étiquette étant ici affaire de conventions. Pour complexifier encore davantage la situation, un discours sur la notation hongroise (sans mention du contexte ou de la forme visée) peut faire référence à la notation Apps, à la notation Systems, ou aux deux.

Sans être le seul standard du genre, et sans non plus être exempte de défauts, la notation hongroise est sans doute l’une de celles que vous rencontrerez le plus souvent lors de la lecture de programmes conçus pour Windows.

Nommage des identifiants

Une question à laquelle est confronté tout concepteur de logiciel en face de la nécessité d’un nouvel identifiant porte sur le choix d’un nom pertinent et utile. Dans l’idéal, trouver des intitulés reflétant la signification des contenus qu’ils enveloppent est souvent recommandé, et d’ordinaire une bonne habitude à perpétuer. Ce point entraine en général à considérer les facteurs suivants :

  • La valeur mnémonique du nom, de sorte que la personne l’ayant choisi puisse s’en souvenir avec aisance.

  • Le potentiel suggestif, de manière à ce que d’autres puissent tirer de la seule lecture de ce nom des observations marquantes, sinon des informations intéressantes.

  • La cohérence, de façon à ce que ce que les noms ayant des caractéristiques communes puissent se ressembler les uns entre les autres.

  • La rapidité de décision, de sorte à limiter le temps de réflexion induit pour la mise en forme d’un intitulé, ainsi que celui nécessaire pour la saisie au clavier.

Les multiples conventions de nommage existantes doivent satisfaire peu ou prou les quelques impératifs que nous venons d’énoncer. Dans l’ensemble, harmoniser un intitulé vis-à-vis de telle ou telle nomenclature peut être une tâche délicate, voire fastidieuse. Le maintien de la cohérence peut être particulièrement difficile.

Histoire

Conçue pour être indépendante du langage de programmation utilisé, la notation hongroise a trouvé sa première utilisation à grande échelle dans BCPL (Basic Combined Programming Language). N’intégrant qu’un seul type de données - le type word, dont la taille correspond à celle du mot machine gérée à l’échelle du processeur, ce langage ne fournit par conséquent aucun indice quant à l’interprétation des valeurs constitutives d’un programme. La notation hongroise vise à remédier à cette lacune, cela en fournissant aux concepteurs de logiciels une connaissance explicite, instinctive au premier abord, du domaine d’utilisation prévu pour chaque variable.

La notation hongroise a été pensée par Charles Simonyi, un informaticien hongrois émigré aux États-Unis en 1968. Après ses études à l’Université de Berkeley, il est embauché au Xerox PARC à Palo Alto en Californie. Recruté par Microsoft en 1981, il crée et prend la direction d’un groupe de travail dont la première réalisation serait un logiciel de traitement de texte WYSIWYG. (Ledit logiciel, sorti en 1983 sous le nom de Microsoft Word, deviendra une des mannes financières les plus importantes pour la firme de Redmond.) Se basant sur ses propres expériences, qui le font mettre les fautes de typage parmi les premières sources de dysfonctionnement des programmes, Simonyi jette les bases d’une convention qui promeut l’emploi systématique de noms de variables préfixés de leur type. Il envisage par ce biais de diminuer les erreurs sur ces variables dues à des manipulations impropres. Son poste chez Microsoft lui a permis de tester ce modèle, l’imposant comme standard de travail pour son équipe.

La désignation accompagnant la méthode hongroise est une référence directe au pays d’origine de Simonyi, né à Budapest, capitale et plus grande ville de la Hongrie. Sur un autre plan plus factuel, la formation d’associations conformes à la notation hongroise emprunte pour une grande part à la grammaire descriptive classique du hongrois, qui fait une utilisation intensive de suffixes pour conférer à partir d’un alphabet sémantique élémentaire toutes sortes de sens.

Après avoir été popularisée au sein de la division Application de Microsoft (d’où l’appellation Apps dont elle sera affublée par la suite), la notation hongroise atteint les équipes de développement à l’origine de Windows, futur système d’exploitation phare de la firme. Les concepteurs en reprennent les principes fondateurs, mais soulignent que certaines pratiques liées à la méthode hongroise tendent à dévoiler plus facilement des informations sur la partie logique d’une variable (ce à quoi elle sert) que sur ses aspects physiques (les valeurs qu’elle peut stocker, et surtout sous quelle forme). Ils imaginent de ce fait un dialecte de la notation hongroise, étiquetée Systems, plus proche de la machine et des traitements et des opérations qui s’y déroulent.

En guise d’anecdote, et dans un registre plus décalé, il faut aussi mentionner que pour quantité de personnes, la notation hongroise est remarquable avant tout par le fait de séries plus ou moins longues et de complexité variable de consonnes, qui sont en tout état de cause imprononçables sorties de quelques contextes linguistiques particuliers. Notez encore, toujours au registre du détail, que le hongrois fait partie de la famille des langues ouraliennes (du nom de l’Oural, leur lieu supposé d’origine), et contrairement aux langues slaves, plutôt riche en voyelles.

Notation hongroise Apps

Dévolue surtout à rendre compte de cas d’utilisation, la notation hongroise Apps invente un plan de nommage tourné vers la sémantique, orienté par l’utilité fonctionnelle individuelle des données de programme. Les symboles envisagés de cette manière le sont sur la base d’un ensemble de préfixes commandé par la force de liens logiques ou formels, plutôt que par la forme ou par la nature. Ainsi, à titre d’exemple, le préfixe i peut éventuellement correspondre à un indice, cb à une taille en octets (count of bytes), et les préfixes rw et col faire référence, respectivement, à une valeur de ligne et une valeur de colonne. Quelques noms élaborés à partir de ce principe : lName, pour une variable hébergeant un entier long (long integer); usName, pour une variable appelée à contenir une chaine de caractères dont on peut avoir un doute sur la sécurité (unsafe string), bName pour indiquer un type booléen (bool), et ainsi de suite.

L’orientation principale sur laquelle la notation hongroise Apps assoie ses modèles est de nature à donner une idée des aboutissants potentiels d’une variable ou d’une fonction, sans chercher à en révéler les tenants exacts. Un développeur attentif au versant Apps de la convention optera par conséquent de préférence pour des symboles qui correspondent à cette optique, par exemple strName à la place de szName, ou cName au lieu de dwName. La forme choisie dans le premier cas parvient à révéler l’existence d’une chaine de caractères, sans cependant rien dire de l’implémentation sous-jacente. Lors du second cas de figure, la symbolique préférée l’est du fait d’indiquer que la variable agit en tant que compteur, qu’il s’agisse d’un entier numérique étant un détail de relativement peu d’importance. En définitive, cet accent mis sur la sémantique permet de véhiculer toutes sortes d’informations utiles.

L’intérêt évident de la notation hongroise Apps est d’aller au-devant de l’utilisation accidentelle d’une donnée dans le mauvais contexte. Il est par exemple presque certain, sans même connaître les détails afférents, que l’expression rwXxx + cbXxx, ajoutant un numéro de ligne à une taille, est un défaut de conception dans le code.

Un constat qui ne peut manquer d’être établi, et d’interpeller le regard moderne, en ce qui concerne les constructions avancées dans la notation hongroise Apps est que toutes ne sont pas de nature sémantique. Certains préfixes semblent en effet avoir trait à la qualité intrinsèque d’une donnée brute, tels que sz pour ce qui est des chaines de caractères, ou b pour une valeur au niveau de l’octet. Sur la question du bien-fondé de ces éléments, il faut se rappeler que les langages de programmation sur lesquelles ils ont pris corps ne disposaient pas à l’époque de systèmes de types. Les concepts que les langages modernes, et par extension les concepteurs de logiciels tiennent pour acquis aujourd’hui n’existaient pas.

La notation hongroise Apps est nommée de la sorte en référence à l’enracinement de ce standard au sein de la division Applications de Microsoft. Son emploi à guidé des logiciels comme Word, Excel, et bien d’autres.

Notation hongroise Systems

Mettant en exergue des informations techniques plutôt que des pistes d’utilisation, la notation hongroise Systems consiste à insuffler à même le nom d’une donnée le type avec lequel elle est en interaction, celui dont elle tient s’il s’agit d’une variable, celui qu’elle retourne dans le cas d’une fonction.

La notation hongroise Systems tire son nom des conditions dans lesquelles elle a été pensée.

Raison d’être et avantages

L’avantage premier auquel conduit l’emploi de la notation hongroise est que son déploiement systématique introduit de facto une normalisation au niveau des règles programmatiques. Si l’appréciation de tel ou tel protocole est laissée à la discrétion et au goût de chacun, il est généralement de bon ton, dans un domaine aussi vaste que l’informatique, qui mérite un grand nombre de mises au point et de réflexions sur le sujet, d’appliquer des standards. Sans trop entrer dans les détails à ce stade, la notation hongroise procure les mêmes bénéfices, pour ce qui est de la discipline, que ceux inhérents à tout type de normalisation.

Un second bienfait dont découle l’application de la notation hongroise est une meilleure lisibilité du code source, considérée dans une optique communément partagée comme une des composantes primordiales de la qualité logicielle. En règle générale, les partisans de la notation hongroise apprécient le surcroît d’information immédiate que leur apporte l’ajout d’informations à chaque nom.

Du fait qu’elle les regroupe selon une schématisation bien formée, la notation hongroise permet de mécaniser en grande grande partie la génération des noms. Cela peut se montrer utile, par exemple, lors du recours à des outils de documentation automatique, qui peuvent aider à dépister éliminer d’éventuelles erreurs.

Parmi tous les atouts qui ont participé au succès de la notation hongroise, l’un en particulier mérite une mention spéciale, en ce sens que le standard en question est soutenu par une firme dont le poids, sur la scène mondiale de l’informatique, est considérable. Les pratiques technologiques qu’elle véhicule tendent donc, de ce fait, à se propager plus loin et plus rapidement que toutes autres.

Une fois maitrisée, la notation hongroise permet une lecture très précise du code. Les erreurs de type ou d’utilisation de pointeurs notamment sont beaucoup plus faciles à repérer.

Inconvénients

Si elle présente effectivement plusieurs avantages, la notation hongroise n’en reste pas moins inadaptée dans quelques cas. Une critique couramment soulevée à son encontre est qu’elle impacte négativement la lisibilité du code. Il faut sur ce plan se rappeler que presque tous les préfixes imaginés conformément à la norme le sont à partir d’une ou de plusieurs consonnes. Sans même évoquer de questions esthétiques, cette forme rebute la plupart des concepteurs, qui y voient (au moins pendant leur période d’acclimatation) une perte d’accessibilité globale des éléments concernés.

Au niveau programmatique, plusieurs facteurs contribuent à mettre en doute l’utilité de la notation hongroise. Entre autres :

  • Les langages modernes disposent d’un système de types particulièrement élaboré que les compilateurs font respecter. De ce point de vue, toute forme de codification, y compris la notation hongroise, est considérée comme un obstacle. Ce point est d’autant plus mis dans en relief dans une perspective purement objet, où l’emploi de noms qui puissent transmettre des informations liées au tapage va à l’encontre de l’objectif fixé, à savoir rendre fonctionnellement équivalent toutes sortes de types. Il est sur cet aspect même possible de considérer l’emploi de la notation hongroise comme un biais évaluatif favorisant les opérations réalisables sur un objet - dont il faut pour l’occasion saisir pleinement le type - plutôt que se préoccuper de ce qu’une instance d’objet peut faire.

Les environnements de développement modernes disposent pour la plupart d’une aide intégrée visant à contextualiser l’emploi des variables et des fonctions. Certains offrent en plus de cela un marquage automatique des opérations qui essaient de manipuler des types incompatibles, voire même suggèrent quels sont ceux attendus. Ces auxiliaires tendent à rendre la notation hongroise largement inutile.

  • Souvent, connaitre l’usage potentiel d’une donnée permet d’en déduire - même approximativement - le type. A l’inverse, discerner clairement le type d’une donnée ne permet pas d’en pressentir la fonction.

  • Lorsque les noms choisis pour identifier des objets sont suffisamment descriptifs, l’ajout d’informations de type peut être redondant, voire superflu. Il est par exemple très peu probable que la variable ProcessName fasse référence à autre chose qu’une chaine de caractère.

  • Une tendance générale du développement logiciel est de s’orienter vers des fonctions courtes, dont le rôle peut être facilement identifié. Dans un tel contexte, la déclaration d’une variable ne devrait jamais se situer très loin des opérations qui en font usage.

  • Modifier le type d’une variable signifie, dans un projet pour lequel on a choisi d’appliquer la notation hongroise, la renommer, et ce partout où elle est utilisée. Un

  • Étroitement liée au langage C, la notation hongroise véhicule des usages qui ont du sens d’abord et avant tout pour ce langage. De ce fait, plus important encore et en dépit de la généralité de ses termes, elle n’est pas directement transposable à d’autres langages de programmation.

Sur le fond, peut-être l’aurez déjà remarqué à la lecture de la liste qui précède, bon nombre des arguments avancés contre la notation hongroise ciblent en réalité le volet Systems de celle-ci, la catégorie Apps étant relativement épargnée.

A noter que les pratiques contemporaines en matière de programmation informatique semblent avoir sur la nature même des diverses conventions de nommage, par extension de la notation hongroise, un regard plutôt hostile. Une illustration particulièrement marquante de ce désaveu tient au fait que Microsoft, qui en fut pourtant le premier promoteur, affirme désormais le caractère obsolète du standard. (Pour information, cette manière d’envisager les choses peut notamment être perçue dans les publications de Microsoft Press relatives au cadre logiciel .NET.) Tristement, les raisons énoncées ne sont que très peu significatives. La position de la firme à ce sujet consiste à mettre au-devant de la scène la technologie IntelliSense, qui consiste en un agrégat de fonctionnalités visant à faciliter l’écriture et la gestion du code, et fournit en l’occurrence une aide (particulièrement bien vue, cela dit) concernant le suivi des données. L’existence de telles solutions de support rendrait l’emploi d’une notation préfixée redondante et peu judicieuse. Si elle est défendable sur le plan de la démarche, cette position reste néanmoins peu avisée pour plusieurs raisons : (1) parce que cette position présume qu’un seul environnement intégré impose le rythme à un pan entier du génie logiciel ; (2) parce que cette position présume que plus personne ne lit de code imprimé ; (3) parce que les technologies de type IntelliSense existent depuis longtemps et, sous d’autres noms et des circonstances différentes, n’ont jamais été vues comme moyen de mettre fin à telle ou telle approche.

Pour finir sur une anecdote amusante, un aspect sur lequel reviennent les détracteurs les plus opiniâtres de la notation hongroise est que même au sein de Microsoft Windows, le maintien de la conformité des variables à ladite norme ne paraît pas, à une certaine échelle, avoir dépassé le stade des versions 16 bits du système. Pour comprendre le propos, il est nécessaire de revenir sur les conditions où s’opérait le traitement des messages dans Windows, ainsi que sur comment elles ont évolué. Ainsi, dans le contexte de Windows 16 bits, les deux types primitifs qui véhiculaient des informations de message étaient encodés l’un sur 16 bits, ce que reflétait le nom wParam (word), l’autre sur 32 bits, ce que soulignait le nom lParam (long). Lors du passage à une architecture 32 bits, aucune mesure ne fut prise afin de mettre en phase ces noms à leur nouvel environnement - la forme wParam aurait dû évolué vers dwParam. Pour certains, cela ne fait que mettre en relief le manque d’evolutivité du modèle. Pour d’autres, cela tient essentiellement à la dimension sémantique du terme word, laquelle renverrait ici au mot machine, dont la taille est fonction de la plateforme matérielle.

MSDN (Microsoft Developer Network)

Microsoft Developer Network (MSDN) est la partie de Microsoft responsable de la gestion de la relation de la firme avec les développeurs qui conçoivent des appareils, services et applications pour Windows. Les médias résultants sont de nature diverse : sites web, bulletins d’information, livres blancs, conférences, articles de presse, entretiens, journaux Web, disques physiques…​ et s’additionnent pour donner naissance à un catalogue à ce jour sans égal en matière de programmation. Pour accéder à la page principale du site MSDN, consultez http://msdn.microsoft.com/fr-fr/default.aspx.

Sites web

Structurée pour l’essentiel autour des moyens de communication offerts par le réseau Internet, l’infrastructure MSDN se présente au premier lieu comme un ensemble de sites web qui accueillent des informations et des discussions utiles au sujet des produits et systèmes Microsoft. Les documents ainsi constitués, qui se chiffrent en millions de pages, sont de la main soit de l’entreprise soit de la communauté de développeurs au sens large. De façon générale, l’accent est mis davantage sur la correspondance et le dialogue plutôt que sur la diffusion unilatérale de contenus.

Bibliothèque MSDN

Ressource primordiale pour les développeurs ciblant les outils, produits et technologies Microsoft, la bibliothèque MSDN contient des informations de programmation technique, des échantillons de code, de la documentation, des articles techniques et des guides de référence. Elle regroupe par exemple l’intégralité des API Windows, du plus bas niveau (écriture de pilotes de périphériques) au plus haut (conception de modules pour les produits Microsoft comme Visual Studio).

La bibliothèque MSDN peut être consultée aux adresses suivantes : http://msdn.microsoft.com/fr-fr/library/ pour la version française et http://msdn.microsoft.com/en-us/library/ pour la version anglaise. Si vous maitrisez l’anglais, nous vous conseiller de consulter cette version, car elle est beaucoup plus complète. De plus, vous êtes certain d’y trouver une documentation parfaitement à jour. Comme il assez est facile de se perdre dans l’arborescence des contenus hébergés par la bibliothèque, Microsoft propose une page web où il est possible de procéder à des recherches. Pour effectuer une recherche, rendez-vous à l’adresse suivante : https://social.msdn.microsoft.com/Search/. La recherche peut s’effectuer soit en anglais soit en français. Cette base de données s’interroge par mot clé ; on peut également faire des recherches avec des opérateurs booléens et restreindre l’espace de recherche à différentes bases de données.

Forums

Les forums MSDN constituent un espace propice aux échanges et aux discussions en ce qui concerne un large éventail de sujets liés au développement de logiciels. Animés par une communauté très active, ils offrent la possibilité de poser des questions, partager des informations ou échanger des idées avec d’autres utilisateurs et des experts partout dans le monde.

Alimentés en permanence de questions et de réponses techniques, les forums MSDN sont l’endroit idéal pour obtenir de l’aide, mais également en apporter. Si vous ne trouvez pas de réponse dans un forum, vous pouvez poser une nouvelle question, être averti lors de la survenue de nouvelles réponses et noter la réponse adéquate. L’interface graphique utilisateur des forums est conçu pour les rendre plus facile à utiliser que les groupes de discussion.

Pour entamez la navigation sur les forums MSDN, consultez le site https://social.msdn.microsoft.com/Forums/.

Blogs

Les blogs MSDN couvrent un éventail considérable de sujets relatifs aux technologies Microsoft. Certains de ces blogs sont consacrés entièrement à un produit majeur, par exemple Windows, Visual Studio ou l’environnement PowerShell, tandis que d’autres privilégient la diffusion de connaissances techniques spécifiques aux métiers de l’informatique.

Voici une sélection de liens que nous vous conseillons :

Un mot sur la conduite à tenir au sein de la communauté de développeurs. Si les auteurs respectifs offrent en général volontiers leur aide, les journaux MSDN sont ouverts à quiconque est à la recherche d’informations sur un sujet technique. Il est ici important de rappeler que les règles qui régissent les forums s’appliquent de la même façon et dans les mêmes proportions aux journaux. Par conséquent, si vous étiez amené à poser une question, veillez à le faire à un endroit approprié.

Base de connaissances

La base de connaissances Microsoft renferme une mine d’informations pratiques et de données sur tous les produits et technologies Microsoft. Alimentée en permanence par des milliers de professionnels de l’assistance, elle est mise à jour, développée et améliorée régulièrement afin de mettre les informations technologiques les plus récentes au vu et au su de tous.

Organisée à la façon d’un vaste dépôt de documents en ligne, chaque article de la base de connaissances Microsoft traite d’un sujet différent et vous y trouverez, presque à coup sûr, les informations que vous recherchez, ou à tout le moins des pistes pour le faire. Le recours à cette base présente toutefois un inconvénient non négligeable, à savoir le fait d’être a priori dépourvue de tout principe évident d’organisation. Cela signifie que si vous ne ciblez pas correctement votre recherche, votre requête risque fort d’être noyée dans le bruit documentaire.

Chaque article de la base de connaissances est identifié par un numéro à six chiffres. À cela s’ajoute un titre décrivant le thème couvert, des informations éventuelles axées sur le produit et la version de produit, ainsi qu’un résumé synthétique présentant brièvement les sujets abordés. Au-delà de ça, chaque article est étiqueté au moyen de mots-clés en relation avec les thématiques dans lesquelles son contenu prend place.

La Base de connaissances Microsoft est disponible sur le réseau MSDN à l’adresse suivante : http://support.microsoft.com.

Magazine

MSDN Magazine fournit des explications approfondies sur l’implémentation des technologies et des outils Microsoft actuels. Il est diffusé sous forme de publication mensuelle en format numérique et imprimé. Pour consulter le magazine en ligne, rendez-vous sur la page https://msdn.microsoft.com/fr-fr/magazine/.

Traduction automatique

Un grand nombre des pages qui entérinent l’engagement de Microsoft sur le secteur du support et l’assistance bénéficient de services de traduction automatisés. Microsoft propose cette traduction pour offrir aux personnes ne maîtrisant pas l’anglais l’accès au contenu relatif aux produits, services et technologies de la firme. Les documents traduits par ce biais peuvent cependant se révéler de moins bonne facture que ceux ayant profité d’une traduction humaine professionnelle.

Mode utilisateur et mode noyau

Pour empêcher les applications d’accéder à et/ou de modifier les données vitales du système d’exploitation, Windows s’appuie sur deux modes d’exécution distincts du processeur : mode utilisateur et mode noyau, l’un et l’autre servant à définir une politique globale en matière matière d’accès, incluant l’interface avec la mémoire et l’exécution des instructions machine. Employée avant tout par Windows afin de parvenir à modèle de contrôle d’accès efficace, cette démarcation entérine au premier stade une scission nette entre le coeur du système, jugé sûr, et ses satellites, considérés comme moins digne de confiance au niveau de la sécurité et de la stabilité.

Le code des applications, ainsi que des sous-systèmes sur lesquels s’appuient les applications de l’utilisateur, est exécuté en mode utilisateur. Les processus en mode utilisateur ne bénéficient pas d’un accès direct au matériel ; ils sont limités à une zone mémoire affectée (excluant la mémoire système et la mémoire d’autres processus) et à un sous-ensemble des instructions du processeur (excluant celles ayant à voir avec la configuration du système informatique). A contrario, le code du système d’exploitation (par exemple les services système et les pilotes) est exécuté en mode noyau, lequel donne accès à l’ensemble de la mémoire et à toutes les instructions du processeur.

Bien que chaque processus Windows ait son propre espace mémoire, le code système et le code des pilotes de périphérique exécuté en mode noyau se partagent un même espace d’adressage, et disposent ainsi des mêmes accès sans restriction à la mémoire système. Autrement dit, tout code noyau a l’accès complet a la mémoire de l’espace système, avec ce que cela suppose d’attention à entretenir lors le chargement de pilotes tierce partie, capables à l’occasion de contourner le modèle de sécurité Windows, voire accidentellement ou volontairement faire s’effondrer le système.

La partition entre mode utilisateur et mode noyau constitue l’un des éléments de base du contrôle d’accès. Les applications exécutées en mode utilisateur ne peuvent ainsi, intentionnellement ou accidentellement, accéder à des données ne leur appartenant pas, ni solliciter diverses instructions machine sensibles en matière de sécurité. En interne, les modes de fonctionnement des processeurs sont implémentés via un mécanisme d’interceptions (trap). Quand une application outrepasse ses droits, par exemple quand une opération issue de son code machine exécutable accède à de la mémoire protégée, s’ensuit le déclenchement d’une interruption matérielle, laquelle est interceptée par le noyau qui met généralement fin à l’application fautive.

Les applications utilisateur passent du mode utilisateur au mode noyau généralement pour solliciter un service système. Quand une application requiert le concours d’une routine exécutée en mode noyau, elle le fait à l’aide d’une instruction processeur spéciale, qui force le processeur à basculer en mode noyau et transfère le contrôle d’une manière sécurisée vers des points d’entrée prédéfinis dans un anneau de plus bas niveau. Le système d’exploitation intercepte cette instruction, remarque la demande vers un service système, valide les arguments que le thread a passé à la fonction système, puis exécute la fonction interne. Lorsque celle-ci se termine, le système d’exploitation repasse le processeur en mode utilisateur et restitue au thread son contexte original, dès lors en mesure de continuer son exécution en mode utilisateur.

Les développeurs peuvent intégrer la partie du système d’exploitation exécutée en mode noyau via la conception de pilotes de périphériques. En réalité, nombre des fonctionnalités attribuées au noyau Windows, telles le système de fichiers, le système de fenêtrage et de graphisme ou la pile réseau TCP/IP, sont conçus de cette façon, conséquemment mis en oeuvre sur la base d’un ou de plusieurs pilotes indépendants.

Anneaux de protection

Les modes utilisateur et noyau que nous venons de voir sont une illustration concrète de comment Windows s’appuie sur les anneaux de protection des architectures x86 et ses extensions. Chaque anneau défini dans un tel schéma l’est de telle sorte à correspondre à un niveau de privilège et de sécurité empêchant les dommages, intentionnels ou non, émanant de code de moindre privilège. Les anneaux sont arrangés dans une hiérarchie allant du plus privilégié (celui qui est le plus sécurisé, habituellement le numéro zéro dit Ring 0) au moins privilégié (le moins sécurisé, habituellement l’anneau le plus élevé).

La notion d’anneaux destinés à sécuriser le système d’exploitation provient à l’origine de Multics, un prédécesseur fortement sécurisé de la famille actuelle des systèmes UNIX, qui s’est par ailleurs brillamment distingué par le grand nombre d’idées novatrices qu’il apportait. Il fut en outre le premier système d’exploitation à intégrer la notion de sécurité informatique (liée au multiutilisateur) dès sa conception.

L’utilisation efficace de l’architecture en anneau implique une coopération étroite entre le matériel (le processeur) et le logiciel d’exploitation. De nombreuses architectures modernes de processeurs intègrent une telle forme de protection, bien que les systèmes d’exploitation ne l’exploitent pas toujours entièrement. Windows, par exemple, quelque soit le nombre d’anneaux que la plateforme d’accueil lui aura conférés, n’en emploie que deux (niveau zéro pour le code noyau, trois en ce qui concerne le code utilisateur). Il déjoue ainsi les pièges d’un modèle de sécurité trop astreignant pour former la base d’un système d’usage général (l’un de ses objectifs de conception), et reste de cette manière compatible avec les quelques architectures matérielles n’incluant que deux types d’anneaux.

Les processeurs de la famille x86 disposent au minimum de quatre anneaux de privilèges. Un autre éventuellement présent correspond au mode hyperviseur sur les machines pourvues d’extensions matérielles de virtualisation (Intel VT et AMD Pacifica, par exemple). Considérant que le système d’exploitation est dans cette configuration un programme sous l’égide d' un outil tiers, ce mode de fonctionnement est quelquefois vu comme un potentiel niveau -1.

Visualisation des temps utilisateur et noyau

L’utilitaire Performances permet de suivre la répartition du temps processeur entre les applications (processus utilisateur) et le système (processus noyau). Voici la procédure :

  1. Démarrez l’utilitaire Performances, par exemple en saisissant la commande perfmon.msc dans la boite de dialogue Exécuter.

  2. Cliquez sur le noeud Analyseur de performances.

  3. Cliquez sur le bouton Ajouter (+) de la barre d’outils.

  4. L’objet Processeur étant sélectionné (il l’est automatiquement), cliquez sur le compteur % Temps privilégié puis, en maintenant la touche CTRL enfoncée, cliquez sur le compteur % Temps utilisateur.

  5. Cliquez sur Ajouter puis faites Ok.

  6. Déplacez rapidement la souris dans un sens puis dans un autre. Selon l’amplitude (minorée par la surface d’affichage) et la vitesse donnée à votre geste, vous devriez constater des variations de plus ou moins grande importance au sein de la courbe % Temps privilégié, à quoi correspond le temps consacré à recevoir et à traiter les interruptions souris, ainsi qu’à gérer les opérations qui s’ensuivent dans la portion mode noyau du sous-système Windows.

Le Gestionnaire des tâches constitue également un moyen pratique de voir rapidement cette activité. Allez dans l’onglet Performances puis sélectionnez l’objet Processeur. Positionnez ensuite le curseur de la souris sur le graphique, faites un clic droit et activez l’option Afficher les temps du noyau. Cela a pour effet de superposer une seconde courbe qui représente le temps de processeur utilisé par le noyau.

Pour voir combien un processus consomme de temps utilisateur et de temps noyau, procédez de la manière qui suit.

  1. Démarrez l’utilitaire Performances. Si une instance de ce processus est déjà en marche, nous vous conseillons de supprimer les compteurs éventuellement présents, ou sinon de masquer l’affichage des informations qui en résultent.

  2. Cliquez sur le noeud Analyseur de performances, et ensuite sur le bouton Ajouter (+) de la barre d’outils.

  3. Parmi ceux disponibles, choisissez les compteurs % Temps privilégié et % Temps utilisateur. À titre informatif, le compteur % Temps Processeur, qui donne le temps CPU total utilisé par un processus, est un cumul des compteurs % Temps privilégié et % Temps utilisateur du même objet.

  4. Sélectionnez le nom du processus duquel vous souhaitez voir les temps d’exécution dans la zone Instances de l’objet sélectionné.

  5. Cliquez sur Ajouter, puis sur Ok.

Du fait que quand le contexte l’exige, Windows effectue une transition de mode, il est tout à fait commun de voir un thread utilisateur passer une partie de son temps d’exécution en mode utilisateur et une autre partie en mode noyau. En outre, les opérations liées à la gestion des fenêtres et au dessin étant en grande majorité mises en oeuvre coté noyau, les applications fortement orientées graphismes passent plus de temps en mode noyau qu’en mode utilisateur.

La liste qui suit énumère les compteurs de performance qui concernent le mode processeur, et partant, se prêtent particulièrement bien à un examen du temps que passe chacune des unités fonctionnelles du système (processeurs, processus et threads) en mode noyau et en mode utilisateur.

  • Processeur : % Temps privilégié Pourcentage de temps qu’un processeur (ou éventuellement tous les processeurs) a passé en mode noyau.

  • Processeur : % Temps utilisateur Pourcentage de temps qu’un processeur (ou éventuellement tous les processeurs) a passé en mode utilisateur.

  • Processus : % Temps privilégié Pourcentage de temps que les threads d’un processus ont passé en mode noyau.

  • Processus : % Temps utilisateur Pourcentage de temps que les threads d’un processus ont passé en mode noyau.

  • Thread : % Temps privilégié Pourcentage de temps qu’un thread a passé en mode noyau. En interne, ce compteur (exprimé en pourcentage) dérive d’un calcul fondé sur la valeur de l’attribut KernelTime dans le bloc KTHREAD d’un thread.

  • Thread : % Temps utilisateur Pourcentage de temps qu’un thread a passé en mode utilisateur.

Windows-1252 et Unicode

Windows-1252 et Unicode sont deux normes informatiques visant à permettre le codage de texte écrit. Le premier (Windows-1252, appelés par confusion ANSI) concerne le codage des caractères de l’alphabet latin, là où Unicode s’entend à décrire de manière unifiée n’importe quel caractère de n’importe quel système d’écriture. Windows s’exportant partout dans le monde, et se devant d’assurer la pérennité des données textuelles, les versions récentes de Windows utilisent le standard Unicode, Windows-1252 subsistant dans les composants hérités du système. Nous le présentons néanmoins pour marquer son existence et son importance passée dans le système d’exploitation.

Windows-1252 ou CP1252 est un jeu de caractères, utilisé historiquement par défaut sur le système d’exploitation Microsoft Windows en anglais et dans les principales langues d’Europe de l’Ouest, dont le français. Il constitue une extension de la norme ISO/CEI 8859-1 (souvent appelée Latin-1 ou Europe occidentale), mais se distingue de cette dernière par l’utilisation de caractères imprimables, plutôt que des caractères de contrôle, dans les codes 128 à 159. Ces derniers ajoutent un certain nombre de caractères, telles les guillemets anglais, les points de suspension, les tirets cadratin et demi-cadratin.

Windows-1252 est parfois appelé ANSI, du nom de l’organisme chargé de superviser le développement de normes pour les produits, les services, les procédés, les systèmes et les employés des États-Unis, l’Institut de normalisation américaine (ANSI, American National Standards Institute). En réalité, Windows-1252 n’a jamais été un standard de l’ANSI. Le nom est donc abusif, faute en incombe à l’utilisation dans la communauté Windows du terme page de code ANSI (ACP, ANSI code page) pour faire référence à Windows-1252. Bien que très populaire, Windows-1252 n’est jamais devenu une norme ANSI, mais le jargon s’y rapportant est néanmoins resté.

Sous l’influence des problèmes d’interopérabilité (les jeux de caractère classiques possèdent des caractéristiques très différentes les uns des autres) et de la mondialisation des échanges (ils ne peuvent au mieux prendre en charge que quelques langues), et bien que le codage Windows-1252 reste très utilisé, ce codage subit la concurrence et le développement du standard Unicode.

Unicode est un mécanisme universel de codage de caractères. Il définit une manière cohérente de coder des textes multilingues et présente un moyen commode de représenter la plupart des alphabets connus dans le monde. Mis en œuvre dans une grande majorité des systèmes d’exploitation modernes, Unicode est au centre de tout logiciel à caractère international.

Le standard Unicode est constitué d’un répertoire de plus de 109 000 caractères couvrant 93 écritures, d’un ensemble de tableaux de codes pour référence visuelle, d’une méthode de codage et de plusieurs codages de caractères standard, d’une énumération des propriétés de caractère (lettres majuscules, minuscules, symboles, ponctuation, etc.), et d’un certain nombre d’éléments liés, tels que des règles de normalisation, de décomposition, de tri, de rendu et de directionalité (pour l’affichage correct de texte contenant à la fois des caractères d’écritures droite à gauche, comme l’arabe et l’hébraïque, et de gauche à droite).

Les données Unicode peuvent être codées sous trois formes principales : une forme codée sur 32 bits (UTF-32), une forme sur 16 bits (UTF-16), et autre forme de 8 bits (UTF-8) conçue pour faciliter son utilisation sur les systèmes ASCII préexistants. Le standard Unicode est identique à la norme internationale ISO 10646 en ce qui concerne l’affectation des caractères (leur numéro) et leurs noms (Unicode est généralement mieux connu que la norme ISO-10646 qui en est un sur-ensemble).

Windows enregistre la plupart des données textuelles internes à l’échelle de caractères Unicode 16 bits, ce que ne fait pas forcément toutes les applications - beaucoup gèrent encore des chaînes de caractère ANSI à 8 bits. Aussi, pour assurer la comptabilité, les fonctions Windows acceptant des chaînes comme paramètres ont deux points d’entrée : une version Unicode (large, 16 bits) et une version ANSI (étroit, 8 bits). lorsqu’une application sollicite la version étroite d’une fonction Windows, les chaînes en entrée sont converties en Unicode avant d’être traités par le système et les chaînes en sortie sont converties en ANSI avant d’être retournées à l’application.

Dans les versions de Windows antérieures a Windows 2000, les éditions Asie et Moyen Orient étaient des déclinaisons à part entière de la version commerciale américaine standard, et contenaient des fonctions supplémentaires pour les saisies et affichages complexes (par exemple, pour gérer les textes bidirectionnels). Du moment où Unicode fut intimement mêlée à Windows, à partir de Windows 2000 donc, cela permis à Microsoft de ne plus prendre en charge des versions distinctes pour tels ou tels langages, mais de reposer à la place sur une même installation gérant plusieurs langues (via l’ajout de packs linguistiques). Les applications peuvent aussi utiliser les fonctions Windows permettant à un même binaire de gérer de multiples langues.

L’architecture de Windows est ainsi faite que les applications conçus sous la perspective Unicode sont plus performantes que les autres. Les fonctions du noyau Windows s’appuyant exclusivement sur Unicode, les chaînes échangées entre le système d’exploitation et les applications usant d’un autre système de représentation des caractères nécessitent un processus de traduction continu qui, s’il n’a pas forcement un impact décisif, n’en reste pas moins présent.

Pour plus d’informations sur Unicode, visitez le site www.unicode.org.

Déterminer si un texte est ANSI ou UNICODE

L’adaptation à différents jeux de caractères peut conduire les applications manipulatrices de fichiers à s’assurer du positionnement Unicode de telles ou telles données. La fonction IsTextUnicode, rendue visible par Advapi32.dll, sert précisément cet objectif.

Le premier paramètre, pvBuffer, spécifie l’adresse du tampon mémoire duquel vérifier la conformité envers Unicode. L’utilisation d’un pointeur non-typé reflète le manque d’informations concrètes sur la nature des données que renferme ledit tampon.

Le second paramètre, cb, indique le nombre d’octets qui seront lues depuis le tampon. Encore une fois, comme les informations disponibles à ce stade ne sont pas suffisantes pour faire référence à un nombre de caractères spécifique, la valeur exprimée ici l’est en nombre d’octets. Elle peut en outre représenter une taille inférieure à celle du du tampon, cela dit au détriment de l’exactitude des conclusions que IsTextUnicode est appelée à fournir.

Le troisième paramètre, pResult, contient l’adresse d’un nombre entier dont la valeur, sous forme d’un masque binaire, sert à l’appelant (comprendre en entrée) à clarifier les objectifs et la portée de l’audit attendu, et pour ce qui concerne la fonction IsTextUnicode elle-même (comprendre en sortie) à relayer les les résultats effectivement obtenus par cet audit en fonction de la démarche suivie.

UNC (Uniform Naming Convention)

La convention de nommage uniforme (UNC, Uniform Naming Convention) est un ensemble de règles destinées à identifier à l’aide d’une adresse unique n’importe qu’elle ressource disponible aux utilisateurs réseau, telle que les répertoires, les fichiers, les canaux de transmission nommés (named pipes) et les imprimantes. Dans les systèmes d’exploitation Windows, et éventuellement d’autres systèmes d’exploitation, UNC peut remplacer dans ses fonctions le système de nommage local (par exemple, C:\partage).

Les dénominations UNC doivent se conformer à la syntaxe \\NOM_SERVEUR\NOM_PARTAGE, dans laquelle NOM_SERVEUR correspond au nom d’un serveur sur le réseau et NOM_PARTAGE au nom de la ressource partagée. Appliquées à des répertoires ou des fichiers, elles peuvent également faire mention du chemin d’accès du répertoire sous le nom de partage, conformément à la syntaxe \\NOM_SERVEUR\NOM_PARTAGE\REPERTOIRE\NOM_FICHIER.

Les dénominations UNC ne requièrent pas d’une ressource qu’elle soit soit stricto sensu un partage réseau, mais désigne par convention comme tel toute ressource accessible par son intermédiaire.

Chaque élément constitutif d’une qualification UNC, à l’exception du dernier, est appelé composant de chemin d’accès (pathname component) ou composant de chemin (path component). Un chemin UNC valide doit en contenir au moins deux, avec le premier considéré comme le premier composant de chemin, le second comme deuxième composant de chemin, et ainsi de suite. Le dernier élément du chemin est aussi appelée composant feuille (leaf component), le situant, dans une terminologie empruntée aux arbres binaire, au plus bas échelon de la hiérarchie.

Système de fichiers

Les périphériques de stockage principaux des systèmes informatiques contemporains, tels que disque dur, CD-ROM et clé USB, doivent au préalable de toute utilisation être configurés par l’intermédiaire d’un système de fichiers, lequel définit un ensemble de conditions et de principes selon lesquels organiser et manipuler des fichiers. Chaque système d’exploitation possède son système de fichier privilégié, même s’il peut en utiliser d’autres. Le tableau suivant donne quelques noms.

Table 3. Systèmes de fichiers de quelques systèmes d’exploitation

Système

Système de fichier

MS-DOS

FAT, aussi appelé FAT-16 (File Allocation Table 16 bits)

Windows 95/98

FAT32, extension du système FAT-16 (File Allocation Table 32 bits)

Windows NT et supérieur

NTFS (New Technology File System)

OS/2

HPFS (High Performance File System)

Linux

Ext4 (Fourth extended file system)

En interne une suite statique d’octets, un fichier est à plus haut niveau d’abstraction une collection d’informations numériques réunies sous un même nom, manipulées comme une unité, et dont c’est le système de fichiers qui caractérisent les propriétés définitoires. A ce titre, fichiers et systèmes de fichiers conditionnent l’accès à toutes les ressources logicielles du système d’exploitation, qui sont à l’exception de la ROM de démarrage, nécessairement situées au niveau d’un ou plusieurs dispositifs de stockage.

Le système de fichiers, ou système de gestion des fichiers, assure plusieurs fonctions :

  • Manipulation des fichiers Le système de gestion de fichiers définit pour manipuler fichiers et répertoires un panel d’opérations les concernant, à savoir créer et détruire des fichiers et des répertoires, insérer, supprimer et modifier les données d’un fichier.

  • Allocation sur mémoires secondaires Le système de fichiers gère l’allocation de l’espace disque aux fichiers et l’espace libre sur le disque dur. Il alloue à chaque fichier, dont la taille est dynamique, une certaine quantité de mémoire secondaire de taille fixe (blocs).

  • Localisation des fichiers Le système de fichiers offre à l’utilisateur une vue abstraite sur ses données, lui permettant de les localiser à partir d’un ensemble d’informations descriptives (nom, adresse) réunies dans un chemin d’accès. Le chemin d’accès d’un fichier ou d’un répertoire est une chaîne de caractères décrivant la position de ce fichier ou répertoire dans le système de fichiers.

  • Sécurité des fichiers Le système de fichiers détermine les différentes options en matière de protection et de contrôle des fichiers. Il permet de la sorte le partage des fichiers par différents programmes d’applications tout en assurant la sécurité et la confidentialité des données parmi les divers utilisateurs.

Services

Nous avons vu dans ce chapitre que le terme "services" sous Windows renvoyait potentiellement à une routine du système d’exploitation, un processus serveur ou un pilote de périphérique. Cette section va traiter des services qui sont des processus en mode utilisateur. Dans ce contexte, un service (ou service Windows) désigne un type de programme qui comprend un ou un ensemble de processus s’exécutant en arrière-plan plutôt que sous le contrôle direct d’un utilisateur. En principe, les services n’interagissent pas avec l’utilisateur connecté.

Les services ressemblent aux "démons" UNIX, en ce sens d’être démarrés souvent lors du chargement du système d’exploitation, et de servir en général à répondre à des requêtes du réseau, à l’activité du matériel ou à d’autres programmes en exécutant certaines tâches. Les services peuvent donc être configurés pour démarrer automatiquement, sans création préalable d’une session interactive. En variante, ils peuvent être lancés manuellement par l’utilisateur (par exemple, via l’outil d’administration Services) ou par un événement ayant besoin du service (événement qui sollicitera pour l’occasion la fonction Windows StartService).

Un service doit se conformer aux règles d’interface et aux protocoles du composant Gestionnaire de contrôle de service (SCM, Service Control Manager), chargé de démarrer, arrêter et gérer les processus de service. Les programmes de service sont en fait des images Windows dont le code est écrit de telle manière à pouvoir répondre aux messages et sollicitations du SCM, incluant des actions du genre inscription du démarrage du service, réponse aux requêtes d’état, suspension ou arrêt du service.

Les services sont rattachés à trois comptes d’utilisateur : le compte Système, le compte Service réseau et le compte Service local. Parce que les services sont associés à leurs propres comptes utilisateur dédiés, ils peuvent fonctionner sans qu’un utilisateur soit connecté au système d’exploitation. Pour plus de détails sur le contexte dans lequel les services sont exécutés, voir au chapitre x la section Comptes de service.

Un certain nombre de composants et fonctionnalités clé de Windows existent sous forme de services, par exemple le spouleur d’impression, le journal des événements, le planificateur de tâches, plus divers composants relatifs au réseau.

Espace de noms

Au premier lieu un moyen commode de lever une ambiguïté sur des termes qui pourraient sans cela être homonymes, le concept d’espace de noms fait dans la perspective des systèmes d’exploitation référence à un lieu abstrait conçu pour l’accueil et l’organisation de ressources de toute nature (mais le plus souvent apparentés), donnant de la sorte aux applications la possibilité d’identifier rapidement un élément parmi d’autres dans la hiérarchie ainsi formée.

Une illustration pour le moins parlante de ce que peut être un espace de noms est le système de fichiers, où les dossiers font dans ce contexte figure d’espace de noms pour les fichiers qu’ils hébergent. Par exemple, le fichier foo.txt peut exister dans plus d’un répertoire, mais deux copies de foo.txt ne peuvent pas coexister dans le même répertoire. De plus, pour faire référence audit fichier depuis l’extérieur du dossier qui le contient, il est nécessaire d’indiquer son chemin d’accès complet, tel que C:\Windows\foo.txt ou C:\Users\foo.txt.

Potentiellement, toute ressource formée à partir d’un sous-ensemble provenant d’un ensemble plus vaste peut être catégorisé selon le principe d’un espace de noms. Cela inclut les fichiers et les dossiers, dont nous avons déjà parlé, mais également les collections de symboles dans un langage de programmation spécifique, les primitives de synchronisation (par exemple mutex, sémaphores, événements, etc.) et les régions de la mémoire partagée utilisées par les processus en cours, et bien d’autres.

API Windows

L’API (Application Programming Interface) Windows est l’interface programmatique de la famille des systèmes d’exploitation Microsoft Windows. Elle est conçue pour les langages de programmation C et C++ et est la manière privilégiée pour une application d’interagir avec le système d’exploitation.

Constituée de milliers de sous-routines appelables depuis le mode utilisateur - autant de points d’entrée vers les services moyen et bas niveau du système -, la couche logicielle Windows est probablement celle présentant le plus d’intérêt pour le plus grand nombre de développeurs, incluant autant ceux nouveaux venus dans l’écosystème Windows que ceux habitués des frameworks et des composants d’interface à l’abstraction plus marquée. Dans ce livre, où il nous arrivera de traiter moins d’elle que de certaines consœurs de plus bas niveau, c’est parce que nous envisageons l’API Windows seulement pour ses liens avec les autres composants fondamentaux du système ; et ce livre n’étant pas un manuel de programmation, jamais en dehors.

L’API Windows couvre un large éventail de fonctionnalités, allant des services de base comme la manipulation des processus et des threads (création et démantèlement), la communication entre programmes ou l’exploitation des réseaux informatiques, à d’autres plus avancés tel la cryptographie, l’application de la sécurité ou l’interaction avec des dispositifs matériels tiers. (C’est par exemple via la fonction Windows DeviceIoControl que le code mode utilisateur envoie une demande à un pilote de périphérique donné, laquelle amène le matériel lié au pilote à effectuer l’opération idoine.)

Les fonctions, structures de données et énumérations de l’API Windows sont pour la plupart documentées, décrites à cet effet dans les divers programmes Microsoft d’assistance aux développeurs, Platform SDK et MSDN notamment. Pour plus de détails, voyez msdn.microsoft.com. Vous trouverez sinon sur le net nombre de tutoriaux.

Historique

À ses débuts, comme le projet était destiné à l’origine comme remplaçant de OS/2 version 2, Windows NT offrait l’interface de programmation 32 bits de OS/2 Presentation Manager. Cependant, Windows 3.0 et le succès qu’on lui connait montrèrent la situation sous un éclairage neuf, et donnèrent un tour nouveau à la carrière de Windows NT, pressenti dès lors pour remplacer Windows au lieu de OS/2.

L’API Windows apportait nombre de fonctionnalités inconnues de Windows 3.1, mais Microsoft décida de rendre la nouvelle API compatible avec les noms de fonction et l’emploi des types de données Windows 16 bits. Pour mettre en exergue son adaptation aux processeurs 32 bits, tels que le Intel 80386 et ses successeurs, et la distinguer de la précédente interface inclue dans les éditions 16 bits (Windows 3.1 et ses prédécesseurs), Microsoft donna à la nouvelle API le nom Win32, renommant au passage l’ancienne en Win16.

A titre informatif, notez que si la conservation de la sémantique entre Win32 et Win16 était pour l’époque un bon moyen de faciliter le portage des applications Windows 16 bits vers Windows NT, elle fut et reste source de confusion. Si vous découvrez l’API Windows pour la première fois et que vous vous demandez pourquoi quelques noms de fonctions et d’interfaces semblent incohérents, la raison majeure vient de vous être expliquée.

Win64 est la version de l’API Windows pour les plateformes 64-bits. Sauf mention du contraire, les architectures de processeur 32 bits et 64 bits coexistant dans les matériels modernes, sauf mention explicite du contraire, Win32 et Win64 forment ensemble l’API Windows.

Composants de l’API Windows

Les fonctionnalités fournies par l’API Windows peuvent être rangées entre plusieurs catégories :

  • Services de base Les services de base donnent accès aux ressources fondamentales du système informatique. Cela inclue par exemple les processus et les threads, le système de fichiers, les pilotes et les périphériques qu’ils desservent. Ils donnent également accès à certaines primitives clé du système d’exploitation, comme la gestion des conditions exceptionnelles pendant l’exécution d’un programme (système de gestion d’exceptions) ou la possibilité de gérer comme un tout un groupe de processus (jobs).

  • Services avancés Là où les services de base se concentrent sur des entités ou des groupes (fichiers, répertoires et autres), les services avancés agissent sur le système dans son ensemble. Sont concernées des opérations spécifiques comme l’extinction de l’ordinateur, la création, le démarrage et l’arrêt des services, ou la manipulation dans les comptes d’utilisateurs.

  • Services graphiques Les services graphiques offrent un tremplin vers les ressources logicielles faisant le transport de contenus graphique vers les divers périphériques de sortie appropriés, tels moniteurs et imprimantes.

  • Services d’interface utilisateur Les services d’interface utilisateur permet d’afficher et de gérer les contrôles de base comme les boutons et barres de défilement, de recevoir les informations du clavier et de la souris et des fonctionnalités associées comme l’environnement graphique.

  • Services réseau Les services réseau ouvrent l’accès aux diverses possibilités du système d’exploitation en matière de gestion de réseau.

Autres implémentations

Bien que l’API Windows soit soumise au Code de la Propriété Intellectuelle et aux droits d’auteur en particulier, quelques initiatives existent pour en proposer une version sur d’autres plateformes. C’est le cas par exemple de Wine qui émule une API compatible avec Win32 pour les systèmes d’exploitation à base UNIX. Un autre exemple est le système ReactOS.

  • Wine Wine est l’acronyme récursif anglophone de "Wine Is Not an Emulator". Ce logiciel est une implémentation libre de l’interface de programmation Windows bâtie sur X et UNIX, c’est-à-dire qu’il permet d’utiliser sur des systèmes d’exploitation non-Microsoft, par exemple Linux ou Mac OS X, des programmes conçus pour fonctionner sous Windows. Il est constitué d’un chargeur de programmes ainsi que d’une bibliothèque d’émulation qui permet l’exécution d’applications Windows sous Unix. Le chargeur de programme va exécuter le binaire d’une application alors que la bibliothèque va servir d’interface entre les appels de fonctions Windows et le système Unix (et l’environnement graphique X).

  • ReactOS ReactOS est un projet de système d’exploitation en développement se voulant compatible avec les programmes et pilotes Microsoft Windows. L’objectif du projet, tel que cité par lui-même, est de fournir un système d’exploitation gratuit et entièrement libre basé sur l’architecture de Microsoft Windows, et devenir une alternative au système d’exploitation dominant le marché actuel. Oeuvrant de concert avec le projet WINE, ReactOS peut donc bénéficier des progrès de Wine dans l’implémentation de l’API Windows. Ces travaux concernent principalement les bibliothèques logicielles, dont la plupart peuvent être échangées entre ReactOS et Wine.

API Native

Si la conception de programmes Windows sous-entend généralement l’utilisation de l’API du même nom, cette dernière n’est en réalité pas tellement proche du coeur du système d’exploitation, lequel se base en l’occurrence sur un autre sous-ensemble d’interfaces, la véritable API système de Windows, dite Native (remarquez la lettre majuscule).

L’API Native est utilisée principalement lors de l’amorçage du système, stade où les autres composants de Windows ne sont pas encore disponibles (ils ne sont sont pas encore chargés en mémoire), puis tout au long du cycle de vue du système par les sous-systèmes, les DLL de sous-système et autres images natives. En plus de cela, l’API Native implémente le code de diffusion de service système pour les services système en mode noyau - autrement dit les appels système.

Quelques processus fondamentaux du système d’exploitation, dont le sous-système d’environnement (Csrss.exe), sont implémentés en utilisant l’API Native. Pour l’utilisateur, l’exemple le plus visible d’une application native est le programme autochk, lequel planifie l’exécution du vérificateur de système de fichiers lors du prochain redémarrage du système.

La plupart des capacités des interfaces de l’API Native sont accessibles via les bibliothèques de l’API Windows principale. Ainsi, NtCreateProcess est le service système interne que la fonction Windows CreateProcess appelle pour créer un nouveau processus. Néanmoins, toutes les fonctions de l’API Native ne sont pas exposées, certaines sont en effet réservées à usage interne du système d’exploitation, et permettent des choses impossibles à réaliser via l’utilisation des API classiques, comme, par exemple, obtenir la liste des handles ouverts d’un processus ou définir les paramètres étendus d’un fichier.

Seule une mince portion du contenu de l’API Native est documentée - le kit de développement pour pilotes laisse place à une petite quantité de description et la Base de connaissances Microsoft à quelques timides évocations. Notez également que la dénomination « API native » n’a rien d’officiel. Il s’agit cependant d’une sorte de consensus dans le monde de la programmation Windows.

Les interfaces et structures de données de l’API Native sont implantés au niveau du module de support système Ntdll.dll, sur lequel nous reviendrons au prochain chapitre.

API noyau

Les différents pensionnaires de l’espace système sous Windows, y compris le noyau et les composants de l’exécutif, définissent relativement aux technologies prises en charge (ordonnancement, processus, mémoire, entrées-sorties, et ainsi de suite) un vaste ensemble de sous-routines, appelables par nature exclusivement à partir du mode noyau, et dont l’ensemble sert en l’occurrence de façade par laquelle le système d’exploitation offre des services à tous les logiciels, incluant les pilotes et autres codes noyau, mais aussi indirectement les applications.

Une des grandes forces de l’API noyau de Windows, par ailleurs la plus essentielle de toutes au regard des aspects fonctionnels, est indéniablement sa stabilité. Cela permet ainsi aux développeurs de concevoir du code qui est portable entre différentes versions de noyaux.

Par contraste avec les interfaces définies au niveau de l’API Windows, disséminées entre plusieurs bibliothèques (Kernel32.dll, User32.dll, etc.) et dont les noms n’évoquent pas les caractéristiques internes, les fonctions rendues visibles sur le plan noyau le sont par l’intermédiaire d’une gamme réduite de support, à savoir Ntoskrnl.exe (ou équivalent) et Hal.dll, et ont leur noms régis par une convention fortement influencée par le caractère modulaire du système d’exploitation.

Les noms des routines système suivent une convention de nommage mettant en valeur l’appartenance de chaque symbole à tel ou tel composant. Par exemple, le préfixe Io représente les fonctions du gestionnaire d’E/S, Ke les interfaces du noyau, Ex les routines de support de l’exécutif, et ainsi de suite. Le tableau qui vient énumère les préfixes les plus couramment employés en la matière.

Table 4. Préfixes pour interfaces en mode noyau
Préfixe Composant

Alpc

Appel de procédure asynchrone

Cc

Gestionnaire de cache

Cm

Gestionnaire de configuration

Ex

Routines de l’exécutif

FsRtl

Bibliothèque d’exécution du pilote de système de fichiers

Hal

Couche d’abstraction matérielle

Io

Gestionnaire d’E/S

Ke

Noyau

Ldr

Chargeur de modules

Lpc

Appel de procédure locale

Mm

Gestionnaire mémoire

Nt

Services système

Ob

Gestionnaire d’objets

Po

Gestionnaire d’alimentation

Pp

Gestionnaire PnP

Ps

Gestionnaire de processus

Rtl

Bibliothèque d’exécution

Se

Sécurité

Wmi

Windows Management Instrumentation

Zw

Appel système

En marge du schéma précédemment décrit, les principaux composants de l’exécutif utilisent une variation du préfixe pour désigner les fonctions internes : soit la première lettre du préfixe suivie d’un i (comme interne), soit le préfixe complet suivi de la lettre p (comme privé). Ainsi, Ki représente les fonctions internes du noyau et Psp les fonctions internes de support du gestionnaire de processus.

Objets et handles

Windows emploie pour la représentation et la manipulation des ressources clé du système d’exploitation deux notions concomitantes mais complémentaires, incarnées l’une par les objets, l’autre par les handles.

Au plus haut niveau d’abstraction, un objet est un ensemble plus ou moins fermé (vu qu’extensible) regroupant les propriétés définitoires d’une même catégorie d’entités. L’objet de type processus, par exemple, contient toutes les informations de contrôle requises pour la gestion de tels éléments - et un objet processus (comprendre un en particulier) représente une instance donnée d’un objet processus. Il en va de même pour les threads, fichiers, périphériques, pilotes, clés de registre, et bien d’autres.

Si, en surface, peu de signes objectifs conviennent pour établir une distinction claire entre objets et structure de données ordinaire, quelques différences fondamentales les séparent. D’une part, la structure interne d’un objet est masquée. Il est pour cette raison indispensable avant d’interagir avec un objet de solliciter les services prévus à cet effet. D’autre part, l’implémentation du code de gestion des objets (générique par nature) étant disjointe du code utilisant l’objet (qui elle est spécifique aux objets d’un même type), il n’est possible de lire ou de modifier directement les données d’un objet sans le faire en violation des politiques instaurées en matière de rétention des objets, qui précisent quand un objet est automatiquement détruit.

Les structures de données du système Windows ne sont pas toutes des objets. Seules les ressources qu’il faut partager, protéger, nommer ou rendre visibles aux programmes en mode utilisateur voient leur fonctionnalité exprimés en tant que tels. Notez également que certains ouvrages ou documentations ont à cet égard une définition plus ample de ce qu’est un objet, et vont jusqu’à utiliser ce concept pour faire référence à des structures communes en mode utilisateur, par exemple les sections critiques. Dans ce livre, nous utilisons le terme objet dans son sens le plus strict, à l’aune des principes exposés plus tôt.

Les processus mode utilisateur souhaitant manipuler les ressources vers lesquelles les objets fournissent un tremplin n’accèdent pas directement aux structures de données stockées dans l’espace mémoire du noyau, mais ont pour obligation d’obtenir un handle sur l’objet. Au plus large degré d’abstraction, un handle (ou identificateur d’objet) est une valeur opaque qui fait office de référence à une instance d’un objet en particulier.

De nombreuses fonctions au sein de l’API Windows conduisent à la création d’objets noyau de tout type (processus, thread, fichier, etc.) et renvoient alors à l’appelant un handle, lequel permet par la suite d’effectuer des opérations sur l’objet. Les handles vers un objet donné sont spécifiques au processus initiateur de l’objet. Il est cependant possible pour un processus, sous réserve que les conditions de sécurité s’y prêtent, de dupliquer un handle relevant d’un autre processus, et de la sorte se voir conférer un accès au même objet.

Le mécanisme d’objets et de handles a notamment les avantages suivants :

  • Favoriser l’uniformité d’accès aux objets du noyau en proposant un intermédiaire commun pour accéder aux ressources qu’ils décrivent, cela sous forme d’un unique type de données (handle en l’occurence).

  • Simplifier la mise à des jour des structures de données internes du système d’exploitation tout en assurant la rétro compatibilité (comprendre sans modifier les interfaces de programmation rendues visibles aux concepteurs de logiciels).

  • Représenter facilement des droits d’accès différents pour un même objet (un processus peut exemple acquérir deux handles sur le même fichier, l’un en lecture seule, l’autre en écriture).

Interface binaire-programme

L’interface binaire-programme (ABI, application binary interface) de Windows définit les procédés bas niveau en oeuvre entre le système d’exploitation et les autres logiciels, dont applications, images natives et bibliothèques. L’ABI détermine quelles conventions d’appels peuvent être utilisées, et comment les arguments et valeurs de fonctions doivent être traités. A plus grande échelle, l’ABI couvre l’ensemble des fonctions du système, elle fixe outre les modalités opérationnelles des applications, liés directement au code machine exécutable, certaines d’ordre plus général, comme le format natif des images exécutables, ou encore la valeur, la taille et l’alignement des données.

Mot machine et types fondamentaux

Le mot machine est un concept en informatique théorique définissant la quantité de données qu’une machine peut traiter en une seule fois. Un mot machine est un nombre entier, une mesure conditionnant les tailles sur lesquelles opèrent les composants de l’architecture tels que registre processeur ou bus mémoire. Typiquement, la taille de l’espace d’adressage est égale à celle d’un mot machine, conséquemment celle d’un pointeur.

Confondu parfois avec le mot machine, le mot (notez l’absence de connotation à un matériel) est une désignation arbitraire faite par la plupart des systèmes d’exploitation, répartissant les tailles standards des entiers entre octets (8 bits), mots (16 bits), double mots (32 bits) et quadruple mots (64 mots).

Le langage de programmation C manquant d’un mécanisme pour ajouter de nouveaux types de données fondamentales (les spécifications du C dictent seulement les tailles minimales des types fondamentaux, à l’exception du type char toujours encodés sur 8 bits d’information), chaque fois qu’une nouvelle architecture processeur a étendu les capacités de l’espace d’adressage, il a fallu repenser la définition des types existants ou ajouter de nouveaux types (non fondamentaux). Windows utilise les deux procédés.

Trois modèles peuvent être choisis afin de changer la carte des types fondamentaux : LP64, ILP64 et LLP64. Ces notations décrivent la quantité de stockage nécessaire aux types de données de base. La notation LP64 montre que les types long et pointer sont encodés sur 64 bits. ILP64 signifie que ce sont les types int, long et pointer qui le sont. LLP64 assigne 64 bits à un nouveau type de données long long) et aux pointeurs. Le tableau x indique la quantité de stockage nécessaire pour les types fondamentaux selon le modèle choisi. A titre informatif, on a également indiqué les notations LP32 et ILP32, cette dernière étant celle utilisée par la plupart des systèmes 32 bits actuels, où les types int, long et pointeur sont tous de même largeur (32 bits).

Table 5. Quantité de stockage des types fondamentaux
Type LP64 ILP64 LLP64 ILP32 LP32

char

8

8

8

8

8

short

16

16

16

16

16

int

32

64

32

32

16

long

64

64

32

32

32

long long

64

64

64

32

32

pointer

64

64

64

32

32

Microsoft Management Console (MMC)

Microsoft Management Console (MMC) est une infrastructure logicielle commune à divers utilitaires d’administration système créés par Microsoft et d’autres éditeurs. Destiné à centraliser et simplifier les tâches quotidiennes de gestion de l’ordinateur, MMC agit comme conteneur pour des interfaces graphiques de configuration, fournissant à ce titre un moyen commode de visualiser l’état et de manipuler les composants logiciels, matériels et réseau de Windows. Servant de base à de nombreux outils incorporés dans Windows, tels Gestion de l’ordinateur, MMC permet de créer des interfaces utilisateur plus flexibles et de personnaliser les outils d’administration en regroupant leur fonctionnalité dans une fenêtre unique.

MMC comporte plusieurs outils qu’elle affiche sous forme de consoles. Ces outils, composés d’une ou de plusieurs applications, sont construits à partir de modules appelés composants logiciels enfichables. Ces composants peuvent eux-mêmes contenir d’autres composants logiciels enfichables d’extension. Les extensions livrées avec Windows permettent notamment de contrôler l’état des périphériques, lire les journaux d’activité, mesurer l’utilisation du processeur et de la mémoire, configurer des imprimantes, installer des logiciels, manipuler les services, planifier l’exécution en traitement par lots et manipuler les comptes utilisateurs.

L’image native correspondant à Microsoft Management Console est mmc.exe, située dans le répertoire %SystemRoot%\System32. Le tableau suivant énumère quelques-unes des consoles intégrées.

Nom anglais Nom français Console

Certificates

Certificats

certmgr.msc

Certificates template

Modèles de certificats

certtmpl.msc

Indexing Service

Service d’indexation

ciadv.msc

Component Services

Services des composants

comexp.msc

Computer Management

Gestion de l’ordinateur

compmgmt.msc

Device Manager

Gestionnaire de périphériques

devmgmt.msc

Disk Defragmenter

Défragmenteur de disque

dfrg.msc

Disk Management

Gestion des disques

diskmgmt.msc

Domain name system management

Gestionnaire DNS

dnsmgmt.msc

Event Viewer

Observateur d’événements

eventvwr.msc

Shared Folders

Dossiers partagés

fsmgmt.msc

Group Policy

Stratégie de groupe

gpedit.msc

Local Users and Groups

Utilisateurs et groupes locaux

lusrmgr.msc

NAP Client Configuration

Configuration du client NAP

napclcfg.msc

Removable Storage

Stockage amovible

ntmsmgr.msc

Performance

Performance

perfmon.msc

Print Management

Gestion de l’impression

printmanagement.msc

Resultant Set of Policy

Jeu de stratégie résultant

rsop.msc

Local Security Settings

Paramètres de sécurité locaux

secpol.msc

Services

Services

services.msc

Task Scheduler

Planificateur de tâches

taskschd.msc

WMI Management

Contrôle WMI

wmimgmt.msc

Composants logiciels enfichables

Ainsi que nous l’avons déjà suggéré, MMC tient moins du logiciel autonome que de l’environnement de gestion partagé inter-applications. MMC est ainsi une application qui, en elle-même, ne fournit aucun service particulier, mais dans laquelle d’autres outils appelés composants logiciels enfichables peuvent être installés et utilisés. Chacun de ces composants met en oeuvre une fonctionnalité d’administration de base. Lorsqu’un ou plusieurs composants logiciels enfichables sont installés dans MMC, le résultat est alors appelé une console. Un jeu de consoles standard est livré avec tout ordinateur exécutant Windows, pour la plupart accessible depuis le groupe de programmes Outils d’administration.

Un composant enfichable peut posséder une ou plusieurs extensions (certaines elles-mêmes enfichables). La console Gestion de l’ordinateur, par exemple, qui ouvre l’accès à des outils majeurs d’administration du système, des services, et du stockage, est constituée de nombreuses extensions : Observateur d’événements, Planificateur de tâches, Utilisateurs et groupes locaux, et d’autres.

Par défaut, les fichiers correspondants à des composants enfichables portent l’extension .msc et se situent sous le répertoire %SystemRoot%\System32.

Modes d’accès d’une console MMC

Lorsque vous créez une console de composant logiciel enfichable personnalisée, vous avez le choix entre deux options d’accès : le mode Auteur, qui ouvre l’accès à toutes les tâches envisageables depuis une MMC, et le mode Utilisateur, qui comporte trois niveaux de restrictions concernant l’utilisation de la console. En définitive, quatre options différentes pour l’accès par défaut à la console sont ainsi disponibles.

  • Mode auteur Les utilisateurs peuvent ajouter ou supprimer des composants logiciels enfichables, créer des fenêtres, afficher toutes les parties de l’arborescence de la console ainsi qu’enregistrer toutes les modifications apportées.

  • Mode utilisateur - accès total Les utilisateurs peuvent se déplacer dans la console, créer et ouvrir de nouvelles fenêtres mais pouvoir les enregistrer, ni même ajouter ou supprimer des composants enfichables.

  • Mode utilisateur - accès limité, fenêtre multiple Les utilisateurs peuvent créer de nouvelles fenêtres mais ne peuvent fermer aucune de celles déjà existantes - autrement dit les parties de l’arborescence qui étaient visibles lorsque le fichier de console a été enregistré.

  • Mode utilisateur - accès limité, fenêtre unique Identique au mode précédent mais les utilisateurs n’ont pas le droit d’afficher plusieurs fenêtres.

Dans l’éventualité où vous rencontreriez une console bridée par l’un de ces modes, vous pouvez (moyennant des privilèges suffisants) forcer l’ouverture en mode auteur (voir section suivante) ou configurer les options idoines depuis la boite de dialogue Options de MMC.

Exécuter une console en mode Auteur

Les consoles MMC peuvent s’exécuter en mode Auteur ou dans trois variantes du mode Utilisateur. Le mode Auteur permet une personnalisation intégrale de la console de composant logiciel enfichable, en donnant notamment la possibilité d’ajouter ou supprimer des composants logiciels enfichables, de créer des fenêtres, et d’accéder à tous les menus ainsi qu’à toutes les options (comprendre les options des boîtes de dialogue Personnalisation de l’affichage et Options).

Par défaut, chaque console MMC s’exécute dans le mode où elle fonctionnait la dernière fois qu’elle a été enregistrée. Ceci dit, vous pouvez toujours exécuter une console dans le mode de votre choix.

Pour exécuter une console en mode Auteur, faites un clic droit sur le fichier la représentant dans une fenêtre de l’Explorateur Windows et choisissez Auteur dans le menu contextuel. Il est également possible afin de parvenir aux mêmes effets d’impliquer le commutateur de ligne de commande /a. Cela donne : nom.msc /a, où nom est le nom du fichier de la console.

Invite de commandes (Cmd)

Démarrer des programmes

Une particularité intéressante (quoique peu extraordinaire) de l’Invite de commandes est de pouvoir démarrer toutes sortes de programmes, qu’ils soient ou non dédiés à une utilisation console ou graphique. Il n’est de ce fait pas nécessaire de connaitre la nature d’une application pour la voir se réaliser : un programme en mode caractère s’exécutera dans la fenêtre Invite de commandes depuis laquelle il a été sollicité, un programme Windows dans sa propre fenêtre externe.

Dans les versions de Windows précédant XP, si vous exécutiez un programme Windows depuis une Invite de commandes, la session correspondante restait inaccessible jusqu’à ce que le logiciel ait terminé son exécution. Si, pour une raison quelconque, une de vos applications reposait sur ce comportement, exécutez-la au moyen de la commande start accompagnée du commutateur /wait.

Syntaxe de la ligne de commande Cmd

La syntaxe complète de la ligne de commande associée à Cmd est la suivante :

cmd [/a | /u] [/q] [/d] [/e:on | /e:off] [/f:on | /f:off] [/v:on | /v:off] [[/s] [/c | /k] chaînecommandes]
  • /a | /u Système d’encodage utilisé pour du texte dirigé vers un fichier ou un autre canal de communication. Utilisez /A pour ANSI et /U pour Unicode.

  • /f:on | /f:off Recommandations concernant les caractères qui complètent les noms de fichiers et de dossiers. Cmd /f:on démarre une session d’Invite de commandes avec CTRL+D comme caractère pour compléter un chemin et CTRL+F pour compléter un nom de fichier, désactivant ainsi les paramètres enregistrés dans le Registre à cet égard (valeurs CompletionChar et PathCompletionChar sous HKCU\Software\Microsoft\Command Processor pour l’utilisateur courant, et même clés dans HKLM pour tous les utilisateurs, touche TAB par défaut). Cmd /f:off démarre une session sans caractère attribué, quels que soient les options stipulées dans le Registre.

  • /c | /k Exécute une chaîne de commandes spécifiée en paramètre. La différence entre ces deux commutateurs tient au fait que l’un (/c) a pour effet de terminer la session d’Invite de commandes dès que la chaine de commandes s’est achevée, tandis que l’autre (/k) entraine un maintien de la session.

Commandes de base

Le tableau qui suit répertorie les différentes commandes et outils accessibles depuis l’invite de commandes. Si vous avez un doute sur la syntaxe à utiliser pour une commande particulière, n’hésitez pas à faire appel à la commande help.

ASSOC Affiche ou modifie les applications associées aux extensions de fichiers.

ATTRIB

Affiche ou modifie les attributs d’un fichier.

BREAK

Active ou désactive le contrôle étendu de CTRL+C.

BCDEDIT

Définit les propriétés dans la base de données de démarrage pour le contrôle du chargement d’amorçage.

CACLS

Affiche ou modifie les listes de contrôles d’accès aux fichiers.

CALL

Appelle un fichier de commandes à partir d’un autre fichier de commandes.

CD

Modifie le répertoire ou affiche le répertoire actif.

CHCP

Modifie ou affiche le numéro de la page de code active.

CHDIR

Modifie le répertoire ou affiche le nom du répertoire actif.

CHKDSK

Vérifie un disque et affiche un rapport d’état.

CHKNTFS

Affiche ou modifie la vérification du disque au démarrage.

CLS

Efface l’écran.

CMD

Exécute une nouvelle instance de l’interpréteur de commandes de Windows.

COLOR

Modifie les couleurs du premier plan et de l’arrière-plan de la console.

COMP

Compare les contenus de deux fichiers ou groupes de fichiers.

COMPACT

Modifie ou affiche la compression des fichiers sur une partition NTFS.

CONVERT

Convertit des volumes FAT en volumes NTFS. Vous ne pouvez pas convertir le lecteur en cours d’utilisation.

COPY

Copie un ou plusieurs fichiers.

DATE

Affiche ou définit la date.

DEL

Supprime un ou plusieurs fichiers.

DIR

Affiche la liste des fichiers et des sous-répertoires d’un répertoire.

DISKCOMP

Compare les contenus de deux disquettes.

DISKCOPY

Copie le contenu d’une disquette sur une autre.

DISKPART

Affiche ou configure les propriétés d’une partition de disque.

DOSKEY

Modifie les lignes de commande, rappelle des commandes Windows, et crée des macros.

DRIVERQUERY

Affiche l’état et les propriétés du pilote de périphérique en cours d’utilisation.

ECHO

Affiche des messages ou active/désactive l’affichage des commandes.

ENDLOCAL

Stoppe la localisation des modifications d’environnement dans un fichier de commandes.

ERASE

Supprime un ou plusieurs fichiers.

EXIT

Quitte l’interpréteur de commandes (CMD.EXE).

FC

Compare deux fichiers ou groupes de fichiers et affiche les différences.

FIND

Recherche une chaîne de caractères dans un ou plusieurs fichiers.

FINDSTR

Cherche des chaînes dans les fichiers.

FOR

Exécute une commande sur chaque fichier d’un ensemble de fichiers.

FORMAT

Formate un disque devant être utilisé avec Windows.

FSUTIL

Affiche ou configure les propriétés du système de fichiers.

FTYPE

Affiche ou modifie les types de fichiers utilisés dans les associations d’extensions.

GOTO

Indique l’exécution d’un fichier de commandes pour une ligne identifiée par une étiquette.

GPRESULT

Affiche les informations de stratégie de groupe pour un ordinateur ou un utilisateur.

GRAFTABL

Permet à Windows d’afficher un jeu de caractères en mode graphique.

HELP

Affiche des informations sur les commandes de Windows.

ICACLS

Afficher, modifier, sauvegarder ou restaurer les listes de contrôle d’accès pour les fichiers et les répertoires.

IF

Effectue un traitement conditionnel dans un fichier de commandes.

LABEL

Crée, modifie ou supprime le nom de volume d’un disque.

MD

Crée un répertoire.

MKDIR

Crée un répertoire.

MKLINK

Créer des liens symboliques et des liens physiques

MODE

Configure un périphérique du système.

MORE

Affiche la sortie écran par écran.

MOVE

Déplace un ou plusieurs fichiers d’un répertoire à un autre.

OPENFILES

Affiche les fichiers partagés ouverts à distance par les utilisateurs.

PATH

Affiche ou définit le chemin de recherche des fichiers exécutables.

PAUSE

Interrompt l’exécution d’un fichier de commandes et affiche un message.

POPD

Restaure la valeur précédente du répertoire actif enregistrée par PUSHD.

PRINT

Imprime un fichier texte.

PROMPT

Modifie l’invite de commande de Windows.

PUSHD

Enregistre le répertoire actif puis le modifie.

RD

Supprime un répertoire.

RECOVER

Récupère l’information lisible d’un disque défectueux.

REM

Insère un commentaire dans un fichier de commandes ou CONFIG.SYS.

REN

Renomme un ou plusieurs fichiers.

RENAME

Renomme un ou plusieurs fichiers.

REPLACE

Remplace des fichiers.

RMDIR

Supprime un répertoire.

ROBOCOPY

Utilitaire avancé pour copier les fichiers et les arborescences de répertoires

SET

Affiche, définit ou supprime des variables d’environnement Windows.

SETLOCAL

Commence la localisation des modifications d’environnement dans un fichier de commandes.

SC

Affiche ou configure les services (processus en arrière-plan).

SCHTASKS

Planifie les commandes et les programmes à exécuter sur l’ordinateur.

SHIFT

Modifie la position des paramètres remplaçables dans un fichier de commandes.

SHUTDOWN

Permet un arrêt local ou distant correct de l’ordinateur.

SORT

Trie les entrées.

START

Ouvre une fenêtre séparée pour l’exécution d’un programme ou d’une commande spécifique.

SUBST

Associe un chemin d’accès à une lettre de lecteur.

SYSTEMINFO

Affiche les propriétés et la configuration spécifiques de l’ordinateur.

TASKLIST

Affiche toutes les tâches en cours d’exécution, y compris les services.

TASKKILL

Termine ou interrompt un processus ou une application en cours d’exécution.

TIME

Affiche ou définit l’heure du système.

TITLE

Définit le titre de la fenêtre pour une session CMD.EXE.

TREE

Affiche le graphisme de la structure de répertoire d’un lecteur ou d’un chemin d’accès.

TYPE

Affiche le contenu d’un fichier texte.

VER

Affiche la version de Windows.

VERIFY

Demande à Windows de vérifier si vos fichiers sont correctement écrits sur le disque.

VOL

Affiche le nom et le numéro de série d’un volume de disque.

XCOPY

Copie les fichiers et les arborescences de répertoires.

WMIC

Affiche les informations WMI dans l’interface de commande interactive.

Interprètes de commandes

Le rôle premier d’un interprète de commandes consiste à fournir une interface d’accès en mode caractère à tout ou partie des fonctionnalités du système d’exploitation. La mise en oeuvre de cet objectif s’effectue sur le plan concret en deux temps : (1) l’analyse syntaxique d’une commande par examen des mots et caractères la constituant, cela afin d’en isoler les options et les arguments, et (2) le chargement de ladite commande pour exécution au sein d’un processus tiers.

S’ils occupent une place moins centrale que dans d’autres systèmes d’exploitation (Unixoïdes surtout), il existe plusieurs interprètes de commandes populaires pour Windows. Parmi eux on trouve :

  • Cmd Cmd est un logiciel d’interprétation des commandes Windows (et éventuellement DOS) affichant une interface utilisateur en mode texte. Processeur de commandes historique de Windows, ce logiciel fournit une interface pratique pour exécuter des tâches courantes, telles que commandes externes, programmes batch et d’autres exécutables. Avec l’enracinement de plus en plus marqué de PowerShell dans Windows, on assiste depuis quelques années à une diminution progressive de l’importance accordée à Cmd.

  • PowerShell Suite logicielle intégrant à la fois une invite de commandes interactives et un puissant langage de scripts, PowerShell permet de piloter localement ou à distance l’ensemble des services offerts sur des systèmes Microsoft.

  • Bash Bash (acronyme de Bourne-Again shell) est l’interprète par défaut sur de nombreux Unix libres, notamment les environnements GNU/Linux. Grâce à un partenariat entre Microsoft et Canonical, il est depuis Windows 10 possible de disposer d’un Bash Ubuntu natif, et par cet intermédiaire de profiter de certains avantages de Linux sans pour autant faire cohabiter les deux systèmes d’exploitation (double boot) ou utiliser des technologies de virtualisation.

  • Autres Plusieurs logiciels conçues originellement pour les systèmes POSIX (tels que les systèmes GNU/Linux, BSD, et Unix) proposent une version compilée pour Windows - ou, a minima, laissent à des tiers le soin d’en fournir une. C’est, par exemple, le cas de Tcsh, Bash, et d’autres. Une alternative consiste à utiliser Cygwin, Gnu On Windows, ou toute autre application du même style.

A titre informatif, notez que les logiciels que nous venons de passer en revue ne sont que quelques-unes des formes de l’invite de commandes dans Windows. Les autres comportent le contrôle Exécuter (commande Run), la barre d’adresses de l’explorateur Windows, et même celle du navigateur Internet. En bien des points, ces invites de commande fonctionnent selon les mêmes conventions et les mêmes principes.

Le tableau suivant énumère plusieurs commandes équivalentes dans l’invite Cmd, PowerShell, et dans les shells Unix.

Cmd Shell PowerShell (cmdlet) PowerShell (alias) Description

cd

pwd

Get-Location

gl, pwd

Afficher le répertoire de travail courant

cd, chdir

cd

Set-Location

sl, cd, chdir

Changer le répertoire courant

cls

clear

Clear-Host

cls, clear

Effacer l’affichage

dir

ls

Get-ChildItem

gci, dir, ls

Afficher le contenu d’un répertoire

help

help, which

Get-Command

gcm

Obtenir une l’aide générale

help

man

Get-Help

help, man

Obtenir de l’aide aide sur une commande en particulier

kill

kill

Stop-Process

spps, kill

Arrêter un processus en cours d’exécution

move

mv

Move-Item

mi, move, mv

Déplacer un fichier ou répertoire

tasklist

ps

Get-Process

gps, ps

Afficher les processus en cours d’exécution

Fonctionnalités de Windows

Ajouter ou supprimer des fonctionnalités Windows

C’est en matière de fonctionnalités l’édition de Windows exécutée sur la station de travail qui détermine lesquelles sont fournies de base, et lesquelles sont complémentaires. Pour réviser cette liste et activer ou désactiver certaines d’entre elles, ouvrez le menu Programmes au Panneau de configuration et cliquez sur Activer ou désactiver des fonctionnalités Windows sous le titre Programmes et fonctionnalités.

La boite de dialogue Fonctionnalités de Windows indique celle présentes dans votre édition : une case coche signifie que la fonctionnalité est actuellement activée, une case blanche qu’elle est désactivée. Une case pleine (ni cochée, ni décochée) signifie qu’une partie seulement de la fonctionnalité est activée. Quelques fonctionnalités sont montrées sous forme d’une structure arborescente. Cliquez sur le signe plus à gauche de l’entrée de sorte à voir les filles d’une fonctionnalité parent.

Certaines fonctionnalités ne peuvent être mises en sommeil sans que des problèmes en résultent, et un message s’affiche alors afin de vous avertir du risque encouru par une telle tentative. Les fonctionnalités liées à Internet Explorer, par exemple, ne devraient idéalement jamais quitter le système - peu importe que vous utilisiez ou non ce navigateur, ces dernières se voyant mutualisées entre plusieurs composants essentiels au bon fonctionnement de Windows.

Notez que les fonctions désactivées restent installées en vue d’une utilisation ultérieure, et n’imputent en cela en rien l’espace de stockage - du reste, compte tenu des tailles des disques durs actuels, cela n’a aucune espèce d’importance. Inhiber les moins utiles (selon vos besoins) contribue néanmoins à maximiser les performances du système en réduisant le nombre de processus.

Windows Update

Tant les utilisateurs que les administrateurs ont besoin de mécanismes efficaces et commodes d’emploi leur permettant de bénéficier des dernières améliorations et optimisations. Pour répondre à ces exigences, Windows inclue un système automatisé de mises à jour, sobrement nommé Update, qui prend en charge la montée à niveau des logiciels s’exécutant sur la plateforme, dont le système d’exploitation, les pilotes de périphérique et quelques applications prédéfinies.

Update se connecte périodiquement à un serveur désigné - site hébergé par Microsoft (http://windowsupdate.microsoft.com) ou bien par l’entreprise - pour vérifier l’existence de nouvelles mises à jour. Selon la configuration, lorsque l’agent Update détermine que des mises à jour sont disponibles, soit il les télécharge et les installe automatiquement, soit il en informe l’utilisateur.

Windows Update classe les mises à jour logicielles selon leur niveau de criticité : importantes, recommandées et facultatives. Outre l’aspect informatif de cette nomenclature, l’agent Update prioritise les téléchargements de façon que les mises à jour soient appliqués par ordre d’importance. Cela permet aux mises à jour les plus critiques, par exemple un correctif de sécurité, d’être installées avant celles moins cruciales.

Les transferts réseau à l’initiative de Windows Update s’effectuent par l’intermédiaire de la technologie BITS (Background Intelligent Transfer Service). Ils ont de la sorte un impact négligeable sur la bande passante (plus précisément, sur l’impression que peuvent en avoir les usagers du même réseau) et peuvent être interrompus ou repris à volonté.

Pilotes de périphérique

Les pilotes de périphérique (device drivers en anglais) sont des composants logiciels qu’emploient les systèmes d’exploitation pour interagir avec les équipements matériels de l’ordinateur, qu’il s’agisse de dispositifs scellés, par exemple un disque interne, ou de périphériques externes, tels que claviers, souris, imprimantes, et bien d’autres. Ils peuvent être propres à un dispositif ou à une famille de dispositifs (comme l’ensemble des imprimantes d’un même constructeur), ainsi qu’à une version spécifique d’un système d’exploitation. On parlera, par exemple, d’un pilote pour telle carte réseau fabriquée par tel constructeur et de ce modèle précis compatible ou non avec une version définie de Windows, Linux, ou autres systèmes.

En règle générale, seuls les pilotes de haut niveau font partie intégrante du système d’exploitation, par exemple le pilote NTFS pour Windows ou les pilotes ext2/3/4 pour Linux. Les autres pilotes, qui régissent des aspects aussi fondamentaux, mais exogènes, peuvent être intégrés de façon statique au noyau ou chargés à la demande sous forme de modules.

De nombreux systèmes d’exploitation, pour assurer la prise en charge d’un maximum de configuration, fournissent des versions génériques des pilotes, lesquels mettent en oeuvre les fonctions de base communes à l’ensemble des périphériques d’un même type, et couvrent ainsi un large panel d’utilisations. À titre d’exemple, il existe des pilotes génériques pour VESA (cartes vidéo), USB (périphériques de stockage), Wi-Fi (équipements réseau), et ainsi de suite. Bien que très utiles, ces pilotes, destinés uniquement à des fins générales, ne donnent de toute évidence pas accès à toutes les fonctionnalités des périphériques (par exemple, dans le cas d’une imprimante : recto-verso, double bac, etc.). C’est pourquoi il est peut-être important de mettre à jour le pilote générique d’un périphérique donné pour le remplacer par celui fourni par le constructeur.

A de rares exceptions près, les ressources prises en charge par le biais de pilotes sont accessibles uniquement depuis le mode noyau. Le système d’exploitation, en tant que fournisseur d’un ensemble commun de services d’entrées/sorties, peut éventuellement permettre l’envoi de séquences de paramétrage à un périphérique depuis un programme utilisateur, ce via le mécanisme des appels système. Dans ce cas de figure, les pilotes servent tout à la fois à séparer et à unir les programmes de leur environnement d’exécution : s’il leur est impossible d’accéder de manière directe aux périphériques, ils peuvent en néanmoins en tirer parti, mais toujours sous arbitrage, et dans un contexte fortement régulé.

Panneau de configuration

Le Panneau de configuration est un composant de Microsoft Windows qui fait office de référentiel central pour l’accès aux outils de configuration du système et des applications.

Pour une clarté accrue de l’information, deux modes de visualisation sont proposés : la vue par catégorie et la vue classique. Il est possible de passer d’une option à l’autre depuis le côté supérieur droit de la fenêtre. Notez en outre la zone de recherche qui permet de rapidement se positionner sur l’applet de configuration de la fonctionnalité de votre choix.

Lors de la navigation parmi les menus du panneau de configuration, le volet gauche de la fenêtre s’adapte à l’emplacement actuel et propose des raccourcis vers des taches d’administration complémentaires.

Table 6. Applets de configuration
Applet (cpl) Nom canonique Description

Access.cpl

Microsoft.EaseOfAccessCenter

Options d’ergonomie

Admintools.cpl

Microsoft.AdministrativeTools

Outils d’administration

Appwiz.cpl

Microsoft.ProgramsAndFeatures

Programmes et fonctionnalités

Bthprops

Périphériques Bluetooth

Desk.cpl

Paramètres d’affichage

Firewall.cpl

Microsoft.WindowsFirewall

Pare-feu Windows Defender

Folders

Microsoft.FolderOptions

Options de l’Explorateur de fichiers

Fonts

Microsoft.Fonts

Polices

Hdwwiz.cpl

Microsoft.DeviceManager

Gestionnaire de périphériques

Inetcpl.cpl

Microsoft.InternetOptions

Options Internet

Intl.cpl

Microsoft.RegionAndLanguage

Options régionales et linguistiques

Joy.cpl

Microsoft.GameControllers

Contrôleurs de jeu

Microsoft.Keyboard

Propriétés du clavier

Main

Microsoft.Mouse

Propriétés de la souris

Mmsys.cpl

Microsoft.Sound

Son

Nusrmgr.cpl

Microsoft.UserAccounts

Comptes d’utilisateur

Powercfg.cpl

Options d’alimentation

Microsoft.DevicesAndPrinters

Périphériques et imprimantes

Sysdm.cpl

Propriétés système

Ncpa.cpl

Connexions réseau

Telephon.cpl

Options modems et téléphonie

Timedate

Microsoft.DateAndTime

Date et heure

Ups.cpl

Options d’alimentation

Wscui.cpl

Microsoft.ActionCenter

Sécurité et maintenance

Le panneau de configuration peut être utilisé en ligne de commande par l’intermédiaire de son application frontale (Control.exe) avec la possibilité de spécifier différentes options et paramètres. La syntaxe associée se présente sous une forme des plus classiques, soit control /[option] [paramètre].

GUID

Un GUID est une valeur hexadécimale sur 128 bits (ou 16 octets) dont l’unicité est garantie. De nombreux objets et ressources existants dans Windows disposent de GUID, y compris par exemple utilisateurs, groupes, ordinateurs, partitions disque, schémas d’alimentation, etc.

Par nature immuables, les GUID sont générés et associés à un objet au moment de la création dudit objet. Si l’objet change de nom ou de place au sein de sa hiérarchie, le GUID est conservé.

Polices et fontes

Dans la perspective typographique, une police de caractères, ou police d’écriture, est un ensemble complet de caractères déterminés par une forme (un dessin) homogène. Les imprimeurs utilisent le terme fonte en vue de désigner spécifiquement des tailles de points, poids, graisse et styles pour une police donnée. Par exemple, Arial est une police, Arial gras 12 point une fonte. Dans le domaine informatique, les deux termes sont souvent confondus et employés de façon interchangeable.

Il existe plusieurs types de polices :

  • Les polices TrueType s’affichent à l’écran telles qu’elles sont imprimées et dans toutes les tailles.

  • Les polices Open Type présentent les mêmes caractéristiques que les polices TrueType mais elles sont plus complètes et il est possible de les faire pivoter

  • Les polices Post Script, destinées aux professionnels, présentent une plus grande résolution à l’impression.

Au coeur de Windows

Une partie importante du contenu de ce livre provient d’observations concrètes menées à l’aide d’une approche par rétro-ingénierie du système d’exploitation. (La rétro-ingénierie informatique regroupe l’ensemble des méthodes et des moyens liés à la compréhension d’un système logiciel, sans le bénéfice des spécifications originales. Elle a pour but d’analyser un système pour en créer une représentation à un plus haut niveau d’abstraction.) Maints aspects internes de Windows peuvent être mis en lumière (et les agissements exposés) à l’aide de toutes sortes d’utilitaires, tels que les outils intégrés à Windows ou les outils de débogage fournis par Microsoft. La présente section va présenter brièvement ces ressources, et le parti que l’on peut en tirer.

Pour vous encourager à explorer par vous-même les coulisses de Windows, cet ouvrage propose de nombreux exercices et mises en situation qui décrivent comment faire pour procéder à l’investigation concernant telle ou telle facette du système, et qui servent à faire remonter en surface nombre d’informations utiles pour en comprendre la logique. (Notez, sur le plan de la présentation de l’information, que ces passages sont identifiés au moyen de l’étiquette prédéfinie En pratique, ou lorsque cela est plus pertinent, entrent naturellement dans le flux textuel.) Voir concrètement comment fonctionne Windows étant tout le propos de ce livre, nous vous nous ne pouvons que vous recommander la lecture de ces passages, et encore plus de reproduire les manipulations qui y figurent. (En un mot : faites ces exercices !)

Le tableau suivant énumère les principaux outils utilisés dans ce livre, en donnant leur provenance.

Table 7. Utilitaires de visualisation des coulisses de Windows
Utilitaire Nom de l’image Origine

Startup Programs Viewer

AUTORUNS

Sysinternals

Global Flags

GFLAGS

Debugging tools

Débogueur noyau

WINDBG, KD

Debugging tools, Windows SDK

Moniteur de performances

PERFMON

Intégré à Windows

Moniteur de ressources

RESMON

Intégré à Windows

Process Explorer

PROCEXP

Sysinternals

Gestionnaire des tâches

TASKMGR

Intégré à Windows

Build libre et build controlé

Chaque itération majeure de Windows s’inscrit dans un modèle général qui donne communément lieu à deux déclinaisons. L’une, appelée build libre, correspond à la version commercialisée normale de Windows ; l’autre, appelée build contrôlé, est une variante spéciale orientée débogage dudit logiciel. Destinée avant tout aux concepteurs de pilote, cette version se démarque essentiellement par les perspectives qu’elle offre sur le plan du suivi et de la validation des composants exécutés en mode noyau. Cela se traduit par un nombre important de mesures, tests, contrôles, et d’autres interventions du même style, qui sont appliqués de façon à améliorer l’identification et la résolution des problèmes de niveau système.

À la différence de son homologue utilisé en environnement de production (build libre), calibré pour les performances et en ce sens allégé de toutes les stratégies susceptibles de les impacter, le build controlé résulte d’un processus de compilation des sources Windows duquel éclos une variété de fonctions de débogage et de trace, y compris la génération de rapports d’erreur, la vérification des résultats d’une opération, la détection des erreurs de logique, ou encore la validation des paramètres transmis d’une routine à une autre. Parallèlement à cela, bon nombre d’optimisations de compilation sont dans le contexte du build controlé à l’état de sommeil, cela afin de faciliter l’étude du code machine. Il n’y a pas, par exemple, post-traitement des binaires à des fins d’exécution plus rapide.

Par nature, le build contrôlé impose des conditions drastiques et des régulations sévères aux fonctions appelées depuis les composants mode noyau du système. Ainsi, si un pilote fait un appel invalide à une routine système qui contrôle les paramètres (par exemple, lors de la réclamation d’un spinlock à un niveau d’interruption inapproprié), le système détecte qu’une erreur est sur le point d’être commise et empêche la requête d’aboutir. (En d’autres circonstances, l’opération aurait certainement été menée à terme, avec tous les risque d’effondrement ultérieur que cela implique. Même si ce point est de plus est de plus en plus discutable, Windows, dans sa configuration initiale, tend à faire aveuglément confiance à n’importe quel élément faisant partie de l’espace système.) Notez que la plupart des tests présents dans la version contrôlée afin de s’assurer de la justesse des valeurs alimentant tel algorithme ou telle structure de données reposent sur des scénarios éventuels. Il reste par conséquent envisageable qu’un paramètre se situe hors de la plage des valeurs considérées.

La déclinaison contrôlée de Windows emploie plusieurs méthodes de remontée des informations, parmi lesquelles la macro assert, les points d’arrêt et les messages de débogage. Toutes font intervenir la sortie de débogage afin de communiquer les résultat de leurs actions.

Une bonne partie des contrôles effectués dans le build controlé le sont par le biais de la macro assert, laquelle est communément utilisée afin de vérifier les hypothèses formulées depuis le code source d’un programme. Cette macro teste une condition (par exemple la validité d’un paramètre) ; si l’évaluation de l’expression retourne FALSE, cela donne lieu à l’appel de la fonction mode noyau RtlAssert, laquelle appelle DbgPrint pour envoyer le texte d’un message de débogage vers un tampon interne prévu à cet effet. Pour visualiser ces messages, vous pouvez soit attacher un débogueur noyau au système cible, soit employer la commande !dbgprint pendant une session de débogage local, ou encore utiliser l’utilitaire DbgView. La manière dont l’échec d’une assertion affecte le système dépend d’un certain nombre de facteurs. Dans les versions de Windows antérieures Windows Vista, si le système n’a pas été amorcé avec les options de débogage noyau et qu’aucun débogueur noyau n’est attaché, cela entraine automatiquement un effondrement du système (KMODE_EXCEPTION_NOT_HANDLED). Dans Windows Vista et versions ultérieures, si le système n’a pas été amorcé avec le débogueur noyau ou s’il n’y a pas de débogueur noyau actuellement attaché, l’échec d’assertion n’est pas signalé.

La plupart des conditions de point d’arrêt établies dans le build contrôlé le sont de telle manière à fournir un maximum d’informations sur les raisons pour lesquelles elles ont été rencontrées. Cela inclut des renseignements sur le problème qui est survenu, l’erreur qui s’ensuit, ainsi que sur la démarche ayant motivé l’interruption. Dans les rares cas où un point d’arrêt a été atteint sans qu’aucun diagnostic ne l’ai accompagné, un bref examen de la pile noyau (en utilisant par exemple la commande kb du débogueur) suffit en général à restituer avec exactitude les circonstances qui ont menés à cette situation.

Il n’est pas indispensable d’exécuter une installation complète du build controlé pour tirer parti de la version de débogage du système d’exploitation. Afin de nuancer les effets négatifs inhérents aux mesures opérationnelles intégrées à ce type de système (à savoir une forte empreinte sur les ressources machine et l’espace disque), Microsoft tient à jour une autre version parallèle, appelée build controlé partiel, dont la particularité est de ne comprendre que les versions contrôlées de l’image noyau et de la couche d’abstraction matérielle, tout le reste provenant la version commercialisée de Windows. Dans la pratique, une telle approche tend à combiner les avantages des deux environnements : rapide d’un côté, techniquement informatif de l’autre.

Le manque d’optimisation des binaires du build controlé, plus le fait qu’ils soit assujettis à des inspections minutieuses, rendent le système particulièrement moins véloce que sa contrepartie arrivant aux mains du grand public. Un tel phénomène peut ainsi dissimuler, ou au contraire mettre en évidence, des soucis de synchronisation multithread, fréquemment dus à des conditions de temporisation spécifiques. C’est la raison pour laquelle en effectuant vos tests sur la version contrôlée du système (ou au moins sur les versions contrôlées de l’image noyau et de la couche d’abstraction matérielle idoine), vous pourriez être surpris par des bogues n’apparaissant pas dans la version commercialisée. (S’il n’existe pas de barrage technique à faire exister et évoluer dans le build libre des contrôles aussi stricts que dans le build controlé, cela n’est pas réaliste du point de vue des performances.)

Vérification de la version (build) exécutée

La commande vertarget des débogueurs Windows standards permet de voir, entres autres informations, laquelle de la version de débogage ou de la version commercialisée est en cours d’exécution sur le système cible.

lkd> vertarget
Windows 8 Kernel Version 9200 MP (1 procs) Free x64

La propriété Debug de la classe WMI Win32_OperatingSystem indique TRUE s’il s’agit de la version contrôlée du système qui est exécutée, FALSE autrement.

Les informations présentées au niveau l’événement qui porte l’ID 6009, laquelle référence dénote que l’enregistrement a été créé au démarrage du système, incluent le type de l’image noyau qui a été chargée (mono processeur ou multi processeur, libre ou contrôlée).

DebugView

Compagnon d’aide idéal en matière de traque et de résolution des problèmes (troubleshooting) liés à la programmation, l’utilitaire DebugView permet de suivre en temps réel les informations de déboggage générées par les divers composants de Windows, incluant programmes en mode utilisateur et pilotes en mode noyau.

Flux de sortie de déboggage

Passerelles parmi d’autres entre le code machine et le développeur attaché à l’étude de celui-ci, Windows établit un certain nombre de flux au travers desquels les programmes peuvent faire entrer ou sortir des informations. L’un, consacré surtout à l’observation du comportement du système (pour voir s’il est conforme au comportement attendu), est le flux de sortie de débogage (debug output), lequel permet aux programmes d’émettre des messages d’erreurs et des diagnostics. Windows implémente ce canal sous forme d’un tampon interne, dont l’utilisation relie une source, un thread, à un destinataire, la plupart du temps un débogueur, mais il peut s’agir de tout autre outil externe avec suffisamment de contrôle pour afficher l’état et l’environnement de débogage.

Les programmes en mode utilisateur peuvent alimenter en informations la sortie de débogage au moyen de la fonction Windows OutputDebugString, laquelle relaie le contenu du message transmis comme paramètre vers le tampon interne. Pour les applications gérées, le framework .NET fournit les classes System.Diagnostics.Debug et System.Diagnostics.Debug, dont les méthodes passent la main à OutputDebugString. Notez que ces méthodes peuvent être sollicitées également depuis Windows PowerShell, par exemple :

[System.Diagnostics.Debug]::Print("Some debug output")

Les pilotes peuvent émettre des informations apparentées à la sortie de débogage en faisant appel aux routines DbgPrint ou DbgPrintEx. Les pilotes fonctionnant uniquement en mode noyau ont aussi à leur disposition un jeu de fonctions spécialement prévu pour les configurations de déboggage, constitué des macros KdPrint et KdPrintEx, qui sont sans effet dans un environnement de production.

Bien que Windows fournisse à la fois une version 8 bits (ANSI) et 16 bits (Unicode) de l’API OutputDebugString, respectivement OutputDebugStringA et OutputDebugStringW, toute sortie de débogage est traitée en interne selon le point de vue ANSI. En la matière, et en contrepied total du scénario classique des fonctions à double entrée, lorsqu’une application sollicite la version large de OutputDebugString (OutputDebugStringW), les chaînes en entrée sont converties en ANSI avant d’être traités par le système. Notez que cette conversion se faisant sur la base de paramètres régionaux, certains caractères peuvent ne pas s’afficher correctement.

Coup d’oeil sur l’interface DebugView

Comme la plupart des outils Sysinternals, DebugView ne requiert pas de processus d’installation, se rendant disponible pour l’exécution dès la fin du téléchargement. Vous pouvez également déclencher l’utilitaire directement à partir du site Web sans le télécharger. Le programme une fois lancé, DebugView démarre automatiquement la collecte des données significatives.

Ainsi que vous pouvez le voir au niveau de la figure suivante, les informations présentées par DebugView le sont sous forme de colonnes.

effe
Figure 1. Interface principale de DebugView

La première colonne affiche une liste de valeurs à partir de laquelle identifier un enregistrement de débogage parmi les autres. Notez que le schéma sur lequel DebugView se base pour attribuer à chaque enregistrement un numéro de séquence est interne à l’application, et ne fait donc sens qu’au sein de celle-ci. Les valeurs sont générées dans un ordre croissant, même si des écarts entre certaines peuvent apparaitre, du fait des conditions en place, règles de filtrage notamment.

La seconde colonne correspond à un point donné du traitement des messages de débogage et affiche le moment où chacun a été enregistré, soit en temps écoulé ou en temps réel. Par défaut, DegugView indique le nombre de secondes écoulées depuis la capture du premier enregistrement, avec l’élément initial positionné toujours sur une valeur nulle (0.00). Cela peut être utile pour résoudre des problèmes liés à des conditions de timing spécifiques, souvent la cause de bogues de synchronisation multithread. Ce compteur est remis à zéro chaque fois que l’affichage est actualisé. Si vos préférences se tournent vers un mécanisme d’horodatage, avec association d’une date et d’une heure à un événement, activez l’option Clock Time à partir du menu Options. Choisissez Show Milliseconds, toujours dans le menu Options, si vous souhaitez que l’horodatage tienne compte des millisecondes. Vous pouvez également configurer l’affichage de l’heure avec des options de ligne de commande : /o pour afficher pour afficher l’heure d’horloge, /om pour l’heure d’horloge avec millisecondes, et /on pour le temps écoulé.

La troisième colonne affiche la collection des sorties de débogage pour les composants cibles : programmes mode utilisateur, programmes mode noyau, éventuellement les deux. Lorsqu’un enregistrement concerne le flux de communication mode utilisateur, l’identifiant du processus (PID) duquel est issu l’opération de débogage apparait entre crochets, suivie de la sortie elle-même. Dans le cas où vous ne souhaiterez pas voir les données d’identification relatives aux processus, désactivez l’option Win32 PIDs à partir du menu Options. Par défaut, DebugView affiche le texte de chaque message passée à une fonction de sortie de débogage sur une ligne distincte, que ce texte se termine ou non par un retour chariot. Si vous désactivez l’option Force Carriage Returns du menu Options, DebugView laisse se déverser les divers enregistrements dans un tampon interne, pour ne l’afficher à l’écran que lorsqu’un retour chariot est rencontré, ou si la mémoire allouée pour ce tampon atteint une taille limite. Remarquez que cette méthode de présenter les données, avec laquelle applications et pilotes peuvent générer plusieurs lignes en sortie, ne convient pas en toutes circonstances. Elle exige en tout cas de l’analyste une certaine discipline, puisque dans cette configuration, si plusieurs processus génèrent des informations de sortie, les données se mélangent alors de manière confuse. De plus, le PID apparaissant à ce moment dans l’application identifie non le processus source du message, mais le processus ayant émis le texte comportant un retour chariot ou qui a rempli la mémoire tampon.

Les résultats des opérations de débogage sont ajoutés en fin de la liste au fur et à mesure que celles-ci se produisent sur le système. La fonction de défilement automatique de DebugView, faisant en sorte que les informations les plus récentes soient aussi celles immédiatement visibles, permet de naviguer facilement entre les diverses entrées. Pour basculer en mode défilement automatique, faites Ctrl+A ou sélectionnez l’icone Autoscroll dans la barre d’outils.

Pour finir, sachez si vous le désirez que DebugView peut être affiché en avant-plan de toutes les autres fenêtres d’application, de façon à toujours avoir un oeil sur les résultats. Pour ce faire, sélectionnez Always on Top à partir du menu Options.

Enregistrement du flux de sortie mode utilisateur

DebugView peut enregistrer l’actualité des diagnostics générés depuis plusieurs sources de données : la session de travail de l’utilisateur interactif, la session de console physique sur la machine (également appelée session 0), et le mode noyau. Chacun de ces foyers d’informations peut être sélectionné à partir du menu Capture. Une fois le mode de fonctionnement choisi, la capture peut être démarrée via l’option Capture Events du menu Capture, via les touches de raccourci Ctrl+E ou en cliquant sur l’icône Capture de la barre d’outils. Lorsqu’elle est active, la sortie de débogage est capturée à partir des sources sélectionnées.

Par défaut, DebugView collecte seulement les activités de débogage dans la session courante parmi les multiples sessions interactives possibles sur une même machine. Une session se compose des processus et des autres objets système (station fenêtre, bureaux et fenêtres) représentant la session de travail d’un utilisateur. L’option Capture Win32 du menu Capture et de la barre d’outils (touches de raccourci Ctrl+W) permet de voir les messages envoyés par les programmes mode utilisateur sur la sortie de débogage (fonction Windows OutputDebugString). Dans ce mode, des informations complémentaires relatives à l’identification du processus émetteur peuvent être demandées en sélectionnant l’option Win32 PIDs du menu Options.

En plus des fonctionnalités citées plus haut, en lien avec la session où un utilisateur exécute ses applications, DebugView permet également le suivi des opérations de débogage effectuées depuis la session globale, appelée aussi session 0, dans laquelle s’exécutent les services et où les objets de niveau globaux sont définis. L’élément de menu Capture Global Win32 fournit un tremplin vers l’activation/désactivation de l’enregistrement des données générés dans la session console. Notez que ce type d’action requérant de l’application l’élévation au statut d’administrateur, vous devez en conséquence disposer de droits d’accès appropriés pour utiliser cette option.

Capture du flux de sortie mode noyau

Au contraire de la plupart des outils du même style, lesquels ne permettent d’envisager que des scénarios de niveau applicatif mode utilisateur, DebugView permet en plus de surveiller le flux de sortie d’erreur apparenté au code mode noyau du système. Vous pouvez configurer DebugView pour afficher les résultats du débogage mode noyau en activant l’option Capture Kernel à partir de menu Options. Notez que cet usage requiert des droits d’administration, en particulier le privilège Load Driver.

Les composants s’exécutant dans l’espace noyau peuvent définir le niveau de gravité de chaque message qu’ils transmettent. Si vous souhaitez voir l’intégralité des sorties de débogage, choisissez l’option Enable Verbose Kernel Output dans le menu Capture. Quand cette option n’est pas activée, DebugView affiche seulement les messages dont le niveau de sévérité les classe comme erreurs.

S’il les en prive habituellement (mode par défaut), DebugView peut être configuré pour transmettre des résultats de débogage mode noyau à d’autres débogueurs. Pour activer ce mode, dit pass-through, activez l’option pass-through mode à partir du menu Capture ou cliquez sur l’icône Pass-Through dans la barre d’outils. Le mode pass-through vous permet de visualiser le contenu des informations de débogage dans un débogueur classique en meme temps que dans DebugView.

Contrôle à distance

Outre des procédures d’écoute relatives à la station de travail locale, DebugView dispose de fonctionnalités à distance qui le mettent en lien potentiel avec n’importe quelle machine du réseau. En ce sens, caractérisant une solution de visualisation intégrée et complète, l’utilitaire peut servir pour l’exploration de données en provenance de multiples sources, l’appareil local aussi bien que des ordinateurs distants.

Lorsqu’il est employé à des fins d’analyse dans un contexte autre que l’ordinateur local, DebugView s’exécute dans un mode de fonctionnement spécial, dit mode agent (agent mode), grâce auquel les enregistrements effectués par une instance de l’application sont relayés vers une instance centrale, cette dernière se chargeant seule de la présentation des données. Vous pouvez choisir de démarrer DebugView sur le système distant de manière manuelle ou automatique, moyennant dans le second cas la mise en conformité avec les normes et règles de sécurité de votre réseau.

Appuyez sur Ctrl-R ou choisissez l’option Connect du menu Computer pour ouvrir une boîte de dialogue via laquelle accéder à un autre ordinateur en réseau. Entrez le nom ou l’adresse IP de l’ordinateur distant, ou cliquez sur le bouton en regard de la zone de liste pour ouvrir la boîte de dialogue Rechercher un ordinateur. Dans la boîte de dialogue Rechercher un ordinateur, à l’aide du contrôle d’arborescence, recherchez l’ordinateur souhaité, puis cliquez sur OK. DebugView essaiera à ce moment d’installer et de démarrer un agent sur cet appareil ; s’il ne le peut pas, DebugView tente de se connecter à un agent déjà en cours d’exécution - cela supposant qu’un ai été démarré manuellement au préalable. Si une connexion est établie, DebugView affiche les données reçues depuis ce dispositif distant, en ajoutant le nom de l’ordinateur à la barre des titres et au menu Computer.

DebugView peut se connecter simultanément à un nombre quelconque de sources de données. Vous pouvez changer la visualisation de sorte à voir la sortie de débogage d’un ordinateur en le sélectionnant parmi la liste proposée par le menu Computer, ainsi que le montre la figure x. Vous pouvez également basculer entre plusieurs ordinateurs en appuyant sur Ctrl+Tab. L’ordinateur actif est signalé par l’affichage de son nom dans la barre de titre de l’application, et par une icône en forme de flèche dans le menu Computer. Notez qu’il est aussi possible d’ouvrir chaque ordinateur dans une fenêtre séparée.

Enregistrement et journaux

DebugView implémente pour la conservation (sauvegarde) des données sources une méthodologie à deux voies : l’enregistrement à la demande, et l’enregistrement séquentiel (journalisation). Dans les deux cas, les informations de débogage ainsi enregistrées le sont en tant que fichier texte (extension .log), ce qui signifie qu’elles peuvent être partagées, archivées, ou simplement conservées pour utilisation ultérieure.

Vous pouvez enregistrer le contenu de la fenêtre principale de DebugView en choisissant Enregistrer ou Enregistrer sous à partir du menu Fichier. Pour visualiser le fichier résultant, sélectionnez l’option Ouvrir du menu Fichier, ou spécifiez le chemin d’accès au fichier sur la ligne de commande.

Pour enregistrer les informations de débogage au fur et à mesure qu’elles apparaissent, choisissez au niveau du contrôle Fichier l’entrée de menu Log To File, ou cliquez sur le bouton de la barre d’outils. La première fois que vous faites cela après le démarrage de DebugView, une fenêtre de réglages apparaît, menant aux divers paramètres susceptibles d’être introduits ou modifiés. Ces derniers sont :

  • Emplacement du journal Désigne via le chemin d’accès un fichier à utiliser pour la sauvegarde. Lors du déploiement de contenus multiples, la partie de ce chemin menant au répertoire indique le dossier où iront se loger les fichiers résultants.

  • Taille de journal illimitée Permet au fichier de croitre sans considération de volume sur le disque, entendu que les restrictions à cet égard au niveau du système de fichiers restent évidemment en vigueur.

  • Créer un nouveau journal pour chaque jour Demande à DebugView de créer chaque jour un nouveau fichier pour le stockage du journal, avec la date du jour ajoutée au nom du fichier. Vous pouvez également sélectionner l’option pour effacer l’écran lorsque le journal pour une nouvelle journée est créé.

  • Limite de taille du journal Quand cette option est choisie, le fichier journal est contrôlée par une taille limite jusqu’à laquelle il peut s’étendre. Du moment que cette valeur est atteinte, deux situations sont envisageables, selon que l’option Wrap soit ou non de mise. Avec l’option Wrap, les données reçus après atteinte de la taille maximale sont renvoyés au début du fichier journal. Autrement, l’enregistrement s’arrête.

Du moment que des choix ont été faits pour un journal, l’option de menu Log To File, ainsi que le bouton caractéristique dans la barre d’outils, sert de relais pour l’activation et la désactivation du rôle enregistrement. Pour établir un fichier différent ou modifier d’autres paramètres, choisissez l’option Log To File As à partir du menu File.

Lorsque plusieurs ordinateurs font objet d’une surveillance et que la journalisation dans un fichier est en vigueur, l’ensemble des informations est consigné à l’intérieur d’un seul et unique fichier. L’empreinte de chaque système est néanmoins facilement distinguable, avec comme moyen de repère un entête donnant le nom de l’ordinateur à partir duquel plusieurs résultats ont été ont été enregistrées.

Handle

L’utilitaire Handle recense les descripteurs ouverts par les processus sur un système. Cela inclut les descripteurs de fichiers et de répertoires, mais également les ports de communication, les clés du Registre, les threads, et d’autres encore. Tous les objets visibles de l’API Windows sont concernés.

Handle dispose de deux modes d’échantillonnage, à quoi correspond dans un cas une utilisation du logiciel à des fins de consultation (visualisation de tous les descripteurs ouverts), et, second cas, pour un usage à des fins de recherche. Par défaut, la commande Handle liste les valeurs de tous les descripteurs associés à des fichiers, et les noms de ceux-ci.

Quand il n’est pas utilisé pour une recherche avec des critères précis, Handle organise les donnes en autant de sections logiques que de processus pour lesquels il montre les informations. Une ligne pointillée sert de séparateur, après laquelle se trouvent le nom et l’ID du processus. Sous ce nom est présenté la valeur du descripteur (en hexadécimal), le type de l’objet auquel le descripteur est associé et, s’il en a un, le nom de l’objet.

Tasklist

Tasklist affiche une liste des processus actuellement en cours sur un ordinateur local ou un ordinateur distant. Utilisable exclusivement à partir d’une invite de commande, le logiciel se révèle particulièrement utile pour les cas où, au cours d’une investigation sur un système, vous avez besoin de disposer d’informations sur les processus qui puissent être conservées et exploitées dans des scripts externes. L’utilitaire Tasklist est distribuée en standard sur chaque installation de Microsoft Windows, l’emplacement associé sur le système de fichiers étant \\Windows\System32.

Une particularité intéressante de TaskList se situe dans les options de mise en forme de la sortie, avec le choix entre une présentation sous forme de tableau, de valeurs séparées par des virgules (CSV, voir encadré plus loin) ou de liste. Le commutateur /fo reconnait pour l’occasion 3 valeurs : table, list, et cvs, qui s’illustre chacune dans l’exemple suivant :

Comma-separated values

Comma-separated values, connu sous le sigle CSV, est un format informatique ouvert représentant des données tabulaires sous forme de valeurs séparés par un caractère de séparation (virgule, point-virgule sous certaines localisations - dont le français, guillemet, etc.). D’abord essentiellement utilisé autour de logiciels tableur comme Microsoft Excel, le format, du fait d’être relativement simple à gérer, a par la suite gagné en popularité auprès de logiciels de toute sorte. Si CSV n’a jamais vraiment fait l’objet d’une spécification formelle, la RFC 4180 en décrit la forme la plus courante.

L’option /v (pour verbeux) affiche la plus grande quantité d’informations sur les processus, y compris le nom de l’image exécutée, le PID, le nom et le numéro de la session à laquelle appartient le processus, le nom d’utilisateur du contexte dans lequel le processus s’exécute, ainsi que le titre de la fenêtre (si le processus dispose d’une interface graphique).

La commande TaskList est utilisable avec une syntaxe (/s ordinateur) permettant d’obtenir l’état des processus d’un ordinateur distant. Deux commutateurs servent auquel cas à définir le contexte utilisateur sous lequel la commande doit s’exécuter : /u et /p, qui permettent de spécifier, respectivement, le nom d’utilisateur et le mot de passe à utiliser pour se connecter à l’ordinateur distant.

Utilitaires Sysinternals

Une bonne partie de la matière technique de ce livre provient d’utilitaires gratuits que vous pouvez télécharger depuis www.sysinternals.com (page qui vous redirigera sur http://technet.microsoft.com/sysinternals). Mark Russinovich, co-auteur des livres de la série Inside Windows, écrit la plupart de ces outils, d’abord de façon indépendante puis, Microsoft ayant acquis l’entreprise et ses actifs, conjointement au programme Microsoft TechNet.

Le site Web Sysinternals a été créé en 1996 par Mark Russinovich et Bryce Cogswell pour accueillir leurs logiciels de gestion, dépannage et diagnostic d’applications et de systèmes Windows, servant régulièrement à observer et à comprendre le comportement du système d’exploitation. Très appréciés des professionnels, nous ne pouvions manquer de donner à certains de ces utilitaires une mention spéciale. Les ressources disponibles sont classées en plusieurs grandes catégories :

  • Utilitaires de fichiers et de disques Utilitaires permettant de consulter et de surveiller l’accès et l’usage des fichiers et disques ; parmi lesquels Diskmon, qui capture toute activité du disque dur, et NTFSInfo, qui permet d’afficher des informations détaillées sur les volumes NTFS.

  • Réseau Outils réseau allant de moniteurs de connexion à des analyseurs de sécurité des ressources ; parmi lesquels PsFile, pour voir quels sont les fichiers ouverts à distance, et TCPView, qui affichera une liste détaillée de tous les points de terminaison TCP et UDP sur votre système, y compris les adresses locales et distantes et l’état des connexions TCP.

  • Processus et threads Utilitaires permettant de voir ce que font les processus et les ressources qu’ils consomment ; parmi lesquels Autoruns, indiquant quels programmes sont configurés pour démarrer automatiquement lors du démarrage du système, Process Explorer, dont nous avons déjà parlé, et la suite Tools, qui inclut des utilitaires de lignes de commande pour répertorier les processus exécutés sur des ordinateurs locaux ou distants, exécuter des processus à distance, redémarrer des ordinateurs, vider des journaux d’événements, entre autres.

  • Utilitaires de sécurité Utilitaires de configuration et de gestion de la sécurité ; parmi lesquels AccessChk, qui permet de visualiser le type d’accès à un objet que possède un utilisateur ou un groupe d’utilisateurs, ou LogonSessions, chargé de répertorier les ouvertures de session actives.

  • Informations système Utilitaires permettant d’examiner l’utilisation et la configuration des ressources système ; parmi lesquels ClockRes, qui affiche la résolution de l’horloge système, LiveKd, qui s’appuient sur le moteur de débogage de Windows pour examiner un système actif, Winobj, qui permet d’accéder aux informations du Gestionnaire d’objets, et DebugView, qui permet d’afficher en temps réel les opérations de débogage effectuées par les divers processus de votre système.

Configuration et utilisation des symboles

Qu’il s’agisse de déplomber des programmes ou analyser le comportement du système, l’étape de configuration des symboles est cruciale. Utilisés par les débogueurs pour référencer et afficher fonctions et variables, les fichiers de symbole contiennent pléthore de renseignements utiles, et constituent une aide précieuse pour fomenter des hypothèses crédibles sur les mécanismes internes de Windows. Dans cette section, nous discutons de la façon d’utiliser correctement les fichiers de symboles, et de découvrir leur importance pour le débogage.

Que sont les fichiers de symboles ?

Les composants de système informatique (applications, librairies, pilotes, systèmes d’exploitation, etc.) doivent pour apparaitre sous forme d’unités compréhensibles du processeur faire l’objet de procédures de compilation et d’éditions des liens. Celles-ci, en plus de construire les modules exécutables correspondants, créent un certain nombre de fichiers supplémentaires, connus collectivement comme les fichiers de symbole. Les fichiers de symboles contiennent une variété de données qui ne servent pas pour l’exécution du code, mais se révèlent fort pratique dans le processus de débogage. Voici en général ce que ce disent ces fichiers :

  • Les noms et adresses des variables globales

  • Les noms et adresses des fonctions et leurs signatures

Comme ils ne servent pas pour l’exécution, les symboles sont généralement séparés de l’image binaire de laquelle ils divulguent les informations. Cela rend les binaires plus petits et plus rapides. (Pour ce fait de rapidité, comprendre moins lourd à charger dans la mémoire.) En revanche, cela signifie que le débogueur puisse accéder aux fichiers de symboles associés aux images concernées par la session de débogage.

Pour diverses raisons, des problématiques de performance aux enjeux de la propriété intellectuelle, Microsoft a eu recours a plusieurs formats de symboles, dont COFF (Common Object File Format), CV (CodeView), et PDB (Program Database). Les versions récentes de Windows utilisent le format PDB.

Chemin des symboles

Le débogueur accède aux fichiers de symboles associés aux images concernées par la session de débogage en cours. Aussi, pour connaitre quels fichiers sont utiles, et lesquels ne le sont, le débogueur utilise deux types d’information : l’emplacement du chemin des symboles, représenté comme un ensemble de chemins d’accès, combiné avec les informations stockées dans les entêtes du module qui ont servi à valider les fichiers de symbole. Chaque chemin d’accès peut être représenté sous la forme d’un dossier local, un partage UNC, ou un serveur de symboles à la demande, comme décrit dans la section Serveur de symboles. Dans sa forme élémentaire, un chemin de symboles est une succession de chemin d’accès délimités par le caractère point-virgule (;). La commande. sympath (Set Symbol Path) modifie le chemin par défaut du débogueur hôte pour la recherche de symbole.

.sympath exe c:\sympath1 ; c:\sympath2

Outre les commandes de débogueur relatives au chemin des symboles, dont .sympath est la plus essentielle, le débogueur peut également être renseigné du même chemin d’accès via un couple de variables d’environnement système. Au démarrage, le débogueur interroge les emplacements définis dans _NT_ALT_SYMBOL_PATH et _NT_SYMBOL_PATH, généralement configurés par un fichier de commandes de débogage à l’aide de la commande SET. Par exemple :

set _NT_SYMBOL_PATH = c:\Sympath

Le chemin de symbole est créé par la concaténation des contenus de _NT_ALT_SYMBOL_PATH et _NT_SYMBOL_PATH, dans cet ordre. En règle générale, le chemin est défini par la seule variable _NT_SYMBOL_PATH. _NT_ALT_SYMBOL_PATH, s’il est facultatif, est utilisable dans divers cas particuliers, par exemple un qui aurait à négocier avec des versions privées de symboles partagés.

Une autre manière de configurer le chemin des symboles avant que naisse une instance de débogueurs est de le faire au moyen de paramètres d’entrée, à savoir le paramètre -y, que l’on ajoute à la commande d’appel. Par exemple :

C:\>windbg –y c:\symbols <image.exe>

Dernière méthode qui permette de configurer les symboles, aidée de la version graphique du débogueur. Dans l’espace de travail de WinDbg, cliquez sur File, sélectionnez Symbol File Path, puis indiquez le chemin des symboles.

Validation des symboles

Que le débogueur manipule des symboles corrects est un prérequis essentiel de toute activité de débogage. La première option est d’utiliser la commande lm (List Loaded Modules) qui, utilisée avec le paramètres l, Affiche seulement les modules dont les informations de symbole ont été chargé, et averti quand elles sont éronnées.

lkd> lm l
start             end                 module name
fffff802`e6a02000 fffff802`e714e000   nt         (pdb symbols)          c:\websymbols\ntkrnlmp.pdb\7B3C9BFCDF6643ABAACE89E4C9C333812\ntkrnlmp.pdb

Autre solution, inspecter les résultats de la commande .reload en mode verbeux.

lkd> !sym noisy
noisy mode - symbol prompts on
lkd> .reload nt
DBGHELP: nt - public symbols
         C:\WinDDK\7600.16385.1\Debuggers\sym\ntkrnlmp.pdb\7B3C9BFCDF6643ABAACE89E4C9C333812\ntkrnlmp.pdb

Le débogueur fournit en plus une commande d’extension qui puisse vérifier la validité du fichier de symbole par rapport au fichier d’image. La commande prend en entrée soit le nom du fichier image exécuté soit l’adresse à laquelle le fichier image est mappé en mémoire, et évalue la qualité des symboles. Par exemple :

lkd> !chksym nt

ntkrnlmp.exe
    Timestamp: 5165E551
  SizeOfImage: 74C000
          pdb: ntkrnlmp.pdb
      pdb sig: 7B3C9BFC-DF66-43AB-AACE-89E4C9C33381
          age: 2

Loaded pdb is c:\websymbols\ntkrnlmp.pdb\7B3C9BFCDF6643ABAACE89E4C9C333812\ntkrnlmp.pdb

ntkrnlmp.pdb
      pdb sig: 7B3C9BFC-DF66-43AB-AACE-89E4C9C33381
          age: 2

MATCH: ntkrnlmp.pdb and ntkrnlmp.exe

BCDEdit

Accompagnant la refonte de l’environnement de démarrage initiée avec la plateforme NT 6.0, l’utilitaire BCDEdit donne une vue sur le processus d’initialisation des systèmes Windows et ouvre la voie à différents scénarios le concernant.

Sur le plan fonctionnel, BCDEdit permet la configuration et le contrôle des fichiers de Données de configuration de démarrage (BCD, Boot Configuration Data), lesquels fournissent un magasin (store) servant à décrire les applications de démarrage et les paramètres de ces dernières. Les objets et les éléments contenus dans ce magasin remplacent à l’usage les fichiers Bootcfg.exe et Boot.ini des précédentes versions de Windows. BCDEdit peut être utilisé pour remplir de nombreuses fonctions, notamment pour créer de nouveaux magasins, pour modifier des magasins existants, pour ajouter des options de menu de démarrage, etc.

L’outil BCDEdit est fourni avec Windows dans le dossier %WINDIR%\System32 ; il n’est directement accessible que par le compte d’Administrateur principal de la machine ou par élévation des droits d’administration pour les autres comptes. Seul outil complet Microsoft à permettre d’entreprendre toutes les opérations de modification et de création de l’environnement de démarrage, BCDEdit reste limité aux types de données standard et est conçu essentiellement pour apporter des modifications courantes et peu nombreuses aux BCD. Pour des opérations plus complexes ou des types de données non standard, préférer WMI.

Gestion de l’ordinateur

La console Gestion de l’ordinateur centralise l’accès à un ensemble d’utilitaires majeurs liés aux tâches fondamentales d’administration des systèmes Windows, locaux ou distants.

Chacune des méthodes suivantes peut être suivie de sorte à afficher la console de gestion de l’ordinateur : (1) ouvrez le menu technique (Win + X) puis cliquez sur le menu Gestion de l’ordinateur ; (2) depuis le groupe de programmes Outils d’administration, effectuez un double clic sur le raccourci Gestion de l’ordinateur ; (3) cliquez sur Gérer à partir du Poste de travail ; (4) depuis une invite de commande ou le contrôle Exécuter, saisissez la commande compmgmt.msc. Étant donné les fonctionnalités qu’il englobe, vous devez disposer des privilèges d’administrateur local pour exploiter tout le potentiel de Gestion de l’ordinateur.

Les outils de la console Gestion de l’ordinateur sont classés en trois grandes catégories : Outils système, Stockage et Services et applications. La première de ces rubriques sert de passerelle d’accès vers des outils généraux d’administration, tels que le service Planificateur de tâches, l’Observateur d’événements, ou encore les Dossiers partagés. La rubrique Stockage ne contient qu’un seul utilitaire : Gestion des disques, lequel fait figure d’assistant multi-terrain pour tout ce qui concerne partitions et volumes. Enfin, la rubrique Services et applications concentre les propriétés et les réglages des services Windows, et le contrôle WMI. Pour plus de détails sur les différents logiciels que met à disposition la console Gestion de l’ordinateur, reportez-vous au premier chapitre, section Outils d’administration.

Une fois donné le départ à une console Gestion de l’ordinateur, vous êtes alors en mesure d’administrer l’ordinateur sur laquelle cette console s’exécute (remarquez la mention (Local) au niveau de la première ligne de l’arborescence). Il est cependant envisageable de se servir de cette même interface en vue d’administrer à distance une autre station de travail. Pour ce faire, sélectionnez la racine de la console Gestion de l’ordinateur (Local) puis le menu Action - Se connecter à un autre ordinateur (ou utilisez le menu contextuel). Dans la boite de dialogue nouvellement apparue, nommée Sélectionner un ordinateur, saisissez le nom pleinement qualifié de l’ordinateur concerné, ou utilisez le bouton Parcourir pour rechercher la machine que vous souhaitez gérer à distance, puis cliquez sur OK. Si la connexion est correctement établie, le nom complet de l’ordinateur apparait entre parenthèses à la racine de la console. Si vous êtes détenteur de privilèges administratifs locaux sur le poste distant, vous pouvez contrôler et agir sur tous les éléments de ce dernier, à l’exception des périphériques.

Utilitaire Configuration du système (Msconfig)

L’utilitaire Configuration du système donne accès à presque tous les paramètres de démarrage.

Les options de configuration mises en avant dans la fenêtre de Configuration du système se divisent en cinq grandes catégories.

  • Général Configuration générale de l’amorçage Windows : démarrage normal, en mode diagnostic (safe mode) ou sélectif.

  • Démarrer Options du chargeur d’amorçage. Cet onglet fait en quelque sorte figure d’interface graphique pour l’utilitaire Bcdedit.

  • Services Contrôle l’activation et le démarrage des services Windows. Il s’agit d’une version simplifiée de la console Gestion des services (services.msc).

  • Démarrage Permet de visualiser et de contrôler les logiciels s’exécutant automatiquement lors de l’ouverture d’une session utilisateur.

  • Outils Contient des lignes de commandes préconfigurées faisant miroir à diverses interfaces d’administration. Il ne s’agit pour la plupart que de raccourcis vers des éléments du Panneau de configuration.

Utilitaires d’administration

  • Contrôle WMI Permet de configurer et contrôler l’infrastructure de gestion Windows (WMI).

  • DiskPart Permet d’administrer disques, partitions et volumes depuis l’invite de commandes.

  • Dossiers partagées Permet de visualiser, créer ou supprimer des répertoires partagées ainsi que les sessions en cours et les fichiers ouverts.

  • Gestion de l’ordinateur Permet d’accéder à des outils majeurs d’administration du système, des services et du stockage.

  • Gestion des disques Permet de visualiser et modifier la structure des partitions et volumes des disques dont est équipé l’ordinateur. Pour en savoir plus, consultez le chapitre Gestion du stockage.

  • Gestionnaire des taches Permet d’afficher des informations d’utilisation concernant les ressources système.

  • Gestionnaire de périphériques Permet de contrôler l’ensemble des périphériques et pilotes de matériel associés. Pour en savoir plus, consultez le chapitre Système d’E/S.

  • Performances Permet de mesurer les performances du système et de connaitre les causes des problèmes éventuels à ce niveau.

  • Moniteur de ressources Permet d’afficher des informations d’utilisation détaillées concernant les ressources système.

  • Ordinateur Permet de visualiser rapidement les périphériques de stockage de la machine.

  • Observateur d’évènements Permet d’accéder à l’ensemble des journaux d’événements (liste d’avertissement et erreurs) de l’ordinateur local ou de la machine sélectionnée.

  • Planificateur de tâches Permet d’afficher, de créer et de gérer des tâches planifiées. Pour en savoir plus, consultez le chapitre Mécanisme de gestion.

  • Système Affiche des informations de base sur l’ordinateur (caractéristiques techniques) et le système d’exploitation utilisé.

  • Services Permet de gérer l’ensemble des services présents sur la station de travail. Pour en savoir plus, consultez le chapitre Mécanismes de gestion.

Variables d’environnement

Sous Windows, les variables d’environnement sont entourées du caractère « % ». Le tableau qui suit dresse la liste des principales variables d’environnement.

Table 8. Variables d’environnement

Variable

Description

%appdata%

Chemin d’accès au dossier contenant les programmes utilisateur (\Program Files par défaut)

%cmdcmdline%

Commande utilisée pour accéder à l’interpréteur de commandes (Cmd.exe)

%computername%

Nom de l’ordinateur

%date%

Date système

%errorlevel%

Code d’erreur de la dernière commande utilisée

%homedrive%

Lettre de lecteur identifiant le volume disque où le dossier de l’utilisateur courant est situé

%homepath%

Chemin d’accès au dossier de l’utilisateur courant

%number_of_processor%

Nombre de processeur présents dans l’ordinateur

%os%

Nom du système d’exploitation installé

%path%

Chemin d’accès des programmes système

%pathext%

Extensions considérées comme exécutables par le système

%processor_architecture%

Architecture du processeur

%random%

Entier choisi aléatoirement

%systemdrive%

Lettre de lecteur identifiant le volume disque où le dossier système (généralement C)

%systemroot%

Chemin d’accès au dossier racine du système

%temp%

Chemin d’accès au dossier temporaire pour les applications

%time%

Heure système

%userdomain%

Domaine auquel appartient le compte utilisateur courant

%username%

Nom de l’utilisateur courant

%userprofile%

Emplacement du profil utilisateur du compte courant

%windir%

Chemin d’accès au dossier Windows (généralement \WINDOWS)

Console Windows

La Console Windows est une forme d’interface utilisateur qui permet d’exécuter des logiciels conçus pour être pilotés à l’aide de commandes textuelles. Entrent dans cette catégorie, par exemple, les interpréteurs de commandes Cmd et Windows PowerShell, différentes commandes intégrées utiles pour l’administration du système, ainsi que pléthore d’utilitaires de gestion ou de diagnostic dédiés.

Chaque console Windows possède une mémoire tampon de sortie vidéo et une mémoire tampon d’entrée.

Dans la configuration par défaut, chaque processus exécutant une application fondée sur du texte a une console qui lui revient et à laquelle il est automatiquement associé. Les processus créées en tant qu’entités détachées (flag DETACHED_PROCESS de CreateProcess) ne s’accompagnent d’une console qu’à partir du moment où ils en créent une nouvelle (AllocConsole). Les applications dotées d’une interface graphique, par nature, ne présentent pas de lien avec une quelconque console.

Un processus peut être associé seulement à une console unique. De ce fait, toute tentative d’association d’une console à un processus échoue (fonction Windows AllocConsole) si ce dernier est déjà pourvu en la matière. Un processus peut utiliser la fonction FreeConsole pour se désolidariser de sa console actuelle, puis donner lieu pour son propre usage à une nouvelle console (AllocConsole) ou opter pour la mise en relation avec une console déjà existante (AttachConsole).

Le tableau qui suit énumère les fonctions utilisables pour accéder à une console.

Table 9. Fonctions de gestion de la console
Fonction Description

AddConsoleAlias

Définit un alias de console pour l’exécutable spécifié.

AllocConsole

Crée une nouvelle console pour le processus appelant.

AttachConsole

Rattache le processus appelant à la console à laquelle est associé un processus donné.

ReadConsole

Lit les caractères en entrée depuis le tampon d’entrée d’une console donnée.

SetConsoleCP

Définit la page de code en vigueur dans la console associée au processus appelant.

SetConsoleTitle

Définit le titre de la fenêtre console courante.

WriteConsole

Ecrit une chaîne de caractères dans le tampon de sortie d’une console donnée.

Observateur d’événements

Intermédiaire entre l’utilisateur et un panel d’actions (et de résultats de celles-ci) que consigne le système d’exploitation, l’Observateur d’événements est l’un des outils de diagnostic les plus vitaux de Windows. L’Observateur d’événements affiche des informations détaillées sur les événements significatifs de l’ordinateur, autant matériels (par exemple une défaillance dans un dispositif) que logiciels (par exemple un programme ne démarrant pas comme prévu), amenant l’outil à une place de choix pour contrôler la santé du système et régler les problèmes lorsqu’ils surviennent.

Accès à l’Observateur d’événements

Vous pouvez ouvrir l’Observateur d’événements à l’aide de l’une ou l’autre des méthodes suivantes.

  • Depuis le contrôle Exécuter ou une fenêtre d’invite de commandes, entrez eventvwr.exe ou eventvwr.msc.

  • Ouvrez la console Gestion de l’ordinateur (compmgmt.msc), développez Outils système et cliquez sur Observateur d’événements.

LiveKd

LiveKd permet d’utiliser les débogueurs noyau standard de Microsoft pour examiner un système au cours de son fonctionnement normal, sans être obligé de le préparer spécifiquement dans ce but (démarrage avec prise en charge du débogage noyau local, recours à un second ordinateur faisant office d’hôte, etc.).

LiveKd est compatible avec les versions x86 et x64 de Windows. Il a compte compte tenu des fonctions qu’il remplit besoin de droits administratifs, dont le privilège Déboguer des programmes.

Par défaut, LiveKd exécute le débogueur noyau ligne de commande (Kd). Pour exécuter le débogueur graphique (Windbg), spécifiez le commutateur -w. Pour exécuter un autre débogueur, spécifiez le commutateur -k. Des arguments de ligne de commande supplémentaires peuvent être fournis.

En interne, LiveKd s’appuie sur la mémoire physique en vue de simuler un fichier de vidange sur incident (dump), rendant de ce fait toutes les opérations autorisées dans ce contexte intelligibles auprès du débogueur. Procéder de la sorte n’est n’est cependant pas sans comporter quelque risque : le débogueur est-il ainsi susceptible de se trouver dans une situation où les structures de données sont en cours de modification par le système, et donc incohérentes. Chaque fois que vous sollicitez LiveKd, il commence par donner lieu à un nouvel instantané de l’état du système et démarre le débogueur pour lequel vous avez opté. Pour actualiser la vue, sortez du débogueur (commande "q"), qui vous demandera alors s’il doit redémarrer.

Driver Verifier

Une large majorité des problèmes susceptibles de frapper le bon fonctionnement du poste de travail sont issues de pilotes défectueux (mal conçus dès le départ ou mal entretenus par la suite). Partant de ce constat, Windows inclut un outil de dépannage puissant, appelé Vérificateur de pilotes, dont la principale fonction est de repérer parmi les actions des pilotes lesquelles sont de nature à compromettre la fiabilité du système, par exemple des appels de fonctions ou des accès mémoire illégaux.

Lorsque le Vérificateur de pilotes se trouve en face d’un comportement inapproprié, il crée de manière proactive une exception. Il devient ainsi possible d’analyser le fichier image mémoire généré et de la sorte découvrir le(s) pilote(s) auquel imputer l' anomalie.

Le vérificateur de pilotes est particulièrement impliqué dans la procédure d’amorçage du système, où il inspecte minutieusement chaque pilote. Il effectue en plus de cela la plupart des contrôles demandés par WHQL durant le processus de certification et de signature.

Systeminfo

L’utilitaire en ligne de commande Systeminfo affiche un résumé de la configuration matérielle et logicielle de l’ordinateur.

Pour exécuter Systeminfo, ouvrez une fenêtre d’invite de commandes, saisissez systeminfo et validez par l’appui de la touche Entrée. En plus du format liste, Systeminfo offre deux autres modes de présentation conçus pour faciliter la lecture et le traitement ultérieur des résultats : tableau et CSV. Pour utiliser l’un de ces formats, ajoutez le commutateur /Fo à la commande. Le cas échéant, redirigez la sortie vers un fichier de sorte à conserver une trace des informations recueillies. Par exemple, la commande systeminfo /fo csv > infos.csv génére une sortie CSV et l’enregistre dans le fichier infos.csv.

Le commutateur /S permet d’obtenir des informations système pour un ordinateur distant. Utiliser les commutateurs /U et /P pour fournir, respectivement, le nom d’utilisateur et le mot de passe d’un compte autorisé sur l’ordinateur cible.

Obtention d’informations avancées sur le système (Msinfo)

Pour obtenir des informations détaillées concernant le système local ou d’autres ordinateurs (station distante), utilisez Informations système (Msinfo32.exe). Toutes les statistiques de configuration fournies le sont par l’intermédiaire du service WMI.

Pour exécuter Informations système, dans une fenêtre d’invite de commandes ou le contrôle Exécuter, saisissez msinfo32. La fenêtre principale de l’application s’ouvre alors sur la page Résumé Système, laquelle centralise maintes informations : version exacte du système, processeur, version du BIOS, etc. La navigation parmi les informations système s’effectue de la même façon que dans l’Explorateur Windows ou dans une console MMC. Cliquez sur une rubrique dans le volet de gauche pour afficher le contenu associé dans celui de droite.

Les informations affichés dans Informations système se répartissent en trois parties majeures :

  • Ressources matérielles Fournit des informations détaillées sur les E/S, les requêtes d’interruption, les canaux d’accès direct à la mémoire (DMA) et les périphériques.

  • Composants Fournit des informations détaillées sur les composants installés , allant des codecs multimédia aux ports USB en passant par les périphériques d’entrée et la gestion réseau.

  • Environnement logiciel Fournit des informations détaillées sur la configuration courante du système d’exploitation.

Architecture du système

Est esquissée en filigrane de ce chapitre l’architecture générale des systèmes d’exploitation de la gamme Microsoft Windows. Après une vue d’ensemble sur le sujet, nous cheminerons parmi les objectifs posés par Microsoft lors de la conception du logiciel, avec dans ce contexte les définitions des besoins basiques ou fondamentaux ayant servi de cadre guide aux spécifications de Windows NT dès 1989. Vous verrez par ce biais comment la construction du système a intégré avec brio divers principes et, sur un plan plus actuels, de quelle façon les honorent les versions modernes de Windows. Nous montrerons les grandes lignes de la structure interne du système : les composants clé, leurs interactions mutuelles et leurs raisons d’être.

Souhaitant éveiller chez le lecteur un sentiment d’ordre général, notez que ce chapitre privilégie une vue globale du thème discuté, sans excès de précisions ou trop-plein de détails techniques. L’ensemble est pour cette raison jalonné de liens vers les contenus plus en profondeur de ce livre, eux-mêmes menant à une multitude d’observations directes du système. Cela étant dit, commençons notre exploration par une étude du modèle de conception général de Windows.

Architecture générale de Microsoft Windows

En dépit de la diversité des méthodes pour les envisager (conception) et les réaliser (implémentation), tous les produits et systèmes informatiques se classent parmi un nombre extrêmement restreint de styles architecturaux. (L’architecture logicielle à l’instar de l’architecture traditionnelle peut se catégoriser en styles.) Nous verrons ainsi dans cette section le style architectural avec lequel Windows a été élaboré, émergeant à cet égard comme réponse à un ensemble d’impératifs divers, autant technique que stratégique. Nous indiquerons en quoi l’approche choisie surpasse ou s’avère plus appropriée que les autres pour atteindre les objectifs fixés, et verrons comment elle marque son empreinte sur des facteurs importants de la dynamique du système d’exploitation.

Fichiers système fondamentaux

La liste suivante met en évidence quels sont les noms de fichiers associés aux composants fondamentaux de Windows. Chacun de ces composants sera traité en détail dans ce chapitre ou dans ceux qui suivent.

  • Hal.dll Couche d’abstraction matérielle.

  • Ntoskrnl.exe Exécutif et noyau pour les systèmes mono processeur.

  • Ntkrnlmp.exe Exécutif et noyau pour les systèmes multi processeur.

  • Ntkrnlpa.exe Exécutif et noyau avec prise en charge de L’extension d’adresse physique (PAE, Physical Address Extension) ; systèmes 32 bits uniquement.

  • Kernel32.dll DLL fondamentale du sous-système Windows.

  • Ntdll.dll Fonctions de support internes et et mécanismes de diffusion vers les services système.

  • Winlogon.exe Ouverture de session.

  • Csrss.exe Processus exécutant le sous-système Windows.

  • Gdi32.dll Fonctions liées à l’interface graphique.

  • User32.dll Fonctions liées à l’interface utilisateur.

  • Services.exe Processus exécutant le contrôleur de services.

  • Smss.exe Sous-système gestionnaire de session.

  • Win32k.sys Partie mode noyau du sous-système Windows.

Aperçu de l’architecture

Empruntant en la matière aux fonctionnalités de gestion des plateformes matérielles modernes, l’architecture de Windows s’articule autour de deux grands axes, et consiste ainsi donc de deux couches principales, l’une hébergeant les fonctions vitales du système d’exploitation (mode noyau), l’autre les programmes soumis à la supervision de ce dernier (mode utilisateur).

Comme mentionné au chapitre 1, les threads mode utilisateur sont exécutées dans un espace d’adressage de processus protégé, lequel les limite quant aux ressources auxquelles ils ont accès. Voici à quoi correspondent les quatre types fondamentaux de processus en mode utilisateur :

  • Processus de support système Les processus de support système offrent l’infrastructure pour le soutien des utilisateurs, de leurs données et de leurs programmes. Dès que Windows a fini de démarrer, un certain nombre de ces processus, tels le processus d’ouverture de session et le gestionnaire de session, sont actif, cela afin que le système d’exploitation puisse fonctionner et l’utilisateur interagir avec lui. (Notez que ces processus ne sont pas des services Windows, au sens qu’ils ils ne reçoivent pas de requêtes du gestionnaire de contrôle des services, mais sont démarrés par le système lui-même.)

  • Applications utilisateur Catalogue auquel s’intègrent les programmes des utilisateurs mais aussi divers programmes appartenant au système d’exploitation, les applications utilisateur s’exécutent en utilisant les services du système d’exploitation pour utiliser les ressources matérielles sous-jacentes. Bloc-notes (notepad.exe), célèbre éditeur de texte intégré à Windows, est un exemple d''application utilisateur ; Microsoft Word (winword.exe), Microsoft Excel (excel.exe), d’autres exemples. Windows divise les applications utilisateur en plusieurs catégories, cela en lien avec les fonctionnalités d’environnement du système d’exploitation : Windows 64 bits, Windows 32 bits, Windows 16 bits, MS-DOS 16 bits, POSIX 32 bits et OS/2 32 bits. (Notez que cette liste comprend des usages qui ne sont pas nécessairement couverts dans les versions modernes de Windows.)

  • Processus de service Les processus de service, analogues des démons d’UNIX, abritent des services Windows, un genre particulier de processus servant généralement à l’incorporation (démarrage, pause et arrêt) de taches d’arrière-plan, ou qui doivent pouvoir être exécutées indépendamment des ouvertures de session des utilisateurs (non liés à l’utilisateur interactif donc). Le planificateur de taches, le spouleur d’impression, et bien d’autres logiciels sont mis en oeuvre en tant que services, ou contiennent des fonctionnalités exécutées à l’intérieur de tels entités.

  • Processus serveur de sous-système d’environnement Implémentent une partie (l’autre partie étant constitué de services système en mode noyau) des fonctionnalités d’environnement du système, lesquelles donnent aux programmes des utilisateurs un contexte d’exécution adéquat (une application Windows 64 bits ne s’exécute pas de la même façon qu’une application Windows 32 bits, et encore moins qu’une application basée MS-DOS fondée sur du texte), met entre les mains des concepteurs d’application un ensemble de méthodes et de modèles à programmer, et donne au système d’exploitation sa personnalité graphique. Pour plus d’informations, consultez la section sous-systèmes d’environnement de ce chapitre.

Au contraire de la plupart des systèmes d’exploitation, qui donnent une proximité immédiate aux fonctions primitives fournies par le noyau et utilisées par les programmes s’exécutant dans l’espace utilisateur (appels système), les applications utilisateur sous Windows ne sollicitent pas directement les services natifs du système ; elles passent plutôt une ou plusieurs bibliothèques de liens dynamiques (DLL, Dynamic Link Library) qui, apparentées à un processus serveur de sous-système d’environnement, délivrent l’interface de programmation de ce système. Le rôle de ces DLL est de traduire l’appel d’une fonction en une requête vers le service système interne appropriée de Windows. Par exemple, les fonctions internes du processus du sous-système Windows sont rendues visibles aux programmes par des interfaces de programmation mises en œuvre par des fichiers DLL. Les trois principales bibliothèques sont User32.dll (manipulation de l’interface utilisateur), GDI32.dll (manipulation des dispositifs d’impression et d’affichage), et Kernel32.dll (utilisation des services concernant les processus et les threads, les fichiers, et autres).

Voici à quoi correspondent les quelques composants logés dans la portion système de Windows, exécutés en mode noyau :

  • Exécutif L’exécutif Windows met en œuvre les services système fondamentaux, tels la gestion de la mémoire, la gestion des processus et des threads, la sécurité et les E/S.

  • Noyau Le noyau Windows contient les fonctions système de bas, par exemple l’ordonnancement des threads, la gestion et la répartition des interceptions (trappes, interruptions et exceptions), et la synchronisation multi processeur. Il fournit également un ensemble de routines basiques et de structures de données élémentaires que les autres modules de l’exécutif peuvent invoquer.

  • Couche d’abstraction matérielle La couche d’abstraction matérielle isole le noyau, les pilotes de périphérique et les services de l’exécutif des spécificités de la plateforme.

  • Pilotes de périphérique Les pilotes de périphérique permettent aux applications de disposer d’une interface vers le système d’entrée/sortie de Windows.

  • Système de fenêtrage et de graphisme Le système de fenêtrage et de graphisme réalise les opérations liées aux dessins des interfaces utilisateur graphique.

Approche en couches

Windows adopte un mode de fonctionnement orienté selon deux grandes lignes de force : l’approche par couche, dans laquelle le système d’exploitation comprend un certain nombre de divisions, et l’orientation objet, où chaque entité du système informatique, physique ou virtuelle, est représentée comme une combinaison de propriétés, de caractéristiques et d’états dans le système.

La division en couches consiste à regrouper les composants possédant une sémantique semblable (ou au moins analogue) de manière à créer un empilement de paquetages de composants ; les composants des couches supérieures dépendants fonctionnellement des composants des couches inférieures. Chaque couche dans cette perspective se superpose à une autre en apportant à l’ensemble de nouvelles fonctions plus élaborées, et reposant sur les fonctions plus élémentaires assurées par les couches sous-jacentes. La couche la plus basse d’un système d’exploitation est le matériel ; la plus haute, par conséquent la plus éloignée des rouages et des procédures bas niveau du système, est l’interface utilisateur.

Une couche est l’implémentation d’un objet abstrait qui encapsule des données et des opérations relatives à l’interaction avec ces données. Dans Windows, toutes les ressources partageables sont représentées par des objets : les processus, les threads, Les fichiers, les dispositifs physiques, les pilotes, et bien d’autres.

Le principal bénéfice à l’utilisation de l’approche en couches est la modularité́, définie en génie logiciel comme le fait, pour un programme, d’être écrit en plusieurs parties relativement indépendantes les unes des autres. Les couches sont sélectionnées de telle sorte que chacune utilise seulement les dispositifs de programmation fournies par les couches de niveau inférieure. Ainsi, chaque couche peut individuellement être vérifiée. Quand la première couche fonctionne correctement, la seconde peut être inspectée, et ainsi de suite. Si une erreur est trouvée au cours du débogage d’une couche, il est légitime de penser que la faute est imputable, à cette couche, et uniquement à elle. (Au-delà du fait que probable ne veut pas dire certain, la complexité d’un système tel Windows peut mener dans l’analyse à de fausses conclusions.) En découpant le système en couches, on facilite par ce biais sa conception, sa réalisation, sa validation et sa maintenance.

L’abstraction est un autre avantage que procure l’approche en couches, cela dans la mesure où toutes se séparent de façon indépendante les unes des autres. Par définition, les opérations implémentés dans une couche le sont en faisant abstraction de l’implémentation de ces opérations dans les couches inférieures. Les éléments d’une couche, des objets, n’ont aucune connaissance de comment sont constitués les autres, et c’est uniquement à travers des interfaces bien définies et un modèle sémantique affirmé que les objets ont la possibilité d’agir entre eux. Chaque couche masque donc l’existence de certaines structures de données, d’opérations et de matériels aux couches supérieures.

Objectifs de conception

Un projet de l’envergure de Microsoft Windows revêt de multiples dimensions et couvre de nombreuses exigences de différents caractères. (Notez, sur la nature et la teneur des difficultés à satisfaire pléthore de contraintes, que ce n’est pas tant la multiplicité des composants, mais la diversité de leurs interrelations, qui caractérisent le plus la complexité, d’autant plus que certaines exigences sont antagonistes. Le résultat final, autrement dit le logiciel tel que nous le connaissons, est par conséquent un compromis entre des conditions générales commandées par les circonstances.) Afin que l’éventail des moyens résultants puisse être intégré de façon harmonieuse, les concepteurs de Windows NT adoptèrent les objectifs de conception suivants :

  • Compatibilité Le système devait être capable d’exécuter les applications existantes développées pour les anciennes versions de Windows (gamme 16 bits) et pour MS-DOS. Il devait aussi pouvoir interagir avec d’autres systèmes comme UNIX ou OS/2.

  • Extensibilité Le système devait pouvoir s’adapter en douceur aux évolutions matérielles et aux évolutions des besoins.

  • Fiabilité et robustesse Le système devait savoir se protéger contre les dysfonctionnements internes et contre les altérations externes. Les applications ne devaient pas pouvoir nuire au système d’exploitation ni aux autres applications.

  • Performance Le système devait répondre rapidement aux tâches demandées, être aussi rapide et réactif que possible sur chaque plateforme matérielle.

  • Portabilité Le système devait pouvoir fonctionner sur différentes architectures et plateformes matérielles. Le support d’une nouvelle architecture devrait pouvoir être intégré sans effort rédhibitoire.

Fiabilité et robustesse

Premier éditeur mondial de logiciels et de solutions d’entreprise, Microsoft véhicule avec ses gammes de systèmes d’exploitation des années d’histoire et de progrès technologique (Windows 1.0, sortie en 1985, est l’aboutissement de quatre années de développement interne.) Cette longévité remarquable s’explique, en partie au moins, par l’enracinement dans Windows des objectifs et qualités requises en terme de fiabilité et de robustesse.

  • Protection contre les applications problématiques Windows exploite une architecture mémoire autorisant une protection complète des divers codes s’exécutant sur le processeur. Le code du système d’exploitation est exécuté dans un mode privilégié du processeur (mode noyau), avec accès complet aux données, aux instructions et au matériel. Le code des applications est exécuté dans un mode non privilégié (mode utilisateur), avec accès limité au code et aux données de la partie privilégiée. Cette protection est l’une des raisons pour lesquelles les composants de Windows sont protégés contre les applications, et les applications contre les agissements potentiellement nuisibles (que ces derniers soient intentionnels ou accidentels) d’autres applications.

  • Restauration système La fonctionnalité Restauration du système permet à un administrateur de poste d’enregistrer diverses informations cruciales pour Windows, essentielles à la bonne marche du système informatique. Un mécanisme de points de restauration permet de maintenir à jour les éléments récupérés. A l’installation de certains composants, ou autres changements de la configuration, Windows crée un point de restauration pour, en cas de problèmes, être en mesure de revenir à l’état initial du système avant prise en compte des modifications.

  • Maturité du code source Riches de pratiques et de savoirs faire en constante amélioration, les diverses versions de Windows fournissent l’assurance d’une qualité logicielle maitrisée et régulière. Avec en parallèle de l’évolution du système d’exploitation la professionnalisation des métiers du test informatique, et partant l’industrialisation de leurs processus, Microsoft utilise une revue intensive du code, l’objectif étant, sur la base de vérifications automatiques et manuelles, d’identifier les fichiers sources pouvant contenir des problèmes, cela afin d’améliorer la fiabilité (qualité et sécurité) du logiciel.

  • Capacités de résistance Windows est soumis à des essais extensifs en condition de stress (stress testing), destinés à évaluer la robustesse du système dans des conditions de fonctionnement sévères ou inhabituelles (ressources mémoire venant à manquer, espace disque insuffisant, conditions de concurrence anormalement élevées, etc.). Le système a été testé dans les conditions d’usage les plus difficiles et montré ses capacités de résistance. 

  • Système de fichiers NTFS Si quantité de biens numériques lui sont confiés (programmes et données personnelles de l’utilisateur, processus et logiciels métiers, et bien d’autres), Windows le doit en ce qu’il s’appuie sur un système de fichiers robuste et moderne, NTFS (NT File System), lequel inclut en standard des fonctions relatives à la protection et à la sécurité des données. Dans la perspective NTFS, toutes les informations d’opérations exécutées sur le disque sont enregistrées dans un fichier journal. En cas de problème, NTFS utilise ce journal pour restaurer l’unité en panne. De plus, NTFS n’enregistre pas une quelconque action avant de s’être assuré que celle-ci s’est correctement déroulée (principe des transactions), cela en vue de garantir l’intégrité des données en cas d’arrêt brutal du système d’exploitation (coupure d’alimentation, effondrement du système, etc.).

  • Fiabilité perçue de l’interface graphique utilisateur Windows étant du point de vue de l’utilisateur un système d’exploitation essentiellement graphique, la fiabilité perçue du logiciel, estimée selon les critères de l’utilisabilité (voir note plus bas) est également améliorée en rendant l’interface utilisateur plus facile à utiliser de par une meilleure ergonomie, des menus plus simples et divers perfectionnements dans la découverte intuitive de comment effectuer les tâches courantes. Exemple de fiabilité perçue, l’environnement personnalisé : Windows tient compte des habitudes de l’utilisateur pour construire dynamiquement une interface graphique façonnée selon l’activité antérieure; ainsi, les applications les plus utilisées sont mises en valeur, les autres objets mis au second plan.

  • Redémarrage automatique des composants en erreur Windows intègre la capacité de relancer automatiquement les composants du système d’exploitation qui auraient cessé de fonctionner. De plus, le système consigne dans plusieurs emplacements du système de fichiers (journaux, Registre, etc.) les raisons pour lesquelles un composant est défectueux non conforme à une commande donnée, ou susceptible de provoquer une situation non attendue. Divers utilitaires accompagnent cette démarche, par exemple l’Utilitaire de résolution des problèmes, qui recherche les problèmes courants et vérifie que tous les nouveaux périphériques et matériels connectés à l’ordinateur se comportent correctement.

  • Vérificateur de pilotes (et consorts) Les systèmes Microsoft intègrent une gamme d’outils, standards ou optionnels, via laquelle améliorer la stabilité du système d’exploitation et déterminer la qualité des composants sur le plan des fonctionnalités. À titre d’exemple, les utilisateurs (les plus techniques, concédons-le) peuvent utiliser la fonctionnalité d’évaluation des pilotes pour vérifier qu’un système d’exploitation Windows en cours d’exécution contient le bon ensemble de pilotes, et par voie de conséquence repérer ceux potentiellement à problème. Un administrateur sera de cette façon capable d’identifier précisément et immédiatement les pilotes susceptibles provoquer l’instabilité de l’ordinateur, au lieu de devoir se contenter d’indices éventuellement trompeurs obtenus après-coup l’effondrement du système. (Le dysfonctionnement d’un composant en mode noyau de Windows est la source la plus répandue de défaillance système.) Dans un autre registre, mais toujours au chapitre de la fiabilité et de la robustesse du système d’exploitation, divers utilitaires sont incorporés à Windows dans le but de surveiller la bonne marche des processus et des services (Gestionnaire de tâches), de juger de la disponibilité des ressources (Moniteur de ressources), d’examiner la manière dont l’exécution des programmes affecte les performances de l’ordinateur (Moniteur de fiabilité et de performances), et bien d’autres usages.

  • Protection des fichiers Windows Les fichiers système critiques de Windows sont protégés en étant sauvegardés automatiquement ; lorsqu’un tel fichier est modifié ou est supprimé accidentellement, Windows le remplace par une copie valide. La protection de ces fichiers permet d’éviter des problèmes au niveau des programmes et du système d’exploitation. Le chapitre Mécanismes système revient plus en détail sur la fonctionnalité Protection des fichiers Windows.

Haute performance

Importante, déjà, en ce qui concerne des logiciels de moindre ampleur, la question de la performance d’un système informatique est centrale quant à son adoption et à son utilité. Microsoft Windows fut ainsi conçu pour offrir de hautes performances pour les systèmes de bureau, les systèmes serveur, terminaux mobiles, et pour les grands environnements multithreadés et multiprocesseurs.

Sur le plan de la langue, le terme performance n’a pas la même connotation compétitive en anglais qu’en français. Au sein d’un contexte francophone, la notion se réfère ainsi le plus souvent à une représentation subjective de la réussite, ou du moins aux voies d’accès à celle-ci. En anglais, le terme performance peut désigner l’action elle-même, une acceptation qui renvoie donc dans ce cas à un processus, sans forcement être synonyme de bons résultats.

La notion de performance apparaît de façon explicite dans de nombreux procédés mis en avant par Windows :

  • Entrées/sorties asynchrones Les E/S asynchrones permettent à une application d’émettre une requête d’E/S, puis de continuer à travailler pendant que le périphérique effectue les traitements impliqués (moyennant quoi le thread applicatif doit synchroniser son exécution avec l’achèvement de la requête).

  • Mise en cache sophistiquée de données du système de fichiers Le gestionnaire de cache de Windows utilise une méthode basée sur les blocs virtuels (par opposition à un cache basé sur des blocs logiques), qui permet des lectures anticipées intelligentes (il peut prédire l’endroit où l’appelant risque de faire la lecture suivante) et des accès haut débit au cache.

  • Mise en lot des requêtes Le cache Windows fait de la régulation des écritures : on laisse un temps s’accumuler dans le cache les modifications adressant l’intérieur de fichiers (on met autrement dit en lot les E/S sous-jacentes) avant de les écrire toutes en une seule fois sur le disque. Cette gestion rend possible de s’abstraire des limites et contraintes inhérentes au matériel disque, et favorise la réactivité d’ensemble de l’environnement.

  • Considérations matérielles Windows emploie pour ses techniques de gestion mémoire et mémoire cache le principe de localité (utilisation des instructions et données situées dans la zone mémoire proche des données et instructions accédées récemment, localité spatiale ; réutilisation des instructions et donnes utilisées dans le passé, localité temporelle). L’algorithme afférent tient compte, et s’adapte en fonction, des spécificités matérielles impliquées dans ce principe (taille de page, taille des lignes de cache, etc.). Le code de gestion des interceptions profite s’il est présent du dispositif appel système rapide, alternative moins coûteuse que les interruptions dans le domaine. En matière de verrouillage et synchronisation, les codes d’acquisition et de libération sont optimisés en langage bas niveau, à la fois pour des raisons de vitesse (performance) et pour pouvoir bénéficier des installations offertes par l’architecture processeur sous-jacente. Ce sont là divers exemples montrant comment, à partir de considérations faites sur le matériels, Windows développe, enrichit et rend optimal ses stratégies d’exploitation.

  • Protocoles de verrouillage extensibles et à faible granularité Les mécanismes de synchronisation offerts par le noyau sont implémentés sous forme de primitives extensibles. Les besoins en la matière étant multiples, plusieurs jeux de fonctions coexistent, conscients qu’à chaque situation de synchronisation correspond une réponse appropriée. Par exemple, là où des spinlocks ordinaires conviendraient peu (le terme spinlock vient du fait que le noyau « boucle » (spins) jusqu’à ce qu’il ait le verrou), vous pourriez utiliser des spinlocks en file (qui offre une meilleure évolutivité) ; et s’ils ne convenaient pas du tout des pushlocks, des mutex, des ressources éxécutif, etc.

  • Système de priorités adaptatives Windows emploie pour l’ordonnancement des tâches un modèle piloté par priorités : les threads peuvent être préemptés par d’autres threads de priorité supérieure. Le système peut en conséquence répondre rapidement à des événements extérieurs, favoriser ou au contraire défavoriser certains éléments de l’exécution.

  • Optimisation Quand bien même C et C++ restent favoris partout ailleurs, parce que gage de portabilité, c’est l’assembleur qui est utilisé lors de procédures sensibles en matière de performances. On trouve de l’assembleur dans le code de gestion des appels système, dans la réalisation de certains protocoles de verrouillage, et même dans certaines bibliothèques mode utilisateur.

  • Mécanisme LPC LPC (Local Procedure Call) est une technologie de communication inter processus pour transmission rapide de messages entre processus d’un même environnement (sur le même ordinateur). Sollicité intensivement dans la communication vers et depuis les sous-systèmes internes de Windows, les mécanismes LPC font beaucoup pour la réactivité du système, et s’utilisent dans des endroits des plus critiques, tels que par exemple le processus serveur d’authentification de sécurité locale, le gestionnaire de session ou celui des services.

  • Graphiques gérés par le noyau Avant Windows NT 4, routines d’interface utilisateur et code graphique (gestionnaire de fenêtres et services de graphisme donc) étaient exécutés dans le contexte d’un processus mode utilisateur. Par la suite, l’essentiel de ce que réalisaient ces éléments fut déplacé dans le noyau (dans le fichier Win32k.sys). On réduisait ce faisant le nombre de basculements de contexte vers un processus serveur séparé, opération coûteuse en cycles processeur et ressources mémoire, et améliorait alors les performances globales du système.

  • DirectX Collection de bibliothèques destinées à la programmation d’applications multimédia sur les plates-formes Microsoft (Xbox, Windows), DirectX offre de hautes performances graphiques pour les ordinateurs personnels. La technologie DirectX permet un gain de rapidité en accédant directement au calculateur 3D des cartes graphiques modernes, et à toutes les versions de Windows depuis Windows 95 de bénéficier de capacités multimédia performantes.

  • SuperFetch Destinée à améliorer les performances de démarrage et le temps de réponse des applications, la fonction SuperFetch permet, selon une analyse des activités passées de l’ordinateur, de pré charger en mémoire les composants les plus sollicités, donc les plus susceptibles de l’être encore. Par exemple, dans le cas d’une utilisation bureautique poussée, SuperFetch détectera un recours intensif à Microsoft Word et Microsoft Excel (en supposant bien sûr une préférence pour ces produits) et chargera automatiquement en mémoire les divers modules relatifs aux processus exécutant ces programmes.

Internationalisation

Conçu pour une utilisation sur le territoire mondial, où de multiples langues, cultures et singularités coexistent, Windows définit compte tenu de ces particularités divers mécanismes pour la prise en compte de l’internationalisation et de la régionalisation, deux parties d’un même ensemble visant à permettre à une application de présenter son contenu dans des langues et des formats adaptés à ses utilisateurs. (Pour plus d’informations sur ces sujets, voir encadré plus loin.)

Parmi les mesures grâce auxquelles Windows s’adapte facilement à différentes langues et cultures :

  • Support des Langues Nationales L’API de support des langues nationales (NLS, National Language Support) héberge divers services internationalisés pour ce qui est de la langue, de la culture et des conventions écrites. L’architecture NLS permet de sauvegarder et manipuler les données en fonction de paramètres de langue préconfigurés. Elle assure que les programmes, messages d’erreur, ordre de tri, date, heure, monétaire, numérique, et calendrier s’adaptent automatiquement aux paramètres préconfigurés de la langue et locale. Elle fournit également le support pour les dispositions de clavier (keyboard layouts) et des polices spécifiques à une langue.

  • Unicode Pour répondre à l’hétérogénéité des différentes représentations de données, Windows utilise Unicode, un format spécial permettant des échanges de textes dans différentes langues, à un niveau mondial. Les applications Windows sont totalement compatibles Unicode, ce qui signifie que chaque caractère est représenté par un nombre unique, indépendamment de la plateforme, du programme ou de la langue. Codage de caractères natif de Windows, Unicode est l’un des moyens par lesquels le système a pu s’exporter facilement, et s’imposer sur le marché international. Pour de plus amples informations sur Unicode, consultez la section Unicode (chapitre 1).

  • Fichiers ressources Les chaines de texte système, plutôt que d’être déclarées de façon statique (autrement dit codées en dur), sont conservées dans des fichiers ressources qui peuvent être remplacés de sorte à adapter l’environnement à différents langages. Un certain nombre de variables liées au pays ou à la culture d’appartenance sont établies relativement à ces aspects, cela afin de mieux correspondre aux préférences des individus ou groupes d’individus multilingues.

Internationalisation et régionalisation

Les définitions en ce qui concerne l’internationalisation et la régionalisation varient. Ici, nous offrons quelques descriptions de niveau général sur la façon dont ce livre a tendance à utiliser ces termes.

L’internationalisation (souvent abrégé en i18n - la lettre initiale i du mot internationalization suivie du nombre de lettres intermédiaires et le tout terminé par un n final) est un terme général faisant référence au fait de préparer un logiciel afin qu’il puisse s’adapter à des langues et à des cultures différentes. Une des techniques de base de l’internationalisation consiste à séparer, dans le code source d’un programme, ce qui est indépendant de la langue et de la culture de ce qui en est dépendant ; cela, généralement, dans des fichiers séparés, qui pourront alors être traduits sans devoir modifier le code de ce programme.

La régionalisation est l’adaptation d’un logiciel à destination d’une culture, ou d’une langue particulière. Le terme localisation (l10n), transposition du faux ami anglais localization, est souvent utilisé. La régionalisation implique principalement la traduction de l’interface utilisateur d’un logiciel , mais elle ne se limite pas à cet aspect, puisque l’adaptation peut également concerner les attentes culturelles et linguistiques propres à la langue et au pays de l’utilisateur, par exemple la représentation des chiffres, le type de virgule, l’utilisation judicieuse de couleurs et de symboles adaptés à la culture cible, les différentes lois et réglementations dans le pays visé, etc. avant qu’un logiciel ne soit régionalisé, il faut qu’il ait été internationalisé, c’est-à-dire qu’il ait été écrit pour pouvoir être traduit. A cet égard, plus L’internationalisation est bien conçue, plus la régionalisation est techniquement facile à effectuer. Le consortium Unicode travaille sur une normalisation de ces paramètres régionaux, le projet Common Locale Data Repository.

Extensibilité

L’extensibilité fait référence à la capacité d’un système d’exploitation à suivre les avancées technologiques, tant en matière de dispositifs physiques que relativement aux infrastructures et solutions logicielles. Les mesures influentes en ce domaine visent, sur le plan structurel, à permettre l’introduction facile de nouvelles fonctions et l’évolution en douceur des existantes. Celles-ci incluent :

  • Structure modulaire Afin que les changements futurs soient facilités, Windows a été conçu selon des principes modulaires qui ouvrent la voie à la greffe de nouvelles fonctions et au remplacement de certaines par d’autres plus évoluées. L’exécutif Windows fonctionne en mode noyau ou protégé et offre les services système fondamentaux, par exemple la gestion des processus (gestionnaire de processus) ou l’ordonnancement des threads (noyau). Chaque composant au sein de la couche exécutive communique avec un ou plusieurs de ses homologues via les interfaces de programmation adéquates. Au-dessus de la couche exécutive, plusieurs sous-systèmes serveur s’exécutent en mode utilisateur. Parmi eux se trouvent les sous-systèmes d’environnement, lesquels agissent comme support pour les programmes Windows et les programmes écrits pour d’autres systèmes d’exploitation, tels MS-DOS ou UNIX. Grâce à cette structure modulaire, de nouvelles surfaces autour desquelles concevoir des supports additionnels peuvent par ce biais être intégrées sans affecter la couche exécutive.

  • Pilotes chargeables dans le système d’E/S Windows met en oeuvre pour la prise en charge des pilotes un mécanisme de modules chargeables dans le système d’E/S. Orientés par une approche souple de l’ajout de matériel, les pilotes de périphérique sous Windows ne manipulent pas directement le matériel, mais sollicitent la couche d’abstraction matérielle pour faire l’interface avec le matériel. De nouveaux périphériques, tels que claviers et souris, et pilotes, tels pilotes de système de fichiers, peuvent ainsi être ajoutés.

  • Exécution distribuée Windows supporte l’exécution distribuée au moyen d’appels de procédures distantes (RPC, Remote Procédure Call). Le protocole RPC permet d’appeler des fonctions sur un système distant de façon quasi transparente, comme s’il s’agissait d’appels locaux, et est utilisé dans de nombreux services Windows. On trouve par exemple du code RPC dans les processus gérant le Registre, les services, les mécanismes de sécurité locale et d’authentification des utilisateurs (LSA), etc.

  • Gestion en réseau Windows intègre de façon native de nombreuses fonctionnalités réseau, permettant à un ensemble d’équipements (ordinateurs et périphériques tiers) reliés entre eux afin d’échanger des informations. Le système supporte un grand nombre de normes de câblage correspondant à des technologies différentes (ethernet, liaison sans fil, modem…​), reconnait autant de protocoles réseau (NetBEUI, TCP/IP, Appletalk, TokenRing…​), et rend accessible pléthore de services réseau (SMB, DNS, NTP, DHCP, Wins…​). L’ensemble de ces intermédiaires donne à Windows un caractère qui offre une grande interopérabilité dans le cadre de réseaux hétérogènes à tout niveau.

Compatibilité

Si chaque nouvelle mouture de Windows apporte son lot de fonctionnalités nouvelles et d’améliorations envers de futures intégrations plus satisfaisantes, Microsoft a toujours été salué pour son attention aux problèmes de compatibilité, fréquents dans le domaine de l’informatique, qui connaît une évolution rapide du matériel et des logiciels. Les méthodes grâce auxquelles les déclinaisons les plus récentes de Windows sont compatibles avec les anciennes versions sont majoritairement les suivantes :

  • Profils système Windows intègre une architecture modulaire et extensible qui offre toute la souplesse requise pour s’adapter à différents profils de système d’exploitation. Il en résulte la prise en charge d’applications dont le fonctionnement se trouve réglé par des dispositions d’origine et de nature diverses, que celles-ci émanent directement d’un autre système d’exploitation, par exemple MS-DOS, sur lequel nous reviendrons plus tard, OS/2, ou de normes techniques prédéfinies, par exemple POSIX. Cela permet permet d’effectuer des améliorations sur un profil système sans affecter la compatibilité avec les applications des autres profils.

  • Mode de compatibilité Pour obtenir une meilleure compatibilité avec les anciennes versions de Windows, les systèmes Microsoft permettent aux utilisateurs de spécifier les applications devant être prises en charge selon un mode de fonctionnement spécifique, appelé mode de compatibilité, se rapportant aux paramètres issus d’une version précédente de Windows et, sur un plan plus global, aux conditions délivrées par une version individuelle de Windows lors de l’exécution des programmes. En interne, Windows introduit pour ce faire une couche intermédiaire qui modifie les API Windows pour mieux approximer le comportement attendu par les anciennes applications. Ce composant peut, par exemple, faire paraître Windows 8 compatible fonctionnalités pour fonctionnalités avec Windows XP, et donner le change à certaines applications qui s’attendent (souvent sans fondements) à voir une certaine version de Windows, comptent sur des bizarreries d’implémentation relatives aux API, mésestiment les traitements internes effectués à l’intérieur des services natifs, ou plus simplement font des assertions erronées quant à l’incidence qu’ont certaines routines et variables noyau. En maintenant un support pour toutes les applications - y compris celles contenant des erreurs de programmation latents qui deviennent apparents à cause des changements dans l’implementation - Microsoft parvient à conserver toujours sur son écosystème un paysage riche des logiciels des versions précédentes.

  • Assistant Compatibilité des programmes La plupart des programmes conçus pour des versions antérieures de Windows sont compatibles avec la nouvelle version (voir point précédent). Toutefois, après mise à niveau vers une version de Windows plus récente que celle pour laquelle ils ont été conçus, il se peut que certains programmes réagissent de manière erratique, effectuent des actions inappropriées, voire ne fonctionnent plus du tout. Pour ces cas, Windows utilise l’assistant Compatibilité des programmes pour procéder automatiquement à des modifications associées à des problèmes de compatibilité connus. Si l’assistant détecte un problème de compatibilité connu, il signale le problème et fournit des solutions possibles pour le résoudre. Vous pouvez alors autoriser l’assistant à reconfigurer automatiquement l’application, ou modifier vous-mêmes les réglages afférents.

  • Maturité du code La maturité du code rend pérenne les interfaces exposées dans le noyau, les services de l’exécutif et les bibliothèques de sous-système (les routines normalement invisibles aux autres composants n’ont de toute façon aucun impératif à ce niveau, puisqu’elles ne devraient normalement jamais être appelé par des composants tiers). Depuis la rédaction du cahier des charges de Windows NT jusqu’à nos jours, les concepteurs d’applications et de pilotes tiers sont en face globalement des mêmes spécifications. Seuls quelques rares prototypes de fonctions ont été revus, notamment pour l’amélioration du multitraitement symétrique (multi processeur), ou pour l’infrastructure de soutien du 64 bits. Lors du passage d’une architecture 32 bits à une nouvelle 64 bits, des types de données additionnels intégrèrent les diverses interfaces Windows, afin de supporter ce nouveau type d’adressage, et le firent de manière assez délicate : en s’adaptant à une architecture cible, 32 ou 64 bits. Ainsi, une valeur ULONG_PTR est une valeur 32 bits quand elle est manipulée par un compilateur 32 bits, une valeur 64 bits quand elle vue par un outil idoine 64 bits. À titre indicatif, vous pouvez être certain que lorsque vous croisez un type PTR dans une déclaration de fonction, il s’agit d’une manœuvre pour permettre aux développeurs de concevoir du code portable et compatible.

  • Compatibilité des pilotes Outre la réduction des problèmes de compatibilité des programmes utilisateur, Windows tend à diminuer également ceux relatifs aux pilotes. Ainsi, chaque modèle de conception de pilotes livre avec Windows définit en standard des méthodes compatibles entre plusieurs versions du système d’exploitation. De plus, Les pilotes conformes à ces règles sont conçus pour être compatibles « vers le haut » (compatibilité ascendante), de sorte qu’un pilote peut fonctionner sur une version de Windows plus récente que celle pour laquelle il a initialement été écrit (ce faisant, le dit pilote ne peut bien entendu pas profiter des fonctionnalités introduites avec la nouvelle version).

  • Support pour les applications héritées Témoins d’un héritage technologique qui, s’il tend à disparaître, reste encore vivant, les produits de la gamme Windows fournissent un support également aux applications dont la réalisation (jeu d’instruction utilisé, sémantique des appels système, etc.) est héritée du lignage des systèmes Microsoft, incluant MS-DOS, Windows 16 bit et, si ce dernier n’a pas le caractère désuet des deux autres, Windows 32 bits sur architecture processeur 64 bits. Les versions 32 bits de Windows intègrent divers mécanismes pour maintenir la compatibilité avec les applications 16 bits ; à titre d’exemple un dispositif chargé de convertir les appels aux interfaces 16 bits (depuis longtemps dépréciée) en appels 32 bits équivalents. Dans la même veine, les versions 64 bits de Windows incorporent un environnement de compatibilité permettant d’exécuter une application 32 bits sur un système Windows 64 bits. WOW64 offre une couche de conversion des appels de l’API 32 bits en appels 64 bits natifs, et prend en charge de nombreuses différences entre Windows 32-bit et Windows 64-bit, en particulier celles impliquant des changements structurels.

Portabilité

Un système d’exploitation est portable s’il fonctionne sur différentes architectures et plateformes matérielles et s’adapte facilement sur de nouvelles, avec relativement peu de changements. Windows est conçu pour l’être.

La première version de Windows NT était compatible avec les architectures x86, omniprésente dans les ordinateurs personnels, stations de travail et serveurs informatiques, et MIPS, surtout en vogue (à l’époque) dans les supercalculateurs SGI (système CISC d´un côté, RISC de l´autre). La compatibilité avec Alpha AXP de Digital Equipment Corporation fut ajoutée dans la foulée. Pionnière de l’industrie informatique à partir des années 1960 jusqu’aux années 1990, la société DEC fut rachetée par Compaq en 1998, qui fusionna avec Hewlett-Packard en 2002. Dans le milieu des années quatre-vingt dix, Windows NT 3.51 fut le premier représentant d’une courte lignée disponible pour l’architecture PowerPC. PowerPC, parfois abrégé PPC, est une gamme de microprocesseurs dérivée de l’architecture RISC POWER d’IBM, et développée conjointement par Apple, IBM et Freescale (anciennement Motorola). Le marché ayant évolué depuis lors, Microsoft profita du début des travaux sur Windows 2000 pour procéder à un élagage massif parmi les architectures prises en compte, et rompit de la sorte toute attache avec les processeurs MIPS, Alpha et PowerPC, ne laissant sur le terrain que x86. Windows XP, mis en circulation en 2001 à la fois comme mise à jour du système de bureau Windows 2000 et en remplacement de Windows 95/98, est la première version de Windows à disposer de déclinaisons 64 bits : une pour les processeurs à base de x86_64, l’autre pour Itanium. Sans grande surprise face au nombre réduit de stations de travail dotés d’un tel équipement, Microsoft décida de mettre un terme à son soutien des processeurs Itanium, Windows Server 2008 R2 étant la dernière version à pouvoir se charger d’eux. En 2001, poussé par l’explosion des ventes dans le milieu de l’informatique embarquée, comprenant entre autre la téléphonie mobile et les tablettes, la firme de Redmond annonça que les déclinaisons futures de ses systèmes d’exploitation seraient capables de fonctionner sur ARM, chose faite dans Windows RT, une version du système d’exploitation Windows 8 pour les appareils ARM. Pour finir, et concédons le, résumer un paragraphe quelque peu rébarbatif, voici une liste (sans doute non exhaustive, sachant que certaines éditions du système ne virent le jour qu’à des fins de test et n’ont jamais été commercialisées), des diverses architectures avec lesquelles Windows est, ou a été, compatible : x86-32, x86-64, MIPS, Alpha, PowerPC, IA-64 (comprendre Itanium), et, dernièrement, ARM.

Windows assure la portabilité sur différentes architectures et plateformes matérielles de deux grandes façons.

  • Couche d’abstraction matérielle Windows dispose d’une structure en couches dans laquelle le code dépendant du matériel est isolé au sein d’une bibliothèque spéciale nommée couche d’abstraction matérielle (HAL, Hardware Abstraction Layer). Pour renforcer la portabilité, les couches supérieures du noyau reposent sur les interfaces HAL plutôt que sur les couches matérielles inférieures.

  • Langage de haut niveau La majeure partie de Windows est écrite en C, un langage qui adopte une vision très proche de la machine, mais dont la portabilité reste un des avantages les plus importants. L’assembleur n’est en l’occurrence employé qu’en de rares occasions, toujours dans des domaines très spécifiques, et là encore avec une certaine réserve. En règle générale, les primitives Windows exprimées en assembleur le sont soit parce qu’elles accèdent directement au matériel (par exemple, le gestionnaire d’interception) ou réussissent de la sorte à procurer un avantage manifeste en ce qui concerne les performances (par exemple, le basculement de contexte). S’il est évidemment surtout possible de rencontrer de l’assembleur dans le noyau et dans la couche d’abstraction matérielle, quelques autres endroits du système lui assurent une présence plus ou moins appuyée, y compris la portion bas niveau du sous-système Windows, pour le transfert vers un périphérique d’affichage, ou la bibliothèque de support Ntdll, pour le démarrage des processus.

Sécurité

Compte tenu de son orientation en tant que système d’exploitation d’entreprise, Windows a dès le départ été pensé en termes de sécurité, intégrant pour cela un ensemble de moyens visant à conserver, rétablir et garantir l’intégrité de l’environnement et des informations que ce dernier héberge. Chaque version de Microsoft Windows assume en la matière les rôles essentiels, et apporte le catalogue des fonctionnalités nécessaires. Celles-ci incluent :

  • Normes de sécurité Windows répond en matière de sécurité à diverses normes indiquant le degré de protection du système d’exploitation. Il est classé C2 dans la norme TCSEC (Trusted Computer Security Evaluation Criteria) et niveau F-C2 / E3 dans la norme ITSEC (Information Technologie Security Evaluation Criteria). Pour plus d’informations sur le sujet, consultez la section Sécurité et normalisations.

  • Journaux d’événements Les journaux d’événements, des fichiers spéciaux dans lesquels Windows enregistre des informations détaillées sur les événements significatifs du système informatique, ouvrent la voie à un système de surveillance permettant de détecter les tentatives d’action non autorisée ou d’intrusion.

  • Chiffrement Windows prend en charge le chiffrement local des données avec EFS (Encryption File System). Cette technologie, qui permet d’enregistrer des fichiers chiffrés au-dessus de NTFS, est la protection la plus renforcée fournie par Windows pour aider à sécuriser vos informations personnelles, les protégeant des attaques de personnes ayant un accès direct à l’ordinateur.

  • Contrôle d’accès Windows intègre le souci de la sécurité par un modèle de contrôle d’accès fin et précis. Les dispositifs majeurs à cet égard incluent la protection discrétionnaire (quels sujets ont accès à quels objets et comment), la protection de la mémoire (chaque programme s’exécute dans son propre espace d’adressage virtuel privé), l’audit (détection et enregistrement des événements relatifs à la sécurité), l’authentification lors de l’ouverture de session, l’identification auprès d’une autorité certifiée et, finalement, la protection contre la réutilisation d’objets (interdiction à un utilisateur d’accéder à des ressources non initialisées ou qu’un autre utilisateur a supprimé).

  • Protection des objets Aisément adaptable à des ressources de nature très différente, le modèle de sécurité de Windows permet de décrire les relations entre les diverses entités partageant des objets, mutualisant de cette façon le contrôle d’accès (voir point précédent) et l’audit. Renvoyant à la notion de propriété et de droits d’accès aux ressources du système, les propriétaires des objets (fichiers, imprimantes ou autres) accordent ou refusent l’accès à autrui. Chaque objet peut être doté d’une sécurité individuelle ou d’une sécurité de groupe. Les objets ont différents types de permissions, qui permettent d’autoriser ou d’interdire leurs accès. Quand un utilisateur ouvre une session, lui est attribué un ensemble de données d’identification (credentials). Quand l’utilisateur essaie d’accéder à un objet, le système compare son profil de sécurité avec celui de l’objet concerné (liste de contrôle d’accès) et vérifie que l’utilisateur est légitime dans son action envers l’objet. Si cette vérification est positive, le système légitime l’accès.

  • Solutions logicielles intégrées Windows intègre en standard diverses solutions dédiées à la sécurité, dont un antivirus et un pare-feu. L’Outil de suppression de logiciels malveillants (MRT, Malicious Software Removal Tool) est mis à la disposition des utilisateurs pour leur permettre de débusquer et d’éliminer les menaces les plus courantes sur un PC Windows infecté. L’application pare-feu livrée avec Windows vous permet d’empêcher les utilisateurs ou logiciels non autorisés d’accéder à votre ordinateur depuis un réseau ou Internet. Le pare-feu peut également empêcher votre ordinateur d’envoyer des éléments logiciels nuisibles à d’autres ordinateurs. Antivirus et pare-feu sont de base configurés pour bloquer les risques liés aux principales menaces.

  • Centre de sécurité Le centre de sécurité, ou centre de maintenance, vérifie le statut de l’ordinateur en matière de sécurité et affiche des avertissements en cas de risques potentiels.

  • Tolérance aux pannes Windows intègre un ensemble de fonctionnalités permettant de fiabiliser le fonctionnement du système. Parmi ces techniques, lesquelles visent à améliorer les performances, la sécurité ou la tolérance aux pannes, figurent par exemple Active Directory (AD), File Replication Service (FRS), Distributed File System (DFS) ou encore Redundant Array of Independent Disks (RAID).

  • BitLocker Solution de chiffrement utilisée afin de mieux protéger l’utilisateur contre le vol, BitLocker permet le chiffrement intégral de volumes, qu’il s’agisse d’un volume système (lecteur sur lequel réside Windows) ou d’un volume de données.

  • Secure Boot Fonctionnalité liée à UEFI, Secure Boot permet lors de la procédure d’amorçage du système de vérifier que chaque élément chargé est fiable.

  • PatchGuard Diminue la surface d’attaque du système en le protégeant de toutes modifications. Pour plus d’informations, voir Kernel Patch Protection (PatchGuard).

Pour replacer les choses dans le contexte qui les a vu naître, notez que la mise en conformité de Windows avec divers processus concernant la sécurité est pour une large part un aspect concomitant des objectifs de conception visant à la robustesse et à la fiabilité du système. De nos jours, la sécurité informatique est une industrie à part entière, avec des idées ayant qui leur vie propre et leur propre discernement.

Pour une vision plus large de la façon dont est gérée la sécurité dans Windows, reportez-vous au chapitre Sécurité.

Modèle de système d’exploitation

Microsoft Windows est une série de systèmes d’exploitation multiplateforme, multitâche, multi-utilisateur et multiprocesseur à base de micronoyau.

  • Multiplateforme Windows est conçu pour fonctionner sur plusieurs plateformes et différentes architectures matérielles. Voici, sur le sujet, une liste d’architecture de processeur qui sont, ou ont été, supportés au fil des années : x86, Alpha, MIPS, PPC, Itanium, AMD64, ARM. Microsoft étoffant ou élaguant la prise en charge entre famille de processeurs en fonction des impératifs du marché (pour des raisons commerciales), les versions récentes de Windows connaissent l’architecture x86, tirent profit des capacités étendues de l’architecture x64 (les versions 64 bits de Windows peuvent solliciter une mémoire plus importante que leurs homologues 32 bits), et gèrent les architectures ARM, dominants dans le domaine de l’informatique embarquée.

  • Multitâche Windows a de la capacité de gérer plusieurs programmes simultanément en leur attribuant tour à tour un pourcentage de temps processeur pour que ces programmes puissent s’exécuter. Chaque application occupe un processeur pendant un laps déterminé à l’avance ou jusqu’à ce qu’une autre application ait une priorité supérieure à l’application en cours. L’emploi du temps du processeur (autrement dit, quelle application doit s’exécuter à un instant t) est fait par un composant du système d’exploitation, l’ordonnanceur, qui contrôle et pilote l’exécution des divers programmes entre tous les utilisateurs.

  • Multi-utilisateur Windows permet à plusieurs utilisateurs d’utiliser l’ordinateur simultanément. Il met en ce sens en place les technologies essentielles du contrôle d’accès (respectivement, mécanisme d’authentification, d’autorisation et de traçabilité), procède aux vérifications de sécurité allant de pair avec l’intégrité des données vitales du système d’exploitation, des utilisateurs et de leurs programmes, et assure l’éventail des dispositifs nécessaires pour protéger des regards, ou au contraire partager, les biens confiés au système d’exploitation.

  • Multiprocesseur Windows sait gérer la présence dans l’environnement matériel de plusieurs processeurs. Il fonctionne sur des systèmes multi processeur symétriques en utilisant au mieux les multiples processeurs.

  • Micronoyau hybride L’architecture de Windows montre les signes d’une structure interne modulaire en adoptant de la technologie à micronoyau hybride : le système n’est stricto sensu ni monolithique, ni tout à fait un micronoyau. Les principaux composants du système (par exemple le noyau, le gestionnaire de mémoire ou le gestionnaire de processus) sont exécutés dans un mode privilégié du processeur, avec accès aux données système et au matériel, et partagent un même espace d’adressage (ce qu’ils ne feraient pas dans un micronoyau pur et dur). Le code des applications est exécuté dans un mode non privilégié du processeur, avec accès limité aux données système et sans possibilité d’accéder directement au matériel. Dans Windows, comme les programmes applicatifs des utilisateurs sont pris en charge par des systèmes client/serveur et ne sauraient fonctionner sans eux, on trouve au système des allures de micronoyau. Windows est encore parfois considéré comme un micronoyau en raison du grand nombre d’objectifs de conception le rapprochant d’un de ces systèmes (en particulier la séparation des personnalités du système d’exploitation à partir d’un design général du noyau).

Systèmes multi-utilisateur

Est dit multi-utilisateur tout système d’exploitation capable de simultanément et indépendamment exécuter plusieurs applications appartenant à plusieurs utilisateurs. Simultanément, dans ce contexte, tient au fait que le système est capable de gérer en harmonie de multiples identités numériques, et de faire en sorte que les accès concurrents vers les mêmes ressources (processeur, mémoire, disques durs…​) ne soient pas source de litiges. Chaque logiciel d’application, de n’importe quel utilisateur, est régi de manière indépendante et ne peut détériorer l’environnement d’un autre logiciel ; chaque tâche peut s’accomplir sans se préoccuper de ce que d’autres tâches, d’autres utilisateurs, effectuent.

Les systèmes multi-utilisateurs doivent pour parvenir à leurs fin prendre en compte plusieurs mécanismes :

  • Un mécanisme d’identification, chargé de prendre connaissance de l’identité d’un utilisateur.

  • Un mécanisme d’authentification, où le système valide les informations d’ouverture de session d’un utilisateur.

  • Un mécanisme d’autorisation, qui accorde à un individu un droit particulier d’utilisation du système.

  • Un mécanisme de protection, assurant l’intégrité du noyau et la non-interférence des applications entre elles.

  • Un mécanisme de comptabilité, astreignant les tâches utilisateur à une utilisation raisonnable de la machine.

Sous-systèmes d’environnement

Reflet de comment Windows apparaît aux concepteurs de logiciels, et éventuellement aux utilisateurs (via le dessin et l’expérience graphique), un sous-système d’environnement désigne une étendue dans laquelle processus et bibliothèques mode utilisateur se voient offrir un contexte d’exécution spécifique. Chaque sous-système présente sa propre réalisation d’un environnement de système d’exploitation (on parle en ce sens de personnalité), pour lequel il rend visible une combinaison de caractéristiques, comportements et interfaces de programmation. Cela permet à Windows d’exécuter des programmes développés pour d’autres systèmes d’exploitation, tels que Windows 16 bits, MS-DOS ou UNIX.

À l’origine, il était prévu que Windows soit pourvu de trois sous-systèmes : Windows, POSIX et OS/2, que la liste suivante présente à grands traits (nous reviendrons sur eux en détail plus tard).

  • Windows A pour rôle de faire fonctionner les applications spécifiquement conçues pour Microsoft Windows, y compris les programmes à interface graphique et ceux à interface caractère (mode console).

  • POSIX Propose un sous-ensemble de fonctions avec lesquelles exécuter des utilitaires et des applications UNIX.

  • OS/2 Reproduit le comportement et les mécanismes du système d’exploitation OS/2, résultat d’une création conjointe entre IBM et Microsoft.

Des constituants de cette liste, le premier, et le plus important est évidemment toujours en vigueur. Le second, OS/2, a suivi un chemin similaire à son modèle : marquant le désengagement de Microsoft sur le projet, le support de OS/2 a disparu à partir de Windows 2000. Concernant POSIX, ses fonctionnalités ont été incorporées à un ensemble d’outils d’interopérabilité, les Windows Services for UNIX, qui étendent et remplacent à cet égard un sous-système POSIX jugée trop minimaliste.

Conçu à partir d’une optique générale du système d’exploitation, et des fonctionnalités offertes par lui, le rôle d’un sous-système d’environnement est d’exposer aux applications un certain sous-ensemble des services système de l’exécutif Windows. Chaque sous-système rend visible un sous-système différent des services natifs de Windows. Cela signifie qu’une application exécutée par-dessus un certain sous-système peut faire des choses que ne peut pas faire une application exécutée par-dessus un autre sous-système. Ainsi, une application Windows ne peut pas utiliser la fonction fork, laquelle est apparentée à POSIX.

L’architecture en sous-systèmes de Windows interdit de mélanger des appels de fonction provenant de différents environnements au sein d’une même application. En d’autres termes, une application ne peut solliciter les services que du sous-système pour lequel elle est prévue. Une seule bannière sous laquelle se rassembler étant possible, une application Windows ne peut appeler que des services exportés par le sous-système Windows, une application POSIX ne peut appeler que des services exportés par le sous-système POSIX, etc.

Développé autour d’une perspective client/serveur, chaque sous-système est porté par un processus serveur s’exécutant en mode utilisateur, duquel les applications sollicitent les services, et par un ensemble de librairies dynamiques, desquelles ils appellent les fonctions. En interne, ces librairies transcrivent les requêtes en composants compréhensibles d’un sous-système de plus bas niveau, dit natif, seul habilité à interagir avec le noyau (Windows donne pour bonne conduite des programmes le fait de ne pas s’impliquer directement avec les appels système).

Bibliothèques de sous-système

Premiers fournisseurs des technologies sur lesquelles s’appuient les applications mode utilisateur, chaque sous-système réalise ses fonctionnalités dans une ou plusieurs bibliothèques. Les bibliothèques de sous-système exportent l’interface que peuvent appeler les programmes liés au sous-système. Ainsi, les DLL du sous-système Windows (telles Kernel32.dll, Advapi32.dll, User32.dll et Gdi32.dll) implémentent les fonctions de l’API Windows. La DLL du sous-système POSIX implémente les fonctions de l’API POSIX.

Quand une application appelle une fonction ayant corps dans une DLL de sous-système, il peut se passer l’une des trois choses suivantes :

  • La fonction est entièrement implémentée dans la DLL de sous-système. A ce niveau, aucun autre traitement supplémentaire n’est requis, il n’y pas de message envoyé au processus du sous-système d’environnement, ni non plus d’appel aux services système de l’exécutif Windows. En pareil cas, la fonction s’exécute et rend la main à l’appelant, retournant quelquefois au passage un résultat. Exemples : GetCurrentProcess, qui retourne la valeur définie pour le pseudo handle associé au processus en cours (systématiquement -1), ou GetCurrentProcessId, laquelle fonction retourne l’ID du processus appelant, qui ne change pas pour un processus en cours d’exécution et est en interne lu depuis une zone de données directement accessible en mode utilisateur.

  • La fonction requiert le concours des services de l’exécutif Windows, et exige à ce titre un accès aux services noyau. A ce cas de figure correspond, par exemple, les fonctions Windows ReadFile et WriteFile, qui impliquent des appels aux services d’E/S Windows NtReadFile et NtWriteFile, respectivement.

  • La fonction nécessite la coopération du processus de sous-système d’environnement. A ce moment, on adresse via fonctionnalité d’appel a une procédure locale (LPC) une requête client-serveur au processus de sous-système. La DLL de sous-système attend alors une réponse avant de rendre la main à l’appelant.

Pour finir sur une note plus globale, chaque fonction provenant d’une DLL de sous-système peut, d’après ce qui vient d’être exposé, être amenée à s’interfacer avec un ou plusieurs autre(s) composant(s) de nature diverse : services natifs, librairies tierces, voire d’autres processus. A de maints égards, cette façon de faire illustre, par les multiples interactions qu’elle suppose, à la fois la dimension en couches de Windows, et le côté coopératif des divers composants.

Informations de démarrage de sous-système

Les informations de démarrage de sous-système sont hébergés sous les auspices du gestionnaire du session (Smss) au sein de la valeur de registre HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\SubSystems.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Subsystems
    (par défaut)    REG_SZ    mnmsrvc
    Debug    REG_EXPAND_SZ
    Kmode    REG_EXPAND_SZ    \SystemRoot\System32\win32k.sys
    Optional    REG_MULTI_SZ
    Required    REG_MULTI_SZ    Debug\0Windows
    Windows    REG_EXPAND_SZ    %SystemRoot%\system32\csrss.exe ObjectDirectory=\Windows SharedSection=1024,20480,768 Windows=On SubSystemType=Windows ServerDll=basesrv,1 ServerDll=winsrv:UserServerDllInitialization,3 ServerDll=sxssrv,4 ProfileControl=Off MaxRequestThreads=16

La valeur Required énumère les sous-systèmes chargés au démarrage du système. La valeur a deux deux chaînes : Windows et Debug. La valeur Windows contient l’emplacement et le nom du fichier du sous-système Windows, Csrss.exe (Client/Server Run-Time Subsystem). La valeur Debug, généralement vide, est employée dans l’optique de tests internes. La valeur Optional indique que le sous-système Posix sera chargé à la demande. La valeur Kmode indique les données de chemin d’accès du fichier abritant la portion mode noyau du sous-système Windows, Win32k.sys.

Environnement MS-DOS (NTVDM)

Reproduction des conditions du système d’exploitation de type DOS développé par Microsoft pour les compatibles PC, l’environnement MS-DOS est supporté dans Windows par le biais d’une application spécifique appelée machine virtuelle DOS (VDM, Virtual DOS Machine), qui fournit un contexte d’exécution adéquat aux applications conçues pour ce système. Par définition, tous les programmes écrits pour MS-DOS sont des programmes 16 bits.

Les technologies enracinées dans la machine virtuelle DOS dépendent du mode virtuel 8086 du processeur Intel 80386, lequel permet d’exécuter des logiciels conçus pour le processeur 8086 en mode réel dans un environnement piloté par interruptions. Chaque machine DOS s’appuie sur une unité d’exécution d’instruction (instruction-execution unit) interne pour exécuter ou émuler des instructions, et a des pilotes virtuels pour l’écran, le clavier et les ports de communication.

Les machines DOS virtuelles sont apparues avec Windows 2.1 386 et sont présentes dans toutes les versions 32 bits subséquentes de Windows. Dans la famille Windows NT, laquelle marque l’abandon des technologies héritées de MS-DOS et de Windows 3.x, elles sont toutefois reléguées à émuler DOS et ne ne peuvent plus interagir avec l’API Windows.

L’exécutable sous-jacent à la couche d’émulation DOS dans Windows NT et supérieurs porte le nom de ntvdm.exe et démarre automatiquement quand l’utilisateur sollicite une application 16 bits dans un environnement 32 bits. Les versions 64 bits de Windows ne possèdent pas cet émulateur.

Sous-systèmes et création de processus

Chaque module exécutable (.exe) est lié à un sous-système. A cet effet, l’attribut Subsystem dans l’entête facultative de l’image détermine pour quel environnement le fichier est prévu. Les valeurs définies à cet égard incluent :

  • IMAGE_SUBSYSTEM_UNKNOWN Le sous-système pour lequel se destine l’image n’est pas connu. Le fichier ne peut être chargé.

  • IMAGE_SUBSYSTEM_NATIVE Sous-système non requis. Cette option est généralement réservée aux composants du système Windows, incluant pilotes de périphérique et processus système natifs.

  • IMAGE_SUBSYSTEM_WINDOWS_GUI Pour une application Windows en mode graphique. L’application ne nécessite pas de console, car elle crée probablement ses propres fenêtres d’interaction avec l’utilisateur.

  • IMAGE_SUBSYSTEM_WINDOWS_GUI Pour une application Windows en mode caractère. Le système d’exploitation fournit automatiquement une console aux applications console.

  • IMAGE_SUBSYSTEM_POSIX_CUI Pour une application de type UNIX s’exécutant avec le sous-système POSIX dans Windows.

  • IMAGE_SUBSYSTEM_WINDOWS_CE_GUI Le fichier est prévu pour être exécuté dans l’environnement Windows CE, lequel n’est pas reproduit dans Windows.

Lors de l’exécution d’une image, le code de création de processus (fonction Windows CreateProcess) examine le code de type de sous-système dans l’en-tête de l’image de façon à informer le bon sous-système de l’existence du nouveau processus. Si le fichier exécutable est une application Windows native, il est exécuté sans détour. Autrement (par exemple, s’il s’agit d’une application MS-DOS ou POSIX), du code additionnel se greffe aux opérations en place pour trouver une image de support permettant d’exécuter le fichier. Les applications non natives ne pouvant être exécutées directement, Windows utilise comme intermédiaire l’une des quelques images de support spéciales qui ont la charge d’executer réellement les programmes non Windows. Le tableau suivant associe quelles applications sont pris en charge par quel sous-système.

Table 10. Associations entre sous-systèmes et processus de support

Type d’application

Processus de support

Fichier exécutable POSIX

Posix.exe

Application MS-DOS

Ntvdm.exe

Application Win16

Ntvdm.exe

Procédure de commandes (.bat ou .cmd)

Cmd.exe

Pour la plupart des programmes Windows, deux types de sous-système de l’image sont utilisées : Windows GUI (IMAGE_SUBSYSTEM_WINDOWS_GUI dans le tableau x), correspondant aux programmes à interface graphique, et Windows CUI (IMAGE_SUBSYSTEM_WINDOWS_CUI) pour les programmes à interface caractère.

L’option /SUBSYSTEM de l’Editeur de liens (link.exe) permet de spécifier quel environnement est apparenté à un fichier executable. La sélection de cette option affecte le symbole de point d’entrée (ou la fonction de point d’entrée) que l’éditeur de liens sélectionne (WinMain, DllMain, DriverEntry, etc.)

Composants fondamentaux du système

Après nous être intéressé à l’architecture générale de Windows, nous allons dans cette section revenir plus en détail sur le rôle joué par chacun des composants clé du système d’exploitation.

Ntdll.dll

Ntdll.dll est une bibliothèque spéciale de support autour de laquelle s’articulent différents composants Windows exécutées en mode utilisateur. Ntdll contient principalement deux types de fonctions :

  • Des fonctions points d’entrée vers les services système de l’exécutif.

  • Des fonctions de support internes sollicitées par les sous-systèmes, les DLL de sous-système et autres images natives.

Le premier groupe de fonctions assure l’interface vers les services système de l’exécutif pouvant être appelés depuis le mode utilisateur. Il existe des centaines de ces fonctions, pour la plupart accessibles depuis l’API Windows. Par exemple, Ntdll exporte NtCreateProcess, qui constitue en l’occurence l’interface commune à les fonctions Windows de création de processus. Autres exemples : NtReadFile, service interne sur lequel s’appuie ReadFile (Kernel32.dll) pour lire des données à partir d’un fichier ; NtSetEvent, employé par SetEvent pour définir le signal associé à un objet de synchronisation type événement, et ainsi de suite. Chacune de ces fonctions contient le code spécifique qui, après vérification de certains paramètres, force une transition vers le mode noyau pour invoquer le dispatcher de service système, lequel passe finalement le relais au service système proprement dit.

Ntdll renferme aussi maintes fonctions de support internes, par exemple le chargeur d’image (fonctions commençant par Ldr), le gestionnaire de tas, le dispatcher d’APC, les mécanismes de communication du processus du sous-système Windows (fonctions commençant par Csr), les routines générales de la bibliothèque d’execution (fonctions commençant par Rtl).

Exécutif

Au-dessus du noyau et des pilotes de périphériques se trouve la partie supérieure du système d’exploitation appelée exécutif, formée d’un petit nombre de composants eux-mêmes constitués d’une multitude de procédures collaborant à la réalisation d’une activité ou d’une tâche donnée. L’exécutif est écrit en C ; il est de la sorte indépendant de l’architecture, prend en compte un large éventail de plateformes, et peut facilement être porté sur de nouvelles.

La liste suivante énumère quels sont les grands composants de l’exécutif Windows. Chacun d’eux sera traité en détail dans un chapitre ultérieur.

  • Gestionnaire d’alimentation Coordonne les événements système résultants d’un changement de l’état d’alimentation de l’ordinateur et génère des notifications d’E/S de gestion électrique aux pilotes de périphériques concernés.

  • Gestionnaire d’E/S Fournit le cadre pour implémenter les pilotes de périphériques, de même que certains services spécifiques à la configuration, l’accès ou la réalisation d’opération sur les périphériques.

  • Gestionnaire de Plug and Play (PnP) Détermine quels sont les pilotes requis par la prise en charge d’un certain matériel, par exemple une carte réseau, et charge ces pilotes.

  • Gestionnaire de processus Traite le cycle de vie des diverses entités exécutables gérés par le système d’exploitation, y compris les processus, les threads, et les travaux (ensemble de processus administrable comme un tout).

  • Gestionnaire de mémoire Implémente la mémoire virtuelle et les procédés auxquels cette technique ouvre la voie, par exemple les fichiers mappés en mémoire ou la stratégie d’optimisation copy-on-write. En outre, le gestionnaire de mémoire fournit la prise en charge sous-jacente au gestionnaire de cache.

  • Gestionnaire d’objets Crée, gère et supprime les objets de l’exécutif et abstrait les types de données qui servent à représenter les ressources système du genre processus, threads et fichiers.

  • Gestionnaire de cache Fournit des services globaux de cache aux différents pilotes de systèmes de fichiers (NTFS et autres), et optimise de la sorte les entrées/sorties disque en conservant en mémoire centrale des parties de fichiers lues ou à lire.

  • Gestionnaire de configuration Met en oeuvre et assure le suivi du Registre Windows, lequel héberge une collection de différents paramètres liés au système d’exploitation, ainsi qu’aux logiciels et aux utilisateurs.

  • Moniteur de références de sécurité Contrôle et fait appliquer les stratégies de sécurité au niveau de l’ordinateur local (connexion authentifiée, mise à zéro de la mémoire allouée, protection de l’espace d’adressage, contrôle d’accès, etc.), assurant de cette façon la protection et l’audit des ressources du système.

  • Gestionnaire WMI Permet aux composants de l’exécutif de publier des données de configuration et de performances et de recevoir des commandes du service WMI mode utilisateur.

  • Prefetcher logique

Gestionnaire de processus

Le gestionnaire de processus de Windows fournit les services nécessaires à la création, la suppression et l’utilisation des processus, des threads et des travaux. Il a pour rôle la définition des critères et des attributs latents au support de ces dispositifs dans le système, et ouvre la voie à leur transposition sous forme algorithmique, à leur mise en oeuvre, et enfin à leur programmation.

Vu la complexité de la mission à réaliser et la diversité des fonctionnalités à pourvoir, le gestionnaire de processus fonctionne en interaction avec de nombreux autres composants de la couche exécutive : gestionnaire de mémoire, pour fournir à chaque processus un espace d’adressage virtuel privé ; moniteur de références de sécurité, afin que tout processus soit systématiquement contrôlé lors des opérations qui doivent l’être ; prefetcher logique, de façon à accélérer le démarrage de certains processus ; etc.

Le gestionnaire de processus représente la partie la plus visible des techniques utilisées pour la gestion des flux d’exécution. La prise en charge sous-jacente des processus et des threads est implémentée dans le noyau Windows ; l’exécutif ajoute des fonctionnalités supplémentaires relatives à ces objets de bas niveau.

En plus des mécanismes généraux de supervision des entités sous sa coupe, le gestionnaire de processus a aussi pour tâche la mise au point de procédés connexes, tels la mise en file d’attente et la livraison des appels de procédure asynchrones (APC, asynchronous procedure calls) aux threads.

Bien que les systèmes Windows tiennent compte d’une certaine forme de hiérarchie entre les processus, le gestionnaire de processus n’a aucune connaissance des relations entre processus pères ou fils. Cette subtilité est traitée par le sous-système d’environnement particulier duquel le processus hérite ses caractéristiques. Le gestionnaire de processus n’est également pas impliqué dans l’ordonnancement des processus, hormis en ce qui concerne le positionnement des priorités et affinités des processus et des threads lors de leur création.

Sur le plan de la sémantique et de la programmation système, les noms des routines qui fournissent une interface directe avec le gestionnaire de processus et de threads sont couramment assortis du préfixe Ps, par exemple PsCreateSystemThread ou PsGetCurrentProcess.

Gestionnaire de mémoire virtuelle

Le composant de l’exécutif en charge des procédés sous-jacents à la gestion de de la mémoire, y compris l’espace d’adressage virtuel, l’allocation de la mémoire physique et la pagination, est le gestionnaire de mémoire.

La fonction première du gestionnaire de mémoire est l’implémentation de la mémoire virtuelle, à savoir un système de gestion mémoire qui offre à chaque processus un espace d’adressage privatif susceptible d’être plus grand que la mémoire physique disponible. La mise en oeuvre d’un tel projet étant fortement dépendante de dispositifs physiques, en premier lieu l’unité de gestion mémoire, partie intégrante de tous les microprocesseurs récents, le gestionnaire de mémoire suppose que l’architecture matérielle supporte un mécanisme de pagination et la translation virtuel vers physique.

Initiateur et administrateur du lien entre pages virtuelles et pages physiques, le gestionnaire de mémoire participe de cette manière au respect des règles de protection qui limitent l’accessibilité d’un thread donné aux pages appartenant à son propre espace d’adressage (sauf cas très particulier).

De par la proximité des schémas sous-jacents à la mémoire à ceux relatifs au cache système, le gestionnaire de mémoire virtuelle fournit une partie de la prise en charge sous-jacente au gestionnaire de cache.

Couche d’abstraction matérielle (HAL)

La couche d’abstraction matérielle (HAL, Hardware Abstraction Layer) fournit l’interface de bas niveau vers la plateforme matérielle.

Vous pouvez évaluer les relations qui unissent les images du noyau (Ntoskrnl.exe) et de la couche d’abstraction matérielle (Hal.dll) en examinant leurs tables d’importation et d’exportation respectives via l’utilitaire Dependency Walker (Depends.exe). Vous remarquerez alors que Ntoskrnl est lié à Hal, qui lui-même est lié à Ntoskrnl. Chacun, en d’autres termes, sollicite et bénéficie des fonctions que l’autre rend visible.

Processus système fondamentaux

Quelques-uns des dispositifs de base de Microsoft Windows, y compris la gestion des utilisateurs, la prise en compte de la sécurité ou encore le suivi des services, sont le fait d’une collection d’acteurs individuels, organisés sous la forme de processus venus compléter le jeu de fonctionnalités exposées depuis le système d’exploitation. Chaque système Windows met à ce titre en oeuvre les processus que voici. (Deux d’entre eux, Inactif et System, ne sont pas des processus à part entière, vu que leur déroulement n’implique pas stricto sensu de module exécutable.)

  • Processus inactif du système (System Idle Process) Occupe le processeur tandis qu’il ne peut l’être autrement.

  • Processus System Héberge la majorité des threads système mode noyau.

  • Processus d’ouverture de session (Winlogon.exe) Gère l’ouverture et la fermeture des sessions interactives. 


  • Gestionnaire de session locale (Lsm.exe) Gère l’ouverture de session locale.

  • Serveur d’authentification de sécurité locale (Lsass.exe) Gère les mécanismes de sécurité locale et d’authentification des utilisateurs via le service Winlogon.

  • Gestionnaire de contrôle de service (Services.exe) Permet l’interaction avec les services et les processus hébergés dedans. 


  • Sous-système Windows (Csrss.exe) Implémente le code mode utilisateur du sous-système d’environnement Windows. Gère les fenêtres et les éléments graphiques de Windows.

  • Gestionnaire de session (Smss.exe) Administre les processus et autres objets système (station fenêtre, bureaux et fenêtres) utilisés dans le but de représenter la session d’un utilisateur.

  • Processus d’initialisation de la session 0 (Wininit.exe) Gère le démarrage de Windows (session 0).

Pour mieux comprendre les relations entre les protagonistes susmentionnés, il est à propos de s’intéresser à la place qu’occupe chacun au sein de l’arborescence des processus. Utilisez pour ce faire un utilitaire permettant de montrer les liens parent/enfant entre processus, par exemple PsList, ou de manière plus graphique, Process Explorer.

C:\>pslist.exe -t

pslist v1.3 - Sysinternals PsList
Copyright (C) 2000-2012 Mark Russinovich
Sysinternals - www.sysinternals.com

Process information for HP:

Name                             Pid Pri Thd  Hnd      VM      WS    Priv
Idle                               0   0   8    0      64       4       0
  System                           4   8 170 1535  138556   32808     884
    smss                         392  11   2   49 4194303     208     352
csrss                            532  13  15  476 4194303    1780    1608
wininit                          624  13   2   86 4194303     680    1036
  services                       700   9   5  425 4194303    5104    3416
    svchost                      440   8  25 1151 4194303   14608   17632
      dasHost                   5684   8   4  312 4194303   10812    5516
    svchost                      904   8  27  753 4194303   12936    8352
    .
    .
    .

Tous les processus dont nous venons de parler fonctionnent dans le contexte du compte système local, lequel est le compte de service qui bénéficie des plus hautes accréditations sur la machine. Windows les considère de ce fait comme des parties approuvées du système d’exploitation.

Processus inactif du système

Préfigurant la résolution à une figure classique des questions soulevées en matière d’ordonnancement, le processus inactif du système se différencie des autres processus par sa seule fonction, à savoir occuper le processeur lorsqu’il ne peut l’être par aucune autre tâche. Il fait de la sorte référence à la vacance des ressources du système (en premier lieu celle du processeur), lesquelles sont par conséquent disponibles pour qui les réclame.

Contrairement aux autres processus, le processus inactif du système travaille lorsque les autres processus ne font rien. Le degré auquel ce processus emploie les ressources machine se rapporte donc en réalité à un certain facteur d’inaction au sein de celles-ci. Ainsi, une valeur de 90% comme taux d’utilisation du processeur pour le processus inactif signifie que 90% des ressources processeur ne sont pas utilisées.

Une autre particularité que présente le processus inactif (de même par ailleurs que celui baptisé System) est de ne pas avoir d’auxiliaire de type image (.exe) à lui être spécifiquement dédié. Les instructions et les données sous-jacentes sont en fin de compte hébergés au niveau du fichier système spécifique au noyau (Ntoskrnl.exe ou équivalent). Comme les processus sont généralement identifiés par les noms des images associées, le nom affiché pour le processus inactif (ID 0) diffère d’un outil à l’autre. Pour résoudre cette ambiguïté, partez du fait que l’ID du processus inactif est toujours initialisé à la valeur zéro.

Winlogon

Le Processus d’ouverture de session Windows (\\Windows\System32\Winlogon.exe) gère les ouvertures et fermetures de session interactive, le déclenchement et l’arrêt des écrans de veille, et l’arrêt/redémarrage de la machine. Il est en outre responsable de la présentation de l’écran d’accueil sur la station de travail, lequel invite généralement à saisir les informations d’identification d’un utilisateur.

Les parties identification et authentification du processus d’ouverture de session sont mises en oeuvre de façon exogène par l’intermédiaire d’interfaces spécialisés, qui font dans ce contexte office de courtiers entre l’utilisateur et l’autorité de sécurité locale (Lsass). Dans les systèmes d’exploitation Windows NT4, Windows 2000, XP et Windows 2003, c’est au premier lieu le module GINA (Msgina.dll) qui offre des services sécurisés en la matière. À partir de Windows Vista, ce rôle est confié à LogonUI, lequel agit en interaction avec divers fournisseurs d’informations d’authentification.

Lors de son démarrage, Winlogon crée 3 bureaux, un bureau sécurisé dans lequel les interactions sécurisées auront lieu, un bureau appelé à être actif quand l’écran de veille se déclenchera, et un autre qui deviendra celui de l’utilisateur interactif. Il enregistre alors la combinaison clavier SAS (Secure Attention Sequence), de sorte à être informé chaque fois qu’un utilisateur interagit avec cette séquence de touches.

La séquence SAS, par défaut CTRL + ALT + SUPPR sert à protéger l’ouverture de session. Lors de la phase d’amorçage, la portion mode noyau du sous-système Windows (Win32k.sys) réserve ladite combinaison de touches afin que, chaque fois que le gestionnaire de saisie clavier de Windows (mis en œuvre dans un thread spécifique au sein de Win32k.sys) l’intercepte, il en résulte l’envoi d’un message RPC vers le processus Winlogon (qui est à l’écoute de notifications d’authentification). Les touches entrées au clavier qui correspondent à une touche de raccourci enregistrée ne sont jamais envoyés à un processus autre que celui souscripteur, et seul le thread ayant enregistré une touche de raccourci peut annuler son inscription. Le système est partant de là conçu de telle façon que la combinaison SAS ne peut être interceptée par un programme autre que le processus d’ouverture de session. Cela est notamment utile contre les programmes de capture de mot de passe, ou tout autre logiciel malveillant basé sur l’usurpation d’identité.

Quel que soit la méthode ayant débouché sur son entrée en scène (ouverture de la session initiale ou SAS), Winlogon affiche à l’écran le bureau sécurisé, lequel présente selon le contexte l’écran d’ouverture de session, la boîte de dialogue Sécurité de Windows, menant à une variété de mesures tels que fermer la session, lancer le gestionnaire des tâches, verrouiller la station, arrêter le système, ou encore les fenêtres associées au consentement de contrôles de comptes utilisateurs. L’écran de veille, géré comme un cas à part, dispose en conséquence de son bureau, toujours sous la supervision de Winlogon.

Apres saisie des données d’identification relatives à un utilisateur (lesquelles sont généralement associées au couple nom et mot de passe), celles-ci sont relayés à LSASS pour validation. Par la suite, Winlogon donne lieu au premier processus créé dans le contexte utilisateur, Userinit, qui est justement le sujet de la section suivante.

Userinit

Premier des processus exécutés dans le contexte de sécurité d’un utilisateur spécifique, Userinit a pour principal objectif de façonner la session de travail selon un ensemble de préférences fonctionnelles et esthétiques. C’est le processus d’ouverture de session (Winlogon), à la suite de l’examen de la clé de registre userinit sous l’emplacement HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon, qui fait appel au processus Userinit (\Windows\System32\Userinit.exe). Entre autres opérations effectuées à l’échelle de ce processus, le chargement du profil utilisateur et le démarrage de l’interface graphique de Windows.

Etroitement liée à l’architecture de scripts incorporée à Windows, elle-même fortement couplée aux paramètres de stratégie, Userinit contrôle les scripts d’ouverture et de fermeture de session, ainsi que les scripts de démarrage et d’arrêt de l’ordinateur. Il itère à cet effet les entrées des arborescences HKCU\Software\Policies\Microsoft\Windows\System\Scripts et HKLM\Software\Policies\Microsoft\Windows\System\Scripts. (Les paramètres de configuration ordinateur définissent un script à l’arrêt et au démarrage de la machine indépendamment de l’utilisateur. Les paramètres de configuration utilisateur appliquent le script à l’ouverture et à la fermeture de session sur n’importe quel ordinateur.) Chaque fois que nécessaire, Winlogon déclenche une nouvelle instance du processus Userinit, lequel se base sur l’emploi de la fonction ShellExecute pour l’exécution des scripts.

Hormis ceux déployés par la stratégie de groupes, Userinit gère plusieurs autres emplacements de registre et répertoires afin de démarrer automatiquement des processus. Entrent dans cette catégories les clés Run et RunOnce situées sous HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion et sous HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion, ainsi que les dossiers %SystemDrive%\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup et %SystemDrive%\Users\%UserName%\AppData\Roaming\Microsoft\Windows\Start Menu.

Autre mission prise en charge par Userinit, le démarrage de l’environnement de bureau Windows, soit celui associé de manière naturelle aux systèmes d’exploitation Microsoft, soit une alternative comme LiteStep. Durant la phase d’initialisation, Userinit crée un processus pour exécuter ce qui est indiqué par la valeur HKCU\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell. Si cette valeur n’existe pas (ce qui est le cas par défaut), il réitère la même procedure pour HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell, qui indique par défaut Explorer.exe.

Un autre rôle que joue Userinit se situe dans l’application des quotas. Ainsi, si la stratégie de groupe fait mention de restriction en ce qui concerne les profils utilisateur, Userinit donne le départ au processus Proquota, chargé en l’occurence de faire respecter le quota du profil de l’utilisateur courant.

Après avoir mené à bien les différentes tâches que nous venons de décrire, Userinit se termine, ce qui a pour effet de couper tout lien de parenté évident entre ce processus et ses fils. De ce fait, Explorer.exe a la particularité d’être toujours montré comme privé de parents au sein des différents utilitaires de visualisation de processus.

Wininit

Le processus d’initialisation de la session console est en charge d’un certain nombre d’étapes préliminaires au déroulement d’autres processus exécutés sous la session console (session 0), y compris le gestionnaire de contrôle des services (services.exe), le serveur d’authentification de sécurité locale (lsass.exe) et le gestionnaire de session locale (lsm.exe).

C’est le thread principal du processus Smss qui démarre Wininit. Lors de l’amorçage du système, Smss détermine l’emplacement du fichier image à exécuter pour la prise en charge de la session 0 au moyen de la valeur S0InitialCommand sous HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager, laquelle mène par défaut à %SystemRoot%\system32\wininit.exe.

SMSS (Session Manager Subsystem)

Premier des processus mode utilisateur créés dans le système, le gestionnaire de session a pour tâche principale de préparer l’ordinateur en vue de son utilisation par un tiers. C’est le thread système mode noyau effectuant la phase finale de l’initialisation de l’exécutif qui crée le processus Smss (\Windows\System32\Smss.exe).

Le gestionnaire de session est responsable d’un certain nombre d’étapes importantes du démarrage de Windows, parmi lesquelles la création des variables d’environnement, l’ouverture de fichiers de pagination supplémentaires, la prise en charge des opérations différées de niveau fichier, et d’autres. Il participe de surcroît à la mise en place du sous-système Windows, du processus d’ouverture de session, et du processus d’initialisation de la session 0, lequel crée le reste des processus système.

La plus grande partie des données de registre concernant le gestionnaire de session se trouvent sous HKLM\SYSTEM\CurrentControlSet\Control\Session Manager. Les valeurs de premier niveau situées sous cette clé servent principalement à la constitution de paramètres initiaux pour l’initialisation de Smss. Les sous-clés hébergées à partir de cet emplacement consolident, quant à elles, pour la plupart, des opérations qui dépassent le strict cadre du gestionnaire de session, par exemple la taille du fichier d’échange ou les informations d’activation (WPA).

Smss offre toute la logistique nécessaire afin que Windows soit un système à multiples sessions. Pour établir une plus grande séparation entre les processus mode utilisateur et le système d’exploitation, Smss crée au démarrage deux sessions, et installe dans chacune une copie de lui-même. La première instance de Smss est exécutée au sein de la session console (appelée session 0), laquelle est exclusivement réservée aux services et aux processus système. La seconde instance fonctionne dans la première session à disposer d’une connexion interactive, la session 1.

L’une des premières actions de large ampleur à se concrétiser dans le cadre du gestionnaire de session est la détection des éventuels programmes et services à exécuter lors de l’amorçage du système, mais avant le sous-système Windows. Le gestionnaire de session procède à cet effet à l’examen de la valeur BootExecute sous HKLM\SYSTEM\CurrentControlSet\Control\Session Manager, servant en l’occurrence à identifier les logiciels qui se situent à ce niveau, et donne le départ aux programmes définis par ce biais. En principe, la valeur BootExecute contient une commande pour exécuter la vérification des systèmes de fichiers, correspondant au module autochk. (Autochk est une version spéciale de Chkdsk prévue uniquement pour des disques NTFS et exclusivement pour l’amorçage.)

Une fois que sa configuration interne a définitivement pris forme, le gestionnaire de session charge la partie mode noyau du sous-système Windows, à savoir Win32k.sys. (A titre informatif, c’est là que Windows bascule l’affichage du mode texte au mode graphique.) Il sollicite ensuite dans le but de les voir démarrer le processus d’initialisation de la session 0 (Wininit), le processus Windows coté utilisateur (Csrss) et le processus d’ouverture de session (Winlogon). Si l’un ou l’autre des processus Csrss et Wininit se termine de manière inattendue, le noyau fait s’effondrer le système, Windows dépendant étroitement d’eux. Dans le cas où ce dysfonctionnement concerne Winlogon, le système met brutalement fin à la session associée.

Smss évalue quels sont les processus de sous-système à charger automatiquement au démarrage (en principe, seulement Csrss, dans la mesure où les autres sous-systèmes sont prévus pour fonctionner à la demande) en se référant aux informations stockées sous HKLM\SYSTEM\CurrentControlSet\Control\Session Manager. Plus spécifiquement, Smss consulte à cet égard la valeur Required, laquelle redirige généralement vers une autre valeur, nommée Windows, qui contient la position du l’exécutable csrss.exe dans le système de fichiers. La mise en marche de Csrss donne aux sessions la possibilité de gérer les applications mode utilisateur, qui emploient dans la plupart des cas de figure l’API Windows.

La prise en charge des sessions s’effectue également par le biais de Smms, à la fois celle de la session non interactive, et de celles qui le sont. Une session se compose des processus et des autres objets système (station fenêtre, bureaux, fenêtres, etc.) qui représentent la session ouverte par un utilisateur sur une station de travail. Quand Smss crée la première des sessions interactives (ID 1), ou quand Smss recoit une demande de création de session, le processus du gestionnaire de session (Smss.exe) commence par faire apparaitre une instance de lui-même au sein de cette session, à laquelle il passe le relais. Commence à partir de là le scénario préparatoire à l’emploi de toute nouvelle session, ce qui inclut le chargement d’un exemplaire propre à la session de Win32k.sys, la création de l’espace de noms de gestionnaire d’objets propre à la session, et la création des instances spécifiques à la session des processus Winlogon et Crsss - des processus Wininit et Crsss en ce qui concerne la session 0.

Ainsi que nous l’avons dit, l’une des premières tâches de Smms est de démarrer le sous-système Windows. À ce titre, le fait que l’un entre en scène avant l’autre constitue une particularité originale. Dépourvu en la circonstance des API Windows, dont l’exposition est justement assurée par le sous-système Windows, non fonctionnel à ce stade, Smss se présente sous les traits d’une application native, et n’utilise par conséquent que des API fondamentales de l’exécutif.

Processus système initial

Le processus système initial (baptisé System) est le réceptacle d’un genre particulier de threads, exécutés uniquement en mode noyau, auxquels il offre pour le compte du système d’exploitation des territoires communs, notamment l’espace d’adressage. (Plus de détails sur de tels entités, consultez la section Threads système du chapitre Processus et threads).

La variable noyau PsInitialSystemProcess mémorise l’adresse du bloc EPROCESS du processus System. La routine PsIsSystemProcess s’appuie sur ledit enregistrement pour vérifier qu’un processus est ou non le processus System.

Sous-système Windows

Environnement principal du système d’exploitation homonyme, le sous-système Windows exécute les applications, gère le clavier, la souris, l’écran et les dispositifs graphiques. Occupant une place spéciale parmi les autres environnements, le sous-système Windows remplit un rôle double, en ce sens qu’il fournit un support aux applications spécifiquement conçues pour Windows, et en plus, via gestion de divers aspects de l’expérience graphique, endosse l’identité visuelle des plateformes développées par Microsoft. Autre particularité majeure, il est à la base de tous les autres sous-systèmes.

Les composants clé du sous-système Windows sont les suivants :

  • Le processus du sous-système d’environnement (Csrss) administre l’état des applications exécutées sous son contrôle - soit, en réalité, l’ensemble des programmes exécutés en mode utilisateur. Il gère les fenêtres console (texte), la création et suppression des processus et des threads, les portions du support des autres sous-systèmes, et diverses autres fonctions.

  • Le pilote de périphérique mode noyau (Win32k.sys) héberge le gestionnaire de fenêtres, qui contrôle le fenêtrage (fenêtres, menus, etc.), les affichages écran et les saisies clavier-souris (et autres périphériques). Il contient également GDI (Graphics Device Interface), est une bibliothèque de fonctions pour périphériques de sortie graphique.

  • Les DLL de sous-système, telles Kernelbase.dll, Kernel32.dll, User32.dll et Advapi32.dll, implémentent les fonctions de l’API Windows et mettent en œuvre des interactions générales avec le processus du sous-système d’environnement. Elles traduisent les fonctions de l’API Windows en appels aux services système, exécutés en mode noyau, de Ntoskrnl.exe, et Win32k.sys.

Le processus de support via lequel apparaît le sous-système Windows s’appelle en interne Client/Server Run-Time Subsystem, ceci en référence au mode de communication à travers duquel il était initialement prévu que les applications communiquent. Dans la conception originelle de Windows, tous les sous-systèmes devaient être exécutés en tant que threads d’un processus de sous-système d’environnement commun au système, Csrss.exe. On fit ensuite des sous-systèmes POSIX et OS/2 des processus à part entière, sans pour autant modifier le nom de fichier du processus du sous-système Windows.

Le sous-système Windows classe les applications en deux catégories : les applications graphiques et celles fondées sur du texte (mode console). Aux applications graphiques est offert un ensemble d’objets et de contrôles standards (fenêtres, boutons, etc.) autour desquels construire et orienter le dialogue homme-machine. Une application à interface caractère, à laquelle le sous-système Windows fournit une représentation graphique, a sa sortie interactive dirigée vers une fenêtre texte. Chaque fois qu’une routine de sortie est appelée, le sous-système Windows appelle une routine pour afficher le texte dans la console associée. Cette façon de faire fonctionne pour toute les applications en ligne de commande.

Du fait de sa proximité avec les services de l’exécutif natif du système, et de son implication avec l’affichage graphique, le sous-système Windows est indispensable au bon fonctionnement de Windows. Sa présence étant obligatoire, les informations de démarrage le concernant le veulent toujours actif, alors que les autres sous-systèmes sont configurés pour être exécutés à la demande. Pour plus d’informations sur comment Windows démarre un sous-système, consultez la section Démarrage de sous-système.

Graphics Device Interface (GDI)

Jonction entre un système d’exploitation essentiellement graphique et des dispositifs d’affichage et systèmes d’impression de nature diverses, Graphics Device Interface (GDI) est une interface de Microsoft Windows pour la représentation d’objets graphiques ainsi que pour leur transmission aux périphériques de sortie, typiquement un écran ou une imprimante.

La fonction principale de GDI est le dessin d’éléments visuels primitif, à savoir pixels, lignes, polygones et bitmaps. (Un pixel est le plus petit élément constituant une image graphique ou une surface d’affichage ; une ligne est un ensemble de points arrangés de façon contiguë ; un polygone est un ensemble de lignes, placées bout à bout de manière à former une figure contiguë et fermée ; un bitmap est un ensemble de pixels arrangés dans une configuration rectangulaire, le tout constituant une forme, une image ou une texture reconnaissable.) GDI contient des fonctions de dessin de traits, de textes et de figures et des fonctions de gestion des palettes. En revanche, il n’est pas chargé de l’affichage des fenêtres, des menus et autres, cette tâche étant assignée au gestionnaire de fenêtres.

L’une des particularités remarquables du système GDI est son indépendance vis à vis des dispositifs physiques, cela au sens d’être capable de s’adapter à une gamme très étendue de combinaisons matérielles, incluant par exemple cartes graphiques et imprimantes. Avec cet objectif d’indépendance en vue, GDI fournit des mécanismes au travers desquels créer du contenu graphique sans considération pour le type, donc les caractéristiques, du matériel utilisé. Il devient alors simple, avec les mêmes instructions, de dessiner à l’écran, ou d’imprimer sur du papier. GDI connait également des moyens de stockage standardisés pour les images sur disque ou sur écran.

S’il est certain que l’émancipation de GDI en regard du matériel est un atout, une conséquence directe de cette indépendance est le manque relatif de performances au niveau de la vitesse d’exécution. En outre, GDI ne sait pas produire correctement des animations et ne supporte aucune fonctionnalité 3D, contrairement aux API DirectX et OpenGL, conçues pour exposer les fonctions matérielles 3D des cartes graphiques.

GDI est un composant mode noyau (win32k.sys), élevées au rang d’entités privilégiées afin de s’adresser directement au matériel et diminuer les temps de réaction de l’IHM. Complétant la politique globale du noyau quant à la couche matérielle, le système GDI offre des capacités de représentation abstraite des périphériques cibles et assure la cohérence du dessin sur des interfaces multiples.

SYSTEM_INFORMATION_CLASS

Table 11. SYSTEM_INFORMATION_CLASS
ID Classe Type de données associé

0x0000

SystemBasicInformation

SYSTEM_BASIC_INFORMATION

0x0001

SystemProcessorInformation

SYSTEM_PROCESSOR_INFORMATION

0x0002

SystemPerformanceInformation

SYSTEM_PERFORMANCE_INFORMATION

0x0003

SystemTimeOfDayInformation

SYSTEM_TIMEOFDAY_INFORMATION

0x0004

SystemPathInformation

0x0005

SystemProcessInformation

SYSTEM_PROCESS_INFORMATION

0x0006

SystemCallCountInformation

0x0007

SystemDeviceInformation

SYSTEM_DEVICE_INFORMATION

0x0008

SystemProcessorPerformanceInformation

SYSTEM_PROCESSOR_PERFORMANCE_INFORMATION

0x0009

SystemFlagsInformation

SYSTEM_FLAGS_INFORMATION

0x000A

SystemCallTimeInformation

0x000B

SystemModulesInformation

SYSTEM_MODULES_INFORMATION // RTL_PROCESS_MODULES

0x000C

SystemLocksInformation

RTL_PROCESS_LOCKS

0x000D

SystemStackTraceInformation

0x000E

SystemPagedPoolInformation

0x000F

SystemNonPagedPoolInformation

0x0010

SystemHandleInformation

SYSTEM_HANDLE_INFORMATION

0x0011

SystemObjectInformation

SYSTEM_OBJECT_INFORMATION, SYSTEM_OBJECTTYPE_INFORMATION

0x0012

SystemPageFileInformation

SYSTEM_PAGEFILE_INFORMATION

0x0013

SystemVdmInstemulInformation

0x0014

SystemVdmBopInformation

0x0015

SystemFileCacheInformation

SYSTEM_FILECACHE_INFORMATION

0x0016

SystemPoolTagInformation

SYSTEM_POOLTAG_INFORMATION

0x0017

SystemInterruptInformation

SYSTEM_INTERRUPT_INFORMATION

0x0018

SystemDpcBehaviorInformation

SYSTEM_DPC_BEHAVIOR_INFORMATION

0x0019

SystemFullMemoryInformation

0x001A

SystemLoadGdiDriverInformation

0x001B

SystemUnloadGdiDriverInformation

0x001C

SystemTimeAdjustmentInformation

SYSTEM_QUERY_TIME_ADJUST_INFORMATION, SYSTEM_SET_TIME_ADJUST_INFORMATION

0x001D

SystemSummaryMemoryInformation

0x001E

SystemMirrorMemoryInformation

0x001F

SystemPerformanceTraceInformation

0x0020

SystemCrashDumpInformation

0x0021

SystemExceptionInformation

SYSTEM_EXCEPTION_INFORMATION

0x0022

SystemCrashDumpStateInformation

0x0023

SystemKernelDebuggerInformation

SYSTEM_KERNEL_DEBUGGER_INFORMATION

0x0024

SystemContextSwitchInformation

SYSTEM_CONTEXT_SWITCH_INFORMATION

0x0025

SystemRegistryQuotaInformation

SYSTEM_REGISTRY_QUOTA_INFORMATION

0x0026

SystemExtendServiceTableInformation

0x0027

SystemPrioritySeperation

0x0028

SystemVerifierAddDriverInformation

0x0029

SystemVerifierRemoveDriverInformation

0x002A

SystemProcessorIdleInformation

SYSTEM_PROCESSOR_IDLE_INFORMATION

0x002B

SystemLegacyDriverInformation

0x002C

SystemCurrentTimeZoneInformation

RTL_TIME_ZONE_INFORMATION

0x002D

SystemLookasideInformation

0x002E

SystemTimeSlipNotification

0x002F

SystemSessionCreate

0x0030

SystemSessionDetach

0x0031

SystemSessionInformation

0x0032

SystemRangeStartInformation

0x0033

SystemVerifierInformation

0x0034

SystemVerifierThunkExtend

0x0035

SystemSessionProcessInformation

0x0036

SystemLoadGdiDriverInSystemSpace

0x0037

SystemNumaProcessorMap

0x0038

SystemPrefetcherInformation

0x0039

SystemExtendedProcessInformation

0x003A

SystemRecommendedSharedDataAlignment

0x003B

SystemComPlusPackage

0x003C

SystemNumaAvailableMemory

0x003D

SystemProcessorPowerInformation

SYSTEM_PROCESSOR_POWER_INFORMATION

0x003E

SystemEmulationBasicInformation

SYSTEM_BASIC_INFORMATION

0x003F

SystemEmulationProcessorInformation

SYSTEM_PROCESSOR_INFORMATION

0x0040

SystemExtendedHandleInformation

SYSTEM_HANDLE_INFORMATION_EX

0x0041

SystemLostDelayedWriteInformation

0x0042

SystemBigPoolInformation

SYSTEM_BIGPOOL_INFORMATION

0x0043

SystemSessionPoolTagInformation

SYSTEM_SESSION_PROCESS_INFORMATION

0x0044

SystemSessionMappedViewInformation

SYSTEM_SESSION_MAPPED_VIEW_INFORMATION

0x0045

SystemHotpatchInformation

0x0046

SystemObjectSecurityMode

0x0047

SystemWatchdogTimerHandler

0x0048

SystemWatchdogTimerInformation

0x0049

SystemLogicalProcessorInformation

0x004A

SystemWow64SharedInformationObsolete

0x004B

SystemRegisterFirmwareTableInformationHandler

0x004C

SystemFirmwareTableInformation

0x004D

SystemModuleInformationEx

RTL_PROCESS_MODULES

0x004E

SystemVerifierTriageInformation

0x004F

SystemSuperfetchInformation

0x0050

SystemMemoryListInformation

0x0051

SystemFileCacheInformationEx

0x0052

SystemThreadPriorityClientIdInformation

0x0053

SystemProcessorIdleCycleTimeInformation

0x0054

SystemVerifierCancellationInformation

0x0055

SystemProcessorPowerInformationEx

SYSTEM_FILECACHE_INFORMATION

0x0056

SystemRefTraceInformation

0x0057

SystemSpecialPoolInformation

0x0058

SystemProcessIdInformation

0x0059

SystemErrorPortInformation

0x005A

SystemBootEnvironmentInformation

SYSTEM_BOOT_ENVIRONMENT_INFORMATION

0x005B

SystemHypervisorInformation

0x005C

SystemVerifierInformationEx

0x005D

SystemTimeZoneInformation

0x005E

SystemImageFileExecutionOptionsInformation

0x005F

SystemCoverageInformation

0x0060

SystemPrefetchPatchInformation

0x0061

SystemVerifierFaultsInformation

0x0062

SystemSystemPartitionInformation

0x0063

SystemSystemDiskInformation

0x0064

SystemProcessorPerformanceDistribution

0x0065

SystemNumaProximityNodeInformation

0x0066

SystemDynamicTimeZoneInformation

0x0067

SystemCodeIntegrityInformation

0x0068

SystemProcessorMicrocodeUpdateInformation

0x0069

SystemProcessorBrandString

0x006A

SystemVirtualAddressInformation

0x006B

SystemLogicalProcessorAndGroupInformation

0x006C

SystemProcessorCycleTimeInformation

0x006D

SystemStoreInformation

0x006E

SystemRegistryAppendString

0x006F

SystemAitSamplingValue

0x0070

SystemVhdBootInformation

0x0071

SystemCpuQuotaInformation

PS_CPU_QUOTA_QUERY_INFORMATION

0x0072

SystemNativeBasicInformation

0x0073

SystemErrorPortTimeouts

0x0074

SystemLowPriorityIoInformation

0x0075

SystemBootEntropyInformation

0x0076

SystemVerifierCountersInformation

0x0077

SystemPagedPoolInformationEx

0x0078

SystemSystemPtesInformationEx

0x0079

SystemNodeDistanceInformation

0x007A

SystemAcpiAuditInformation

0x007B

SystemBasicPerformanceInformation

SYSTEM_BASIC_PERFORMANCE_INFORMATION

0x007C

SystemQueryPerformanceCounterInformation

0x007D

SystemSessionBigPoolInformation

0x007E

SystemBootGraphicsInformation

0x007F

SystemScrubPhysicalMemoryInformation

0x0080

SystemBadPageInformation

0x0081

SystemProcessorProfileControlArea

0x0082

SystemCombinePhysicalMemoryInformation

0x0083

SystemEntropyInterruptTimingInformation

0x0084

SystemConsoleInformation

0x0085

SystemPlatformBinaryInformation

0x0086

SystemThrottleNotificationInformation

0x0087

SystemHypervisorProcessorCountInformation

0x0088

SystemDeviceDataInformation

0x0089

SystemDeviceDataEnumerationInformation

0x008A

SystemMemoryTopologyInformation

0x008B

SystemMemoryChannelInformation

0x008C

SystemBootLogoInformation

0x008D

SystemProcessorPerformanceInformationEx

SYSTEM_PROCESSOR_PERFORMANCE_INFORMATION_EX

0x008E

SystemSpare0

0x008F

SystemSecureBootPolicyInformation

0x0090

SystemPageFileInformationEx

0x0091

SystemSecureBootInformation

0x0092

SystemEntropyInterruptTimingRawInformation

0x0093

SystemPortableWorkspaceEfiLauncherInformation

0x0094

SystemFullProcessInformation

0x0095

SystemKernelDebuggerInformationEx

0x0096

SystemBootMetadataInformation

0x0097

SystemSoftRebootInformation

0x0098

SystemElamCertificateInformation

0x0099

SystemOfflineDumpConfigInformation

0x009a

SystemProcessorFeaturesInformation

0x009b

SystemRegistryReconciliationInformation

SYSTEM_BASIC_INFORMATION
typedef struct _SYSTEM_BASIC_INFORMATION {
    ULONG Reserved;
    ULONG TimerResolution;
    ULONG PageSize;
    ULONG NumberOfPhysicalPages;
    ULONG LowestPhysicalPageNumber;
    ULONG HighestPhysicalPageNumber;
    ULONG AllocationGranularity;
    ULONG MinimumUserModeAddress;
    ULONG MaximumUserModeAddress;
    KAFFINITY ActiveProcessorsAffinityMask;
    CHAR NumberOfProcessors;
} SYSTEM_BASIC_INFORMATION, *PSYSTEM_BASIC_INFORMATION;
Table 12. Valeurs initiales des champs de la structure SYSTEM_BASIC_INFORMATION
Champ Valeur initiale

ActiveProcessorsAffinityMask

KeActiveProcessors

HighestPhysicalPageNumber

MmHighestPhysicalPage

LowestPhysicalPageNumber

MmLowestPhysicalPage

MaximumUserModeAddress

MmHighestUserAddress

NumberOfProcessors

KeNumberProcessors

NumberOfPhysicalPages

MmNumberOfPhysicalPages

TimerResolution

KeMaximumIncrement

SYSTEM_BOOT_ENVIRONMENT_INFORMATION
typedef struct _SYSTEM_BOOT_ENVIRONMENT_INFORMATION
{
    GUID BootIdentifier;
    FIRMWARE_TYPE FirmwareType;
    ULONGLONG BootFlags;
} SYSTEM_BOOT_ENVIRONMENT_INFORMATION, PSYSTEM_BOOT_ENVIRONMENT_INFORMATION;
Table 13. Valeurs initiales des champs de la structure SYSTEM_BOOT_ENVIRONMENT_INFORMATION
Champ Valeur initiale

BootFlags

LOADER_PARAMETER_EXTENSION BootFlags

BootIdentifier

LOADER_PARAMETER_EXTENSION BootIdentifier

SYSTEM_PROCESSOR_INFORMATION
typedef struct _SYSTEM_PROCESSOR_INFORMATION {
    USHORT ProcessorArchitecture;
    USHORT ProcessorLevel;
    USHORT ProcessorRevision;
    USHORT MaximumProcessors;
    ULONG ProcessorFeatureBits;
} SYSTEM_PROCESSOR_INFORMATION, *PSYSTEM_PROCESSOR_INFORMATION;
Table 14. Valeurs initiales des champs de la structure SYSTEM_PROCESSOR_INFORMATION
Champ Valeur initiale

ProcessorArchitecture

KeProcessorArchitecture

ProcessorLevel

KeProcessorLevel

ProcessorRevision

KeProcessorRevision;

ProcessorFeatureBits

KeFeatureBits;

SYSTEM_PERFORMANCE_INFORMATION
typedef struct _SYSTEM_PERFORMANCE_INFORMATION {
    LARGE_INTEGER IdleProcessTime;
    LARGE_INTEGER IoReadTransferCount;
    LARGE_INTEGER IoWriteTransferCount;
    LARGE_INTEGER IoOtherTransferCount;
    ULONG IoReadOperationCount;
    ULONG IoWriteOperationCount;
    ULONG IoOtherOperationCount;
    ULONG AvailablePages;
    ULONG CommittedPages;
    ULONG CommitLimit;
    ULONG PeakCommitment;
    ULONG PageFaultCount;
    ULONG CopyOnWriteCount;
    ULONG TransitionCount;
    ULONG CacheTransitionCount;
    ULONG DemandZeroCount;
    ULONG PageReadCount;
    ULONG PageReadIoCount;
    ULONG CacheReadCount;
    ULONG CacheIoCount;
    ULONG DirtyPagesWriteCount;
    ULONG DirtyWriteIoCount;
    ULONG MappedPagesWriteCount;
    ULONG MappedWriteIoCount;
    ULONG PagedPoolPages;
    ULONG NonPagedPoolPages;
    ULONG PagedPoolAllocs;
    ULONG PagedPoolFrees;
    ULONG NonPagedPoolAllocs;
    ULONG NonPagedPoolFrees;
    ULONG FreeSystemPtes;
    ULONG ResidentSystemCodePage;
    ULONG TotalSystemDriverPages;
    ULONG TotalSystemCodePages;
    ULONG NonPagedPoolLookasideHits;
    ULONG PagedPoolLookasideHits;
    ULONG AvailablePagedPoolPages;
    ULONG ResidentSystemCachePage;
    ULONG ResidentPagedPoolPage;
    ULONG ResidentSystemDriverPage;
    ULONG CcFastReadNoWait;
    ULONG CcFastReadWait;
    ULONG CcFastReadResourceMiss;
    ULONG CcFastReadNotPossible;
    ULONG CcFastMdlReadNoWait;
    ULONG CcFastMdlReadWait;
    ULONG CcFastMdlReadResourceMiss;
    ULONG CcFastMdlReadNotPossible;
    ULONG CcMapDataNoWait;
    ULONG CcMapDataWait;
    ULONG CcMapDataNoWaitMiss;
    ULONG CcMapDataWaitMiss;
    ULONG CcPinMappedDataCount;
    ULONG CcPinReadNoWait;
    ULONG CcPinReadWait;
    ULONG CcPinReadNoWaitMiss;
    ULONG CcPinReadWaitMiss;
    ULONG CcCopyReadNoWait;
    ULONG CcCopyReadNoWaitMiss;
    ULONG CcCopyReadWaitMiss;
    ULONG CcMdlReadNoWait;
    ULONG CcMdlReadWait;
    ULONG CcMdlReadNoWaitMiss;
    ULONG CcMdlReadWaitMiss;
    ULONG CcReadAheadIos;
    ULONG CcLazyWriteIos;
    ULONG CcLazyWritePages;
    ULONG CcDataFlushes;
    ULONG CcDataPages;
    ULONG ContextSwitches;
    ULONG FirstLevelTbFills;
    ULONG SecondLevelTbFills;
    ULONG SystemCalls;
} SYSTEM_PERFORMANCE_INFORMATION, *PSYSTEM_PERFORMANCE_INFORMATION;
Table 15. Valeurs initiales des champs de la structure SYSTEM_PERFORMANCE_INFORMATION
Champ Valeur initiale

AvailablePages = MmAvailablePages

CacheIoCount

KPRCB MmCacheIoCount

CacheReadCount

KPRCB MmCacheReadCount

CacheTransitionCount

KPRCB MmCacheTransitionCount

CommitLimit

MmTotalCommitLimit

CommittedPages

MmTotalCommittedPages

ContextSwitches

KPRCB KeContextSwitches

CopyOnWriteCount

KPRCB MmCopyOnWriteCount

DemandZeroCount

KPRCB MmDemandZeroCount

DirtyPagesWriteCount

KPRCB MmDirtyPagesWriteCount

DirtyWriteIoCount

KPRCB MmDirtyWriteIoCount

MappedPagesWriteCount

KPRCB MmMappedPagesWriteCount

MappedWriteIoCount

KPRCB MmMappedWriteIoCount

PageFaultCount

KPRCB MmPageFaultCount

PageReadCount

KPRCB MmPageReadCount

PageReadIoCount

KPRCB MmPageReadIoCount

PeakCommitment

MmPeakCommitment

ResidentPagedPoolPage

MmPagedPoolPage

ResidentSystemCodePage

MmSystemCodePage

ResidentSystemCachePage

MmSystemCachePage

ResidentSystemDriverPage

MmSystemDriverPage

SystemCalls

KPRCB KeSystemCalls

TransitionCount

SYSTEM_TIMEOFDAY_INFORMATION
typedef struct _SYSTEM_TIMEOFDAY_INFORMATION {
    LARGE_INTEGER BootTime;
    LARGE_INTEGER CurrentTime;
    LARGE_INTEGER TimeZoneBias;
    ULONG TimeZoneId;
    ULONG Reserved;
    ULONGLONG BootTimeBias;
    ULONGLONG SleepTimeBias;
} SYSTEM_TIMEOFDAY_INFORMATION, *PSYSTEM_TIMEOFDAY_INFORMATION;
Table 16. Valeurs initiales des champs de la structure SYSTEM_TIMEOFDAY_INFORMATION
Champ Valeur initiale

CurrentTime

KeQuerySystemTime

BootTime

KeBootTime

TimeZoneBias

ExpTimeZoneBias

TimeZoneId

ExpCurrentTimeZoneId

BootTimeBias

KeBootTimeBias

SYSTEM_PROCESSOR_IDLE_INFORMATION
typedef struct _SYSTEM_PROCESSOR_IDLE_INFORMATION {
    ULONGLONG IdleTime;
    ULONGLONG C1Time;
    ULONGLONG C2Time;
    ULONGLONG C3Time;
    ULONG     C1Transitions;
    ULONG     C2Transitions;
    ULONG     C3Transitions;
    ULONG     Padding;
} SYSTEM_PROCESSOR_IDLE_INFORMATION, *PSYSTEM_PROCESSOR_IDLE_INFORMATION;
Table 17. Valeurs initiales des champs de la structure SYSTEM_PROCESSOR_IDLE_INFORMATION
Champ Valeur initiale

IdleTime

KPRCB IdleThread.KernelTime

C1Time

KPCB PowerState.TotalIdleStateTime[0]

C2Time

KPCB PowerState.TotalIdleStateTime[1]

C3Time

KPCB PowerState.TotalIdleStateTime[2]

C1Transitions

KPCB PowerState.TotalIdleTransitions[0]

C2Transitions

KPCB PowerState.TotalIdleTransitions[1]

C3Transitions

KPCB PowerState.TotalIdleTransitions[2]

SYSTEM_DEVICE_INFORMATION
typedef struct _SYSTEM_DEVICE_INFORMATION {
    ULONG NumberOfDisks;
    ULONG NumberOfFloppies;
    ULONG NumberOfCdRoms;
    ULONG NumberOfTapes;
    ULONG NumberOfSerialPorts;
    ULONG NumberOfParallelPorts;
} SYSTEM_DEVICE_INFORMATION, *PSYSTEM_DEVICE_INFORMATION;
SYSTEM_PROCESSOR_PERFORMANCE_INFORMATION
typedef struct _SYSTEM_PROCESSOR_PERFORMANCE_INFORMATION {
{
    LARGE_INTEGER IdleTime;
    LARGE_INTEGER KernelTime;
    LARGE_INTEGER UserTime;
    LARGE_INTEGER DpcTime;
    LARGE_INTEGER InterruptTime;
    ULONG InterruptCount;
} SYSTEM_PROCESSOR_PERFORMANCE_INFORMATION, *PSYSTEM_PROCESSOR_PERFORMANCE_INFORMATION;
Table 18. Valeurs initiales des champs de la structure SYSTEM_PROCESSOR_IDLE_INFORMATION
Champ Valeur initiale

DpcTime

KPRCB DpcTime

IdleTime

KPRCB IdleThread.KernelTime

InterruptCount

KPRCB InterruptCount

InterruptTime

KPRCB InterruptTime

KernelTime

KPRCB KernelTime

UserTime

KPRCB UserTime

SYSTEM_QUERY_TIME_ADJUST_INFORMATION
typedef struct _SYSTEM_QUERY_TIME_ADJUST_INFORMATION {
    ULONG TimeAdjustment;
    ULONG TimeIncrement;
    BOOLEAN Enable;
} SYSTEM_QUERY_TIME_ADJUST_INFORMATION, *PSYSTEM_QUERY_TIME_ADJUST_INFORMATION;
SYSTEM_SET_TIME_ADJUST_INFORMATION
typedef struct _SYSTEM_SET_TIME_ADJUST_INFORMATION {
    ULONG TimeAdjustment;
    BOOLEAN Enable;
} SYSTEM_SET_TIME_ADJUST_INFORMATION, *PSYSTEM_SET_TIME_ADJUST_INFORMATION;
SYSTEM_PROCESS_INFORMATION
typedef struct _SYSTEM_PROCESS_INFORMATION
{
    ULONG NextEntryOffset;
    ULONG NumberOfThreads;
    LARGE_INTEGER WorkingSetPrivateSize; // since VISTA
    ULONG HardFaultCount; // since WIN7
    ULONG NumberOfThreadsHighWatermark; // since WIN7
    ULONGLONG CycleTime; // since WIN7
    LARGE_INTEGER CreateTime;
    LARGE_INTEGER UserTime;
    LARGE_INTEGER KernelTime;
    UNICODE_STRING ImageName;
    KPRIORITY BasePriority;
    HANDLE UniqueProcessId;
    HANDLE InheritedFromUniqueProcessId;
    ULONG HandleCount;
    ULONG SessionId;
    ULONG_PTR UniqueProcessKey; // since VISTA (requires SystemExtendedProcessInformation)
    SIZE_T PeakVirtualSize;
    SIZE_T VirtualSize;
    ULONG PageFaultCount;
    SIZE_T PeakWorkingSetSize;
    SIZE_T WorkingSetSize;
    SIZE_T QuotaPeakPagedPoolUsage;
    SIZE_T QuotaPagedPoolUsage;
    SIZE_T QuotaPeakNonPagedPoolUsage;
    SIZE_T QuotaNonPagedPoolUsage;
    SIZE_T PagefileUsage;
    SIZE_T PeakPagefileUsage;
    SIZE_T PrivatePageCount;
    LARGE_INTEGER ReadOperationCount;
    LARGE_INTEGER WriteOperationCount;
    LARGE_INTEGER OtherOperationCount;
    LARGE_INTEGER ReadTransferCount;
    LARGE_INTEGER WriteTransferCount;
    LARGE_INTEGER OtherTransferCount;
} SYSTEM_PROCESS_INFORMATION, *PSYSTEM_PROCESS_INFORMATION;
SYSTEM_FLAGS_INFORMATION
typedef struct _SYSTEM_FLAGS_INFORMATION
{
    ULONG Flags; // NtGlobalFlag
} SYSTEM_FLAGS_INFORMATION, *PSYSTEM_FLAGS_INFORMATION;
SYSTEM_PROCESSOR_POWER_INFORMATION
typedef struct _SYSTEM_PROCESSOR_POWER_INFORMATION
{
    UCHAR CurrentFrequency;
    UCHAR ThermalLimitFrequency;
    UCHAR ConstantThrottleFrequency;
    UCHAR DegradedThrottleFrequency;
    UCHAR LastBusyFrequency;
    UCHAR LastC3Frequency;
    UCHAR LastAdjustedBusyFrequency;
    UCHAR ProcessorMinThrottle;
    UCHAR ProcessorMaxThrottle;
    ULONG NumberOfFrequencies;
    ULONG PromotionCount;
    ULONG DemotionCount;
    ULONG ErrorCount;
    ULONG RetryCount;
    ULONGLONG CurrentFrequencyTime;
    ULONGLONG CurrentProcessorTime;
    ULONGLONG CurrentProcessorIdleTime;
    ULONGLONG LastProcessorTime;
    ULONGLONG LastProcessorIdleTime;
} SYSTEM_PROCESSOR_POWER_INFORMATION, *PSYSTEM_PROCESSOR_POWER_INFORMATION;
SYSTEM_PAGEFILE_INFORMATION
typedef struct _SYSTEM_PAGEFILE_INFORMATION {
    ULONG NextEntryOffset;
    ULONG TotalSize;
    ULONG TotalInUse;
    ULONG PeakUsage;
    UNICODE_STRING PageFileName;
} SYSTEM_PAGEFILE_INFORMATION, *PSYSTEM_PAGEFILE_INFORMATION;
SYSTEM_FILECACHE_INFORMATION
typedef struct _SYSTEM_FILECACHE_INFORMATION
{
    SIZE_T CurrentSize;
    SIZE_T PeakSize;
    ULONG PageFaultCount;
    SIZE_T MinimumWorkingSet;
    SIZE_T MaximumWorkingSet;
    SIZE_T CurrentSizeIncludingTransitionInPages;
    SIZE_T PeakSizeIncludingTransitionInPages;
    ULONG TransitionRePurposeCount;
    ULONG Flags;
} SYSTEM_FILECACHE_INFORMATION, *PSYSTEM_FILECACHE_INFORMATION;
SYSTEM_DPC_BEHAVIOR_INFORMATION
typedef struct _SYSTEM_DPC_BEHAVIOR_INFORMATION
{
    ULONG Reserved;
    ULONG DpcQueueDepth;
    ULONG MinimumDpcRate;
    ULONG AdjustDpcThreshold;
    ULONG IdealDpcRate;
} SYSTEM_DPC_BEHAVIOR_INFORMATION, *PSYSTEM_DPC_BEHAVIOR_INFORMATION;
SYSTEM_INTERRUPT_INFORMATION
typedef struct _SYSTEM_INTERRUPT_INFORMATION {
    ULONG ContextSwitches;
    ULONG DpcCount;
    ULONG DpcRate;
    ULONG TimeIncrement;
    ULONG DpcBypassCount;
    ULONG ApcBypassCount;
} SYSTEM_INTERRUPT_INFORMATION, *PSYSTEM_INTERRUPT_INFORMATION;
RTL_PROCESS_MODULES
typedef struct _RTL_PROCESS_MODULES {
    ULONG NumberOfModules;
    RTL_PROCESS_MODULE_INFORMATION Modules[1];
} RTL_PROCESS_MODULES, *PRTL_PROCESS_MODULES;
RTL_PROCESS_MODULE_INFORMATION
typedef struct _RTL_PROCESS_MODULE_INFORMATION {
    HANDLE Section;
    PVOID MappedBase;
    PVOID ImageBase;
    ULONG ImageSize;
    ULONG Flags;
    USHORT LoadOrderIndex;
    USHORT InitOrderIndex;
    USHORT LoadCount;
    USHORT OffsetToFileName;
    UCHAR  FullPathName[256];
} RTL_PROCESS_MODULE_INFORMATION, *PRTL_PROCESS_MODULE_INFORMATION;
SYSTEM_HANDLE_INFORMATION
typedef struct _SYSTEM_HANDLE_INFORMATION {
    ULONG NumberOfHandles;
    SYSTEM_HANDLE_TABLE_ENTRY_INFO Handles[1];
} SYSTEM_HANDLE_INFORMATION, *PSYSTEM_HANDLE_INFORMATION;
SYSTEM_HANDLE_TABLE_ENTRY_INFO
typedef struct _SYSTEM_HANDLE_TABLE_ENTRY_INFO {
    USHORT UniqueProcessId;
    USHORT CreatorBackTraceIndex;
    UCHAR ObjectTypeIndex;
    UCHAR HandleAttributes;
    USHORT HandleValue;
    PVOID Object;
    ULONG GrantedAccess;
} SYSTEM_HANDLE_TABLE_ENTRY_INFO, *PSYSTEM_HANDLE_TABLE_ENTRY_INFO;

NUMA

Autre type de systèmes multi processeur reconnue par Windows : NUMA (Non Uniform Memory Access), laquelle topologie permet de regrouper les processeurs en unités de plus large échelle appelées noeuds. Chaque noeud a ses propres processeurs, canaux d’E/S et sa propre mémoire, et est relié au système global par l’intermédiaire d’un bus d’interconnexion.

Les systèmes NUMA sont dits non uniformes au sens où, vis à vis de chaque processeur, les temps d’accès diffèrent selon la mémoire accédée. Tous les processeurs de tous les noeuds peuvent accéder à toute la mémoire (avec un même espace d adressage), mais les accès à la mémoire du noeud sont plus rapides.

L’objectif fondamental suivi par NUMA est de pallier les limites des configurations SMP, dans lesquelles le couplage étroit entre les processeurs et le reste du système (en réalité la compétition que ce schéma implique, supportée du reste par un unique bus) augmente considérablement la charge sur l’interconnexion, et diminue les performances.

Table 19. Opérations concernant NUMA
Opération Fonction Service Routine

Récupérer le noeud qui a le numéro le plus élevé

GetNumaHighestNodeNumber

NtQuerySystemInformation (SystemNumaProcessorMap)

KeQueryHighestNodeNumber

Récupérer le masque processeur d’un noeud

GetNumaNodeProcessorMask

NtQuerySystemInformation (SystemNumaProcessorMap)

Récupérer le numéro de noeud d’un processeur

GetNumaProcessorNode

NtQuerySystemInformation (SystemNumaProcessorMap)

Obtenir la quantité de mémoire disponible dans un noeud

GetNumaAvailableMemoryNode

NtQuerySystemInformation (SystemNumaAvailableMemory)

ExpQueryNumaAvailableMemory

Obtenir le numéro de noeud sur lequel s’exécute l’appelant

KeGetCurrentNodeNumber

Initialiser les structures noyau requises pour le support des systèmes NUMA.

s/o

s/o

KeNumaInitialize

Obtenir le masque d’affinité d’un noeud

KeQueryNodeActiveAffinity

Table 20. Variables noyau concernant NUMA
Variable Type Description

ExNode0

KeNodeBlock

PKNODE

KeNumberNodes

UCHAR

Voir routine KeQueryHighestNodeNumber

Hyperthread

Hyperthread est une technologie Intel qui créé plusieurs processeurs logiques (en l’occurrence deux) sur un même processeur physique. Chaque processeur a son propre état CPU (registres de données et de contrôle), mais le moteur d’exécution, le cache matériel et le bus système sont partagés. Cela permet à un coeur de processeur physique d’agir essentiellement tel un duo logique, et en définitive d’exécuter deux applications indépendantes en même temps.

Bien qu’hyperthread ne double pas les performances d’un système, il peut les optimiser en exploitant mieux les ressources oisives. Ainsi, un CPU logique peut mener de l’avant diverses opérations tandis que les autres CPU logiques sont occupés. Gardez cependant à l’esprit que les gains en performances apportées par Hyperthread dépendent étroitement du contexte applicatif.

Dans une configuration hyperthread, les processeurs logiques situés sur le même coeur possèdent des numéros de CPU consécutifs: les CPU 0 et 1 se trouvent tous deux sur le premier coeur, les CPU 2 et 3 sur le second coeur, et ainsi de suite.

Les algorithmes d’ordonnancement de Windows ont été conçus de telle sorte à tirer le meilleur parti des systèmes hyperthread, tout en prenant en compte leurs limites. Ainsi, considérant qu’une unité de calcul logique ne peut rivaliser avec une physique, Windows emploie hyperthread que si la charge de travail le justifie.

Indépendamment de la version de Windows qui anime l’ordinateur, les processeurs logiques, compte tenu de leur nature, n’entrent pas en ligne de compte au niveau de la licence d’utilisation. Ainsi, par exemple, sur un système hyperthread mono processeur, une version de Windows limitée à un processeur utilisera les deux processeurs logiques disponibles.

Multitraitement

Le multitraitement désigne l’aptitude du système d’exploitation à utiliser les processeurs présents dans la station de travail en vue de mener de l’avant l’exécution des threads. Dans le scénario idéal, Windows peut traiter simultanément autant de threads qu’il existe de processeurs sur la machine.

Windows est un système d’exploitation SMP (Symetric MultiProcessing), ce qui signifie que le système et les threads utilisateur peuvent prendre place sur n’importe quel processeur. Ce modèle s’oppose à un autre, à savoir ASMP, (ASymetric MultiProcessing), qui consiste à réserver un processeur à l’usage exclusif du système, les autres processeurs exécutant en ces circonstances le code utilisateur.

Les versions 32 bits de Windows peuvent gérer 32 processeurs, et les versions 64 bits 64 processeurs. (Deux nombres qui découlent directement de la taille native d’un mot machine au sein de ces architectures.) Dans les faits, le nombre réel de processeurs gérés dépend de l’édition de Windows qu’exécute l’ordinateur.

Les versions 64 bits de Windows apparues depuis Windows Vista et Windows Server 2008 s’appuient sur un noyau unifiée qui prend indistinctement en charge les systèmes mono processeur et les systèmes multi processeur. Comparativement aux versions antérieures de Windows, qui comportaient des versions distinctes du noyau et de la couche d’abstraction matérielle pour chaque type de machine, cette modification a pris place conformément au fait que la plus grande partie des configurations parmi le paysage informatique moderne ont au moins deux coeurs (logiques sinon physiques). Les versions 32 bits incorporent quand à elle toujours deux versions du noyau : une compatible PAE (avec en filigrane la prise en charge de la mémoire marquée non exécutable, qui dépend étroitement de ce support), et l’autre dont la fonctionnalité est absente.

Multitâche

Le multitâche est le procédé via lequel Windows (ainsi, du reste, que tout autre système d’exploitation) partage un processeur unique entre de multiples threads.

L’aptitude d’un système à fonctionner en traitement multitâche est indépendante du nombre de processeurs que renferme l’ordinateur. Une configuration multi processeur (ou multi coeur) n’est de ce fait pas nécessaire pour bénéficier d’une telle opportunité.

On distingue pour la mise en oeuvre du multitâche deux modèles : coopératif et préemptif, l’un comme l’autre relevant d’une approche distincte, dont ils sont en définitive la concrétisation.

Dans la perspective du multitâche coopératif, chaque application qui s’exécute doit explicitement libérer le processeur sur lequel elle est installée, permettant de la sorte à une autre application dans la file d’attente de disposer à son tour du processeur.

Les principaux atouts du multitâche coopératif consistent en une simplification des rapports entre système et applications d’un coté, et entre applications et ressources partagées d’un autre. Compte tenu dans cette configuration de la main-mise qu’a une application sur le processeur (application dont dépend, en toute fin, le prochain basculement basculement de contexte), il est dès lors plus facile de garantir l’indivisibilité des séquences de traitement (sections critiques). Si une interruption peut toujours survenir, la séquence d’instructions en cours reprendra automatiquement son exécution au point où elle a été interrompu. Le mode coopératif présente cependant plusieurs inconvénients, le plus évident étant que rien ne garantit qu’une application ne mobilisera pas le processeur au détriment des autres. Pour cette raison, La forme coopérative est en pratique rarement utilisée (du moins pas sous son aspect le plus strict). Elle l’a été dans les produits Microsoft Windows jusque dans Windows 3.X.

Avec le multitâche préemptif, chaque application occupe le processeur pendant un laps de temps prédéfini ou jusqu’à ce que la priorité d’une autre application devienne supérieure à la sienne. Dans une tel scénario, l’attribution de temps processeur pour les applications est fait par le système d’exploitation, lui assurant ainsi un droit de préemption inaliénable.

Dans l’éventualité où tous les threads d’un processus ont la même charge de travail (ce qui n’est généralement pas le cas), le multitâche préemptif permet une répartition équitable du temps processeur (principe du temps partagé).

Mécanismes système

Particulièrement riche sur le plan des technologies et des services rendus afférant, Windows offre à cet égard kyrielle de dispositifs globaux sur lesquels s’appuient les composants mode noyau, tels que l’exécutif et les pilotes de périphérique, ainsi que ceux exécutés en mode utilisateur, y compris applications et processus de support. Dans ce chapitre, nous allons passer à la loupe les mécanismes système que voici :

  • Flags Windows globaux

  • Options d’exécution d’image

  • Windows on Windows, incluant Wow32 et Wow64

  • Windows Resource Protection

Windows on Windows

Windows on Windows, ou plus simplement Wow, désigne une infrastructure par laquelle le système d’exploitation présente ses services de manière analogue aux versions de Windows conçues par le passé, dont l’information élémentaire était traité sous forme de donnes 16, puis 32 bits - cela conditionnant bon nombre de comportements internes et de surfaces logicielles exposées. C’est via l’approche Wow (et avec elle, ainsi que nous allons les voir dans cette section, diverses techniques) que Windows 32 bits est capable de reproduire les conditions attendues par des programmes écrits pour Windows 95 et Windows 98, voire Windows 3.1 (lui-même reposant sur MS-DOS), et, dans la même veine, que Windows 64 bits permet l’exécution d’applications x86 32 bits.

Historique de Windows on Windows

Windows évoluant au rythme des avancées technologiques et en fonction de la largeur des registres internes du processeur pour la manipulation des données, Wow a d’abord commencé en tant qu’appui aux programmes 16 bits exécutés dans Windows NT, premier système d’exploitation de la gamme à être entièrement 32 bits. Par la suite, avec l’introduction des processeurs 64 bits et la diminution subséquente de l’utilisation de l’informatique 32 bits (32 bits et 64 bits faisant ici référence non seulement à la façon dont le processeur traite les informations, mais aussi comment système et logiciels tirent profit de ces ressources), le terme Windows sur Windows a changé de connotation et se réfère aujourd’hui à la capacité du système d’exploitation 64 bits à exécuter côte à côte des processus Win32 et Win64. Notez, en ce qui concerne l’écosystème logiciel, que Wow vise moins à conserver l’existant qu’à préparer l’avenir. Que ce soit pour les utilisateurs, les concepteurs de logiciel ou les administrateurs système, il n’existe aucune raison de refuser les changements induits par le passage au 64 bits.

Wow32

Imitation des conditions attendues par les programmes écrits pour Windows 3.1, dernière version 16 bits d’un système d’exploitation Microsoft, et la dernière aussi à se reposer sur MS-DOS, l’environnement d’exécution Windows 16 bits est supporté par le biais d’une couche intermédiaire, dévolue à la compatibilité, appelée Windows sur Windows (WOW32, Windows on Windows 32-bits), laquelle intègre et étend les technologies permettant d’exécuter des programmes MS-DOS (NTVDM).

L’environnement Windows 16 bits est disponible dans les diverses éditions 32 bits de Microsoft Windows, dont Windows NT, 2000, XP, Serveur 2003, Vista, Serveur 2008, 7, 8 et 10. Les versions 64 bits de Windows, en revanche, n’incluent pas de couche d’émulation pour le code 16 bits, et ne peuvent donc pas exécuter des applications Win16.

Considérations sur la compatibilité 16 bits

Si les programmes 16 bits semblent a priori avoir disparus du paysage informatique contemporain (soit près de 20 ans après la sortie du premier Windows 32 bits), quelques cas persistent où ce type d’applications intervient encore. Certains jeux, par exemple, développés pour les anciens systèmes Microsoft peuvent ne pas fonctionner correctement sur des systèmes d’exploitation plus récents. La sphère professionnelle, elle aussi, abrite encore potentiellement un certain nombre d’applications métiers héritées 16 bits.

Historiquement, les produits Windows de la famille 9x, basée sur Windows 95 et qui maintient un ancrage très fort sur MS-DOS, peuvent exécuter des applications 16 bits sans problèmes majeurs, ces systèmes s’appuyant en réalité sur un noyau hybride 16/32 bits. Avec Windows NT, Microsoft a implanté au sein de ses systèmes le dispositif Windows on Windows (WoW) qui permet de créer un environnement 16 bits pour les anciens programmes, cela alors que le système repose sur des fondations entièrement 32 bits.

Windows 64bits n’assure plus la compatibilité avec les programmes 16 bits. On aura donc recours pour l’occasion à des applications tierces. DOSBox, par exemple, est un émulateur simulant un environnement compatible DOS sous Windows dans le but d’exécuter des programmes conçus pour ce système. Autre exemple, VMware, une gamme de logiciels liés à la virtualisation d’architectures x86. Avec les systèmes 64 bits, le WoW original (Wow32) n’est plus présent, remplacé au même poste par WoW64, qui permet de lancer des applications 32 bits, très courantes, sur un système 64 bits.

Limitations et restrictions concernant Wow32

La machine virtuelle Windows 16 bits, et c’est son but, ressemble à Windows 3.1 par bien des aspects, mais présente du coup les mêmes limites. Une seule application Win16 peut fonctionner à la fois, les applications ne possèdent qu’un seul thread, elles résident dans le même espace d’adressage et partagent toutes la même file d’attente d’entrée. Cela implique qu’une application qui subit un dysfonctionnement peut affecter défavorablement toutes les autres applications s’exécutant dans le même environnement Win16. Par exemple, si une application ne libère pas le processeur, aucune autre ne peut y accéder, ou si une application bloque l’arrivée d’entrées, toutes les autres en sont privées. De plus, une application Win16 peut faire échouer toutes les autres en corrompant l’espace d’adressage commun.

La résolution des problèmes de comptabilité issus de certaines applications spécifiques 16 bits se trouvent à d’autres niveau que l’espace d’adressage ou le modèle mémoire utilisé, incluant les noms de fichiers longs (noms qui ne sont pas conforment à la convention 8.3), la multi utilisation ou le concept de moindre privilège. Eloignées du domaine de compétences de WOW32, ces questions ont pour quelques-unes une réponse, ou sont au moins (autant qu’il est possible de le faire) prises en compte. Par exemple, lorsque vous enregistrez un fichier avec un nom de fichier long vers un lecteur NTFS, NTFS crée, par défaut, une seconde entrée de répertoire de fichier avec un nom de fichier court conforme à la convention 8.3.

Si cette limite a moins le caractère critique des précédentes, il n’existe aucune mémoire partagée entre les applications qui s’exécutent dans le programme WOW et les autres applications sous Windows. Les applications Win16 ne peuvent pas appeler de fonctions incluses dans les bibliothèques 32 bits et les applications pour Windows ne peuvent pas appeler des DLL Win16.

Wow64

Les déclinaisons de Windows calibrées pour l’architecture matérielle x64 utilisent des adresses et le jeu d’instructions 64 bits de ces plateformes. Ainsi, et même en considérant l’inclusion dans la famille de processeurs x64 d’un support natif pour l’exécution d’applications x86 en utilisant les registres idoines (eax, ecx, et ainsi de suite), exécuter des programmes IA32 32 bits dans un environnement x64 64 bits nécessite une formule avec laquelle gommer les différences structurelles entre les deux architectures. Windows x64 implémente à cet effet une couche applicative distincte, nommée Windows on Windows, qui permet de faire fonctionner les programmes x86 32 bits dans le système d’exploitation 64 bits.

L’objectif premier de WOW64 est de fournir les interfaces requises pour permettre à des applications Windows 32 bits de s’exécuter sans être modifiées sur un système 64 bits. Cela inclut une couche de conversion des appels Win32 32 bits en appels 64 bits correspondants, plus divers aménagements en ce qui concerne la création des processus et des threads, la gestion des appels système ou le basculement du processeur entre les modes 32 bits et 64 bits.

Composants Wow64

Au plus haut niveau d’abstraction, l’environnement Wow64 se présente sous la forme d’une collection de modules (DLL) en mode utilisateur.

  • Wow64.dll Fournit l’infrastructure de base sur laquelle repose la couche logicielle Wow64 ; gère la création des processus et des threads ; intercepte les appels système de base exportés par Ntoskrnl.exe ; implémente la redirection du système de fichiers, ainsi que la redirection et réflexion du registre.

  • Wow64Cpu.dll Fait abstraction des caractéristiques du processeur hôte ; gère le contexte processeur de chaque thread exécuté dans Wow64 ; fournit le support, spécifique à l’architecture du processeur, du basculement du processeur entre les modes 32 bits et 64 bits.

  • Wow64Win.dll Intercepte les appels système relatifs à la portion mode noyau du sous-système Windows, autrement dit les appels concernant l’interface graphique exportés par Win32k.sys.

  • Ntvdm64.dll Accomplit diverses manœuvres et instructions dans le but de gérer les programmes d’installation 16 bits permettant l’intégration d’un logiciel 32 bits sur l’ordinateur.

Espace d’adressage des processus Wow64

Windows 64 bits installe le logiciel Wow64 dans l’espace d’adressage de tout processus né à partir d’une image exécutable (.exe) 32 bits. Les processus Wow64 peuvent fonctionner avec 2 ou 4 Go d’espace virtuel. Si l’application a dans son entête de l’image le flag d’adressage large a l’état actif, lui est offert un espace d’adressage de mémoire virtuelle de 4 Go. Dans le cas contraire, le gestionnaire de mémoire, par l’intermédiaire de Wow64, crée une fenêtre de mémoire virtuelle adressable en 32 bits, soit 2 Go, exactement comme si l’application fonctionnait sur une édition 32 bits de Windows. Evidement (mais il n’est peut-être pas inutile de le rappeler), malgré WoW64, les programmes 32 bits exécutées sous Windows 64 bits ne bénéficient ni de la taille de l’espace d’adressage 64 bits ni des registres élargis à 64 bits sur les processeurs.

Appels système

Le logiciel Wow64 instaure une présence dans les surfaces de contact entre la plateforme native et les applications héritées, y compris les appels système. Il intercepte pour ce faire tous les chemins d’exécution dans lesquels a lieu un basculement entre les modes 32 bits et 64 bits du processeur, où le code 32 bits sollicite des services implémentés au niveau du noyau 64 bits, ou où le système natif 64 bits appelle du code mode utilisateur 32 bits.

Lors de l’exécution d’un programme, Windows donne en premier lieu la main au code d’initialisation du chargeur (loader), lequel inspecte l’en-tête de l’image exécutable et, s’il la reconnaît en tant que 32 bits, met en place pour elle un environnement Wow64. Il charge pour ce faire Wow64.dll, faisant le lien entre le support 32 bits et le système d’exploitation 64 bits. Ensuite, Wow64 configure le contexte de démarrage à l’intérieur de Ntdll, bascule le processeur en mode 32 bits et commence l’exécution du chargeur 32 bits. A partir de là, étant donné que les processeurs x64 peuvent exécuter directement les instructions x86, l’exécution continue comme si le processus était exécuté sur un système 32 bits natif.

Wow64 embarque des versions 32 bits spéciales de quelques-unes des DLL fondamentales du sous-système Windows, incluant Kernel32.dll, User32.dll, Gdi32.dll. Ces modules, stockés dans le dossier \Windows\System32\Syswow64, sont pour la plupart fonctionnellement identiques à leurs homologues incorporés à Windows 32 bits. Une exception, toutefois, avec la bibliothèque de support Ntdll.dll, qui dans le contexte Wow64 s’occupe également de convertir les données 32 bits en vue de leur transmission vers les couches natives.

Paramètres d’entrée et de sortie des processus Wow64 opèrent a une échelle différente de celle des autres composants hébergés par le système natif. Ainsi, quand un tel processus réclame du traitement en mode noyau, Wow64 bascule le processeur en mode 64 bits, capture les paramètres au format 32 bits associés à l’appel système, puis émet l’appel 64 bits correspondant. A la fin du traitement, Wow64 convertit les paramètres de sortie avant de repasser dans le mode 32 bits.

Impression

Considérant l’impossibilité pour Wow64 de charger des pilotes mode noyau 32 bits (voir à ce sujet la section Restrictions), les pilotes d’imprimante 32 bits sont inutilisables sous Windows 64 bits. Un mécanisme d’impression spécifique aux processus 32 bits est cependant mis en oeuvre via le processus splwow64.exe, correspondant au serveur d’impression RPC de Wow64, que le système utilise chaque fois qu’une demande d’impression émane d’un processus 32 bits. Comme Splwow64 est un processus 64 bits, il peut charger des pilotes d’imprimante 64 bits. Dans Windows Vista et versions ultérieures de Windows, les pilotes d’imprimante ont obligation de suivre l’infrastructure de pilote en mode utilisateur (UMDF, User-Mode Driver Framework).

Performances de Wow64

Performances et consommation de mémoire des processus Wow64 sont déterminés par un ensemble de facteurs incluant la plate-forme matérielle sous-jacente, les frais imputables à la conversion des appels 32 bits en appels 64 bits natifs (thunking) et, finalement, au la dimension de l’ensemble de travail (working set).

  • Matériel processeur Une large part des opérations effectuées par Wow64 viennent en réalité directement de la main de la plateforme matérielle x64, dont un mode d’exécution distinct, appelé mode de compatibilité (compatibility mode), permet l’exécution d’instructions x86 32 bits. De cette manière, la vitesse à laquelle lesdites instructions sont traitées sous Wow64 est similaire à celle observée sous les systèmes x86 natif.

  • Mémoire Chaque fois qu’un processus Wow64 accède à une ressource gérée par le noyau, le chemin emprumté à cette occassion aboutit invariablement à un appel système. Les systèmes Windows 64 bits traitent des données perceptiblement différentes en taille de celles manipulées par les applications 32 bits, et qu’un protocole de conversion s’avère par conséquent nécessaire. Un tel dispositif a un surcout, pas tellement en ce qui concerne les performances - les frais au niveau du processeur sont négligeables dans la plupart des cas - mais relativement à la quantité de mémoire nécessaire pour la représentation des données. Amener des donnée 32 bits a un format 64 bits double essentiellement la quantité de mémoire nécessaire pour les stocker. Ce fait, particulièrement impactant, touche divers domaines, des stratégies d’allocation à la création de threads.

  • Working set Considérant que les systèmes informatiques 64 bits disposent de de plus grandes quantités de mémoire physique que leurs homologues 32 bits, Wow64 dimensionne les working sets de processus de façon plus souple que ne le ferait Windows 32 bits. Avec plus de pages virtuelles résidant en mémoire physique, les threads de processus Wow64 ont plus de chance de référéncer des données sans provoquer de défaut de page. Notez que Wow64 étant majoritairement implémenté en mode utilisateur, le mécanisme n’a aucune incidence sur le code et les données paginables du système d’exploitation.

Wow64 permet aux applications 32 bits de bénéficier, ne serait-ce que partiellement, de l’architecture 64 bits sous-jacente. Elles peuvent par exemple utiliser un plus grand nombre de descripteurs faisant référence à des objets noyau ou à des fenêtres. Cependant, les procédures mises en œuvre pour assurer un bon fonctionnement aux applications 32 bits (Wow64 donc) sont elles-aussi consommatrices de ressources et, en tant que telles, tendent à peser sur les entités dont elles assurent la gestion. Ainsi, les applications 32 bits ont proportionnellement moins de possibilité de créer des threads dans Wow64 que dans leur écosystème natif, cela en raison de la création par le sous-système d’une pile supplémentaire 64 bits pour chaque thread. En outre, le système réserve automatiquement pour Wow64 et les structures de données qu’il utilise une certaine quantité de mémoire, ponctionnée pour l’occasion dans l’espace d’adressage mode utilisateur du processus.

Communication entre processus Wow64 et processus natifs

Comme tout programme informatique, les entités sous l’aile de Wow64 ont besoin quelquefois de partager des données ou des ressources avec d’autres composants du système d’exploitation. Les processus Wow64 disposent en la matière et à quelques exceptions près des mêmes mécanismes que ceux en œuvre pour la communication inter processus des processus exécutés sur le système 64 bits natifs.

  • Objets et handles d’objets Par égard pour l’interopérabilité avec le parc applicatif existant, les éditions 64 bits de Windows emploient en divers endroits du système des mécanismes orientés non en fonction des propriétés du système natif, mais de celles de l’architecture héritée 32 bits. C’est, par exemple en ce qui concerne les méthodes d’accès aux objets, le cas des handles, qui conservent (en surface) une dimension unique entre les versions 32 bits et 64 bits de Windows.

  • RPC Conçus pour atténuer les problèmes structurels auxquels sont confrontées les applications, les appels de procédure distante, agnostiques vis-à-vis de l’architecture sur laquelle ils fonctionnent, répondent de ce fait particulièrement bien aux problèmes des échanges et de la synchronisation entre processus Wow64 et processus natifs.

  • COM Le système d’exploitation fournit de l’interopérabilité à travers la frontière 32/64 bits pour COM ainsi que pour diverses opérations élémentaires relatives au presse-papiers, telles que couper, copier et coller.

  • Mémoire partagée La mémoire peut être partagée entre processus 32 bits et processus 64 bits à la condition que les types de données dépendants des pointeurs soient convertis.

  • Création de processus Les interfaces Windows avec lesquelles créer des processus, dont font par exemple partie les API CreateProcess et ShellExecute, sont capables d’ouvrir des chemins d’exécution 32 bits ou 64 bits, selon les caractéristiques du fichier image (.exe) à exécuter. Un processus Wow64 peut ainsi donner naissance à un processus dans l’environnement natif du système d’exploitation, et un processus 64 bits demander la création d’un processus 32 bits.

Pilotes en mode noyau

Wow64, sans doute dans le cadre d’une politique visant à plus de modernité dans les systèmes Microsoft actuels, ne permet pas le chargement de pilotes en mode noyau 32 bits. Le noyau 64 bits ne les prenant pas en charge, de tels logiciels doivent par conséquent être portés vers le 64 bits natif.

Les pilotes peuvent appeler la routine IoIs32bitProcess pour déterminer si une requête d’E/S émane ou non d’un processus Wow64. Dans le mode utilisateur, deux fonctions intégrées à Kernel32.dll peuvent détecter les processus Wow64, IsWow64Process et GetNativeSystemInfo. IsWow64Process retourne un indicateur permettant de déterminer si un processus s’exécute sous WOW64. GetNativeSystemInfo extrait des informations sur le système pour une application fonctionnant sous WOW64. Si la fonction est appelée à partir d’une application 64 bits, elle est équivalente à GetSystemInfo.

Limitations et restrictions inhérentes à Wow64

Ce qui suit répertorie quelques-unes des limitations inhérentes à Wow64 et, partant, à la compatibilité des programmes 32 bits dans l’environnement Windows 64 bits.

  • Espace d’adressage La taille par défaut de l’espace d’adressage pour un processus Wow64 est limitée à 2 Go, extensible à 4 si l’application gère les adresses de taille supérieure (option /LARGEADDRESSAWARE de l’Éditeur de liens).

  • 16 bits Les versions 64 bits de Windows, donc par association le sous-système Wow64, ne supportent aucune application 16 bits. De ce fait, si vous possédez une application héritée 16 bits (ou une application 32 bits avec un programme d’installation 16 bits), vous devrez soit conserver l’infrastructure existante en assumant la charge, soit vous tourner vers les diverses solutions de virtualisation présentes sur le marché.

  • Posix et OS/2 Wow64 n’intègre pas de support à destination des applications Posix ou OS/2, avec la conséquence que ces programmes ne fonctionnent pas nativement sur les systèmes Microsoft 64 bits. (Des alternatives sont néanmoins disponibles.)

  • 32 bits en Mode noyau Wow64 ne permet pas de charger des pilotes des périphériques mode noyau 32 bits. Cela a pour conséquence que les pilotes de niveau système doivent être compilés en mode 64 bits, portées, voire repensées, afin de tirer le meilleur avantage du 64 bits natif.

  • Mixité entre programmes 32 et 64 bits Les processus Wow64 ne peuvent charger que des DLL 32 bits, mais pas de DLL 64 bits natives. De même, les processus 64 bits natifs ne peuvent pas charger de DLL 32 bits. Divers cas particuliers illustrant cette limite sont, par exemple, Microsoft Internet Explorer ne pouvant charger de contrôles ActiveX 32 bits, l’interpréteur de commandes standard ne pouvant interagir avec les extensions d’environnement 32 bits, ou les programmes d’installation 32 bits ne pouvant enregistrer des DLL en 64 bits.

Redirection du système de fichiers

Pour diverses raisons mal définies, un certain nombre de programmes 32 bits font référence aux répertoires système non via la méthode appropriée, à laquelle correspond la fonction Windows GetSystemDirectory, mais sur l’assertion que le chemin d’accès \Windows\System32 fasse référence inconditionnellement au dossier racine du système d’exploitation. Autrement dit, même une fois exécuté dans un contexte 64 bits, ces programmes essaieront toujours d’accéder au répertoire \Windows\System32. Pour donner une solution efficace à cette problématique, les noms des répertoires système communs entre Win32 et Windows 64 bits ont été conservés, et un mécanisme de redirection intégré pour assurer le bon fonctionnement de l’ensemble.

Remarque A l’époque de Windows 16 bits, le répertoire hôte de la plupart des fichiers nécessaires au système était \Windows\System. Avec l’introduction de Win32, un autre répertoire fut ajouté, soit \Windows\System32, contenant les fichiers et modules natifs 32 bits. Windows 95 jeta le trouble et commença à semer la confusion en faisant cohabiter dans System32 les deux types de fichiers système, 16 bits et 32 bits.

Dans les systèmes Windows 64 bits, le répertoire \Windows\System32 contient les images 64 bits natives, réservées aux applications 64 bits.(Notez que le nombre 32, partie du nom, perd pour l’occasion toute signification particulière.) Wow64, quand il intercepte les appels système, traduit les API liées aux chemins, de sorte que lorsqu’un processus 32 bits accède au répertoire \Windows\System32, ses opérations sont redirigées vers le répertoire \Windows\SysWOW64, lequel héberge les versions 32 bits des modules habituels. De plus, la plupart des programmes 32 bits sont détectés a l’installation et enregistrées dans le \Program Files (x86), alors que les programmes 64 bits vont dans le dossier \Program Files.

Les modalités dont s’effectuent l’accès à quelques sous-répertoires de \Windows\System32 sont, pour des raisons de compatibilité, exemptées de la redirection du système de fichiers, les opérations des applications 32 bits qui y accèdent ciblant du coup de vrais répertoires. Ceux-ci incluent :

  • %windir%\system32\drivers\etc 


  • %windir%\system32\spool 


  • %windir%\system32\catroot et %windir%\system32\catroot2 


  • %windir%\system32\logfiles 
 Par défaut, la redirection de système de fichiers intégrée à Wow64 est active pour tout processus exécutée conjointement à ce sous-système. Les processus peuvent pour interagir avec le mécanisme avoir recours aux API Wow64DisableWow64FsRedirection, Wow64EnableWow64FsRedirection et Wow64RevertWow64FsRedirection.

Les diverses fonctions Windows apparentées à la redirection de système de fichiers affectent toutes les E/S orientées fichier émises par le thread appelant. Il en résulte quelques situations conflictuelles du moment où la redirection est désactivée. Les procédures de chargement de DLL, par exemple, émettent des E/S dépendantes de chemins d’accès redirigées, et auront dans ce contexte des résultats inattendus. Ces procédures ne répondent en outre pas toujours à un chemin d’exécution évident : une DLL peut avoir des dépendances envers d’autres DLL, une application charger une DLL au nom d’une autre application, ou encore Windows différer le chargement d’une DLL jusque-là survenue d’un événement. Dans n’importe laquelle de ces situations, l’application pourrait dépendre d’un chemin d’accès habituellement redirigé par Wow64, qui ne l’est pas quand le système concrétise les traitements nécessaires à la requête d’E/S. Pour éviter ces problèmes, il est vivement conseillé de désactiver la redirection immédiatement avant une fonction d’E/S, et de la réactiver immédiatement après.

Les opérations concernant la redirection de système de fichiers s’effectuent à l’échelle du thread. Certaines fonctions, tel CreateProcessAsUser, qui exécutent diverses tâches pour le compte (et dans le contexte) d’autres threads ne sont donc pas concernées par l’état de la redirection dans le thread appelant.

Variables d’environnement

Corollaire aux quelques divergences que le sous-système instaure en ce qui concerne le registre et des parties du système de fichiers, WOW64 expose aux applications 32 bits des variables d’environnement différentes de celles vues par les applications 64 bits. Les processus 32 bits voient par exemple la variable d’environnement relative au chemin d’installation des programmes (%ProgramFiles%) en tant que \Program Files (x86), cela en référence au répertoire des programmes x86 enregistrés dans Windows 64 bits, alors que les programmes 64 bits voient la valeur \Program Files, soit le chemin normal des programmes installés.

Quand un processus 32 bits est créé par le système 64 bits natif, ou quand un processus 64 bits est créé par un processus 32 bits, Wow64 participe à la condition (l’état) de quelques-unes des variables dynamiques utilisées par ce processus. Le tableau montre ces variables, et présente les fluctuations se manifestant à ce niveau entre processus 32 bits natifs, processus 32 bits sur plateforme matérielle 64 bits - emmenées par Wow64 donc, et les processus 64 bits.

Table 21. Variables d’environnement pour processus 32 bits, processus 64 bits et processus Wow64

Variable

32 bits natif

64 bits natif

Wow64

PROCESSOR_ARCHITECTURE

x86

amd64

x86

PROCESSOR_ARCHITEW6432

Non défini

Non défini

amd64

ProgramFiles

\Program Files

\Program Files

\Program Files (x86)

ProgramW6432

-

\Program Files

\Program Files (x86)

CommonProgramFiles

\Program Files\Common Files

\Program Files\Common Files

\Program Files\Common Files(x86)

CommonProgramW6432

-

\Program Files\Common Files

-

Flags globaux de Windows

Pour faciliter le débogage et préparer le terrain à toutes sortes d’autres activités de suivi, Windows prend en charge un jeu de modificateurs (flags) faisant écho à diverses fonctionnalités de diagnostic, de trace et de validation internes. Appelés les flags globaux de Windows, ces paramètres servent à altérer la façon dont les logiciels interagissent avec les composants du système d’exploitation, à la fois en mode utilisateur et en mode noyau, et font preuve de leur utilité en de multiples circonstances, allant de l’enquête sur les signes d’une corruption du tas à la préparation de tests de résistance.

Chacun des flags globaux de Windows se caractérise par un nom qui le désigne en surface et par une valeur numérique que le système d’exploitation emploie en interne. S’ajoute à cela une abréviation alphabétique de trois caractères qui, si le schéma dont elle fait partie n’a pas d’existence en dehors du plan fonctionnel (et absolument aucune sur le plan programmatique), n’en reste pas moins suivi par la plupart (sinon tous) les utilitaires permettant des interactions sur ces propriétés. Par exemple, le sous-ensemble des flags globaux correspondant à la fonctionnalité de balisage de pool (Enable pool tagging) renvoie au nom FLG_POOL_ENABLE_TAGGING, à la valeur 0x0400 et l’abréviation ptg.

Constante Valeur Abréviation Signification

FLG_STOP_ON_EXCEPTION

0x00000001

soe

Stop on exception

FLG_SHOW_LDR_SNAPS

0x00000002

sls

Show loader snaps

FLG_DEBUG_INITIAL_COMMAND

0x00000004

dic

Debug initial command

FLG_STOP_ON_HUNG_GUI

0x00000008

shg

Stop on hung GUI

FLG_HEAP_ENABLE_TAIL_CHECK

0x00000010

htc

Enable heap tail checking

FLG_HEAP_ENABLE_FREE_CHECK

0x00000020

hfs

Enable heap free checking

FLG_HEAP_VALIDATE_PARAMETERS

0x00000040

hpc

Enable heap parameter checking

FLG_HEAP_VALIDATE_ALL

0x00000080

hvc

Enable heap validation on call

FLG_APPLICATION_VERIFIER

0x00000100

vrf

Enable application verifier

FLG_POOL_ENABLE_TAGGING

0x00000400

ptg

Enable pool tagging

FLG_HEAP_ENABLE_TAGGING

0x00000800

htg

Enable heap tagging

FLG_USER_STACK_TRACE_DB

0x00001000

ust

Create user mode stack trace database

FLG_KERNEL_STACK_TRACE_DB

0x00002000

kst

kernel mode stack trace database

FLG_MAINTAIN_OBJECT_TYPELIST

0x00004000

otl

Maintain a list of objects for each type

FLG_HEAP_ENABLE_TAG_BY_DLL

0x00008000

htd

Enable heap tagging by DLL

FLG_DISABLE_STACK_EXTENSION

0x00010000

dse

Disable stack extension

FLG_ENABLE_CSRDEBUG

0x00020000

d32

Enable debugging of Win32 subsystem

FLG_ENABLE_KDEBUG_SYMBOL_LOAD

0x00040000

ksl

Enable loading of kernel debugger symbols

FLG_DISABLE_PAGE_KERNEL_STACKS

0x00080000

dps

Disable paging of kernel stacks

FLG_ENABLE_CLOSE_EXCEPTIONS

0x00400000

ece

Enable close exception

FLG_DEBUG_INITIAL_COMMAND_EX

0x04000000

dwl

Debug WinLogon

FLG_DISABLE_PROTDLLS

0x80000000

dpd

Disable protected DLL verification

Les flags globaux du système sont stockés sous la forme d’un masque binaire dans une variable globale, nommée NtGlobalFlag, initialisée lors de l’amorçage de Windows depuis la clé de registre HKLM\SYSTEM\CurrentControlSet\Control\Session Manager dans la valeur GlobalFlag. Par défaut, cette valeur de registre est 0x400, à quoi correspond en interne l’activation du balisage de pool.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager
    GlobalFlag    REG_DWORD    0x400

La représentation binaire (et à l’échelle d’une seule clé de registre) étant quelquefois insuffisante pour englober toutes les informations relatives à un statut, une condition ou à un chemin d’exécution alternatif, certains composants de Windows ont en partie pour tâche de gérer des protocoles additionnels en vue de leur propre configuration. C’est, par exemple, la situation du gestionnaire de tas qui, une fois ses options activées par l’intermédiaire de flags globaux, emploie une valeur de registre spécifique (PageHeapFlags) de sorte à pouvoir gérer ses fonctionnalités de façon plus granulaire.

Logiciel Global Flags

La manière dont sont stockés les flags Windows globaux (en l’occurrence un masque binaire) ne se prête que très malaisément à une perception intuitive. Heureusement, Windows SDK et les outils de débogage standard incluent un utilitaire graphique nommé Global Flags via lequel interagir sur ces aspects, et par conséquent voir et modifier les flags globaux du système (soit dans le registre, soit dans le système en cours d’exécution), ainsi que les flags globaux d’une image.

Le module exécutable sous-jacent à Global Flag, gflags.exe, peut être lancé à partir du chemin d’installation par défaut ou depuis un des raccourcis créés par le programme d’installation. L’utilitaire demande automatiquement l’élévation de ses privilèges au niveau administratif. Ainsi que vous pouvez le voir au niveau de la figure Boîte de dialogue Global Flags, l’interface principale de Global Flags est divisée en onglets regroupant plusieurs options d’une même catégorie.

effe
Figure 2. Boîte de dialogue Global Flags

Vous pouvez basculer entre paramètres du registre (en cliquant sur System Registry) et valeur courante de la variable en mémoire système (en cliquant sur Kernel Flags). S’il est possible dans quelques cas de remanier la disposition générale des flags d’un système en cours d’exécution, la plupart des scénarios exigent un réamorçage système afin que les modifications prennent effet.

Les possibilités de configuration mises en avant dans l’onglet System Registry (le plus à gauche) s’appuient sur l’existence de paramètres dans le registre Windows. Les modifications ainsi faites sont répercutées sous la clé correspondante appartenant au gestionnaire de session, et alimentent la variable NtGlobalFlags lors du prochain démarrage du système d’exploitation.

Les options rendues visibles depuis l’onglet Kernel Flags peuvent être utilisées pour ajuster en temps réel la valeur courante de la variable globale système NtGlobalFlag. Tout changement apporté par ce biais est effectif sans avoir besoin de redémarrer Windows, au détriment de sa survie entre deux amorçages du système. Notez que quelques-uns des comportements appuyés par des flags globaux ne peuvent prendre effet à la volée, dans la mesure où les paramètres associés sont lus uniquement durant le démarrage du système d’exploitation - il n’existe pas de prise en compte dynamique de la conduite à tenir. Ceci est la raison pour laquelle quelques options de la liste des paramètres du registre sont absentes de la gamme des choix accessibles en ce qui concerne le noyau.

Les contrôles regroupés sous l’onglet Image File permettent de modifier les flags globaux relatifs à une image exécutable, plutôt que ceux du système dans son ensemble.

effe
Figure 3. Configuration des flags globaux d’image avec Gflags

Les informations dans le champ de saisie Image doivent faire référence à un nom de module, et non à un emplacement du système de fichiers. Cela signifie qu’il vous suffit d’entrer dans cette zone de texte le nom de fichier d’une image exécutable, par exemple notepad.exe. Remarquez que vous devez inclure l’extension de fichier dans le nom du fichier. Les flags globaux d’une image se propageant au processus associé seulement à l’occasion de sa mise en route, les modifications apportées à l’aide de l’outil Gflags (ou même les changements effectués directement dans le Registre) s’appliquent uniquement aux instances nouvellement créées.

Une fois que vous avez défini par l’intermédiaire de l’outil Gflags les flags globaux d’une image exécutable, vous pouvez vérifier que le Registre comporte bel et bien une nouvelle entrée concernant le module dont vous avez renseigné le nom dans la boite de dialogue Image (notepad.exe dans notre exemple). Pour ce faire, à l’aide de n’importe quel outil d’édition du registre, portez votre attention sur les clés et valeurs hébergées sous HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options. Vous devriez voir quelque chose ressemblant à ce qui suit.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\notepad.exe
    GlobalFlag    REG_DWORD    0x2000000
    PageHeapFlags    REG_DWORD    0x3

Idéalement, vous ne devriez interférer sur le cours des évènements induit par les flags globaux de Windows que par l’entremise d’outils tiers spécialisés à cette fin. Au cas où vous souhaiteriez passer outre cet avertissement et procéder à des changements directs dans le registre, veillez à garder à l’esprit que dans les versions 64 bits de Windows, programmes natifs et programmes 32 bits ne disposent pas de la même vue de certaines parties du système d’exploitation. Cela signifie que si un module renvoie à du code x86 32 bits, vous devrez mettre à jour la clé de registre située sous l’arborescence HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\. L’utilitaire Gflags est en la situation assez pratique pour modifier à la fois la vue native (portion 64 bits) et la vue Wow64 (portion 32 bits) du Registre, de sorte que vous n’ayez pas à vous préoccuper de ces détails.

Flags globaux d’image

De façon similaire à comment le comportement du système peut être dirigé par l’intermédiaire de modificateurs (flags), chaque image exécutable dispose également d’un ensemble de flags globaux chargés d’activer du code interne de trace, de vérification et de recouvrement d’erreurs. Au contraire des flags globaux du système, qui étendent leur portée sur tout l’environnement, les flans globaux relatifs à un fichier image n’ont d’influence que sur les instances d’un processus.

La configuration d’ensemble des flags globaux d’image trouve un abri dans le Registre sous HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\. Lors de la création de processus, le système s’en remet à cet emplacement de sorte à voir s’il existe une sous-clé nommée à partir du nom de fichier et de l’extension de l’image exécutable. Si tel est le cas, il recherche une valeur nommée GlobalFlag pour cette clé. S’il y en a une, les données sont alors enregistrées en tant que flags globaux du processus. Autrement, à savoir dans l’éventualité où la valeur GlobalFlag est absente ou qu’il n’est nulle part fait mention de l’image sous Image File Execution Options (ce qui sur ce sujet revient au même), les flags globaux du processus sont dérivés de la valeur de la variable en mémoire système nommée NtGlobalFlag (bien que la disposition binaire de ces flags soit complètement différente de celles des flags système globaux).

Une fois que les flags globaux d’une image ont été déterminés, le chargeur répercute ces informations à l’attribut NtGlobalFlag du bloc PEB dans l’espace d’adressage mode utilisateur du processus exécutant l’image.

0:000> dt ntdll!_PEB NtGlobalFlag @$Peb
   +0x0bc NtGlobalFlag : 0x2000400

Lors de vos expérimentations sur les flags globaux d’une image, sachez que quelques-uns sont automatiquement mis en oeuvre dès lors que le processus associé est démarré depuis un débogeur en mode utilisateur. Quand une requête de création de processus survient, le code d’initialisation afférent dans le module ntdll, par nature instruit des conditions dans lesquelles tout fichier image a été exécuté, observe si ces dernières sont de nature à assurer le diagnostic des applications, et si elles le sont effectivement, anime de façon silencieuse un petit nombre de modificateurs. Le cas concerne uniquement les modules pour lesquelles aucun paramètre n’est explicitement défini à cet égard dans le Registre. A titre d’illustration, la sortie suivante montre la valeur courante des flags globaux du processus calc.exe lorsque l’image concernée n’a pas d’attributs déterminés en la matière.

0:000> !gflag
Current NtGlobalFlag contents: 0x00000070
    htc - Enable heap tail checking
    hfc - Enable heap free checking
    hpc - Enable heap parameter checking

Ainsi que vous pouvez le voir, un petit nombre paramètres qui ont trait au suivi du tas sont au niveau de l’image notepad.exe à l’état actif, sans par ailleurs que rien de concret nous ai préparé à cette situation. Un fait intéressant à relever ici et qui découle directement de cette caractéristique est qu’une application peut se comporter différemment selon son exécution au sein d’un environnement de débogage. Dans notre exemple, ceci explique pourquoi un programme fautif vis-à-vis du tas en manifeste tous les signes quand il est pris en charge par un débogueur, et jamais ou dans de rares occasions quand il ne l’est pas.

Vous pouvez si vous le souhaitez couper court à l’influence des procédés de diagnostic sur la gestion du tas, a fortiori sur les flags globaux de niveau image, en définissant la variable d’environnement _NO_DEBUG_HEAP avant de donner naissance à un processus, ou en indiquant l’option de ligne de commande dh lors du démarrage de WinDbg. Ces deux opérations ont pour effet de demander de disposer du tas standard plutôt que de celui axé sur le débogage. Une autre alternative consiste à attacher le débogueur à un processus en cours d’exécution, dont les conditions initiales ne le préparaient par conséquent pas de façon spécifique à l’analyse.

À titre informatif, notez que la manière dont influent les pratiques de débogage sur les flags globaux d’image constitue un moyen parmi d’autres de détecter la présence d’environnement virtuel ou d’outils utilisés dans le cadre de l’analyse dynamique. Une application qui souhaite freiner l’étude de son code exécutable ou de certaines de ses informations peut par exemple observer le positionnement des flags globaux qui lui ont été attribués, et adopter un comportement particulier en conséquence.

Commande d’extension !gflag

L’extension !gflag, accessible depuis les outils de débogage standard, permet d’interagir avec les flags globaux de Windows. Sollicitée dans un contexte mode utilisateur, la commande permet de voir l’état de la variable NtGlobalFlag conservée au niveau du bloc d’environnement du processus sous le contrôle du débogueur.

0:001> !gflag
Current NtGlobalFlag contents: 0x00000002
    sls - Show Loader Snaps

Vous pouvez si vous le souhaitez obtenir une assistance en ce qui concerne cette extension en spécifiant le commutateur -?. L’aide textuelle qui apparait alors contient une liste détaillée d’abréviations dont l’emploi ambitionne de simplifier la manipulation des flags globaux.

0:003> !gflag -?
usage: !gflag [-? | flags]
Flags may either be a single hex number that specifies all
32-bits of the GlobalFlags value, or it can be one or more
arguments, each beginning with a + or -, where the + means
to set the corresponding bit(s) in the GlobalFlags and a -
means to clear the corresponding bit(s).  After the + or -
may be either a hex number or a three letter abbreviation
for a GlobalFlag.  Valid abbreviations are:
    soe - Stop On Exception
    sls - Show Loader Snaps
    htc - Enable heap tail checking
    hfc - Enable heap free checking
    hpc - Enable heap parameter checking
    hvc - Enable heap validation on call
    vrf - Enable application verifier
    htg - Enable heap tagging
    ust - Create user mode stack trace database
    htd - Enable heap tagging by DLL
    dse - Disable stack extensions
    scb - Enable system critical breaks
    dhc - Disable Heap Coalesce on Free
    eel - Enable exception logging
    hpa - Place heap allocations at ends of pages
    cse - Early critical section event creation
    sue - Stop on Unhandled Exception
    dpd - Disable protected DLL verification

La commande !gflag du débogueur noyau permet de voir la valeur de la variable NtGlobalFlag en mémoire système.

lkd> dd nt!NtGlobalFlag
fffff800`2f5661c0  00000400 00000000 00000000 00000000

lkd> !gflag
Current NtGlobalFlag contents: 0x00000400
    ptg - Enable pool tagging

lkd> !gflag -?
    soe - Stop On Exception
    sls - Show Loader Snaps
    dic - Debug Initial Command
    shg - Stop on Hung GUI
    htc - Enable heap tail checking
    hfc - Enable heap free checking
    hpc - Enable heap parameter checking
    hvc - Enable heap validation on call
    vrf - Enable application verifier
    ptg - Enable pool tagging
    htg - Enable heap tagging
    ust - Create user mode stack trace database
    kst - Create kernel mode stack trace database
    otl - Maintain a list of objects for each type
    htd - Enable heap tagging by DLL
    dse - Disable stack extensions
    d32 - Enable debugging of Win32 Subsystem
    ksl - Enable loading of kernel debugger symbols
    dps - Disable paging of kernel stacks
    scb - Enable system critical breaks
    dhc - Disable Heap Coalesce on Free
    ece - Enable close exception
    eel - Enable exception logging
    eot - Enable object handle type tagging
    hpa - Place heap allocations at ends of pages
    dwl - Debug WINLOGON
    ddp - Disable kernel mode DbgPrint output
    cse - Early critical section event creation
    sue - Stop on Unhandled Exception
    bhd - Enable bad handles detection
    dpd - Disable protected DLL verification

La commande !gflag peut également être utilisée afin de prendre la main sur l’état des flags globaux. Dans la pratique, cela peut s’effectuer de façon naturelle, en indiquant en paramètre une nouvelle valeur de la variable, soit sous la forme d’opérations basiques. Les signes plus (+) et moins (-) servent auquel cas à armer et désarmer tel ou tel drapeau. En guise d’exemple, ce qui suit montre comment activer et désactiver les informations de trace du chargeur d’image.

lkd> !gflag
Current NtGlobalFlag contents: 0x00000400
    ptg - Enable pool tagging

lkd> !gflag +soe
New NtGlobalFlag contents: 0x00000401
    soe - Stop On Exception
    ptg - Enable pool tagging

lkd> !gflag -1
New NtGlobalFlag contents: 0x00000400
    ptg - Enable pool tagging

Pour finir, notez que si l’extension !gflag permet une approche définitivement pratique des flags Windows globaux, vous restez bien évidement libre de correspondre avec eux sans son intermédiaire, moyennant un confort bien moindre. Utilisiez dans ce scénario les options classiques en matière d’interaction avec la mémoire, comme nous le faisons (en partie) dans l’exemple qui suit.

lkd> ed nt!NtGlobalFlag 0x401

lkd> !gflag
Current NtGlobalFlag contents: 0x00000401
    soe - Stop On Exception
    ptg - Enable pool tagging

Options d’exécution d’image

Les options d’exécution de fichier image (IFEO, Image File Execution Options) sont une collection de paramètres utilisés en amont de la création des processus de sorte à en assurer un contrôle spécifique. Étroitement liées au mode opératoire et aux agissements du chargeur (loader), un composant qui est par ailleurs doté lui-même de multiples ramifications dans de nombreux champs, ces données permettent de s’introduire à plusieurs étapes de la naissance d’un processus, mais aussi et surtout à divers niveaux : scénarios pour l’ouverture du fichier image à exécuter, niveaux d’analyse des fonctionnalités de débogage, détails des informations de trace, et bien d’autres.

Le registre Windows offre un toit aux options d’exécution par le biais de HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options, lequel contient pour chaque image exécutable à prendre en compte dans un scénario particulier (toutes ne le sont pas) une sous-clé nommée depuis le nom de fichier et l’extension de l’image (mais sans les données de répertoire et de chemin, par exemple Image.exe). Les valeurs sous ces clés peuvent constituer un référentiel d’informations potentiellement vaste. Pour voir quelles applications de votre système ont des options d’exécution, tournez-vous vers la clé Image File Execution Options au moyen de n’importe quel outil permettant de le faire, Regedit ou autre.

Les options d’exécution permettent une interaction très poussée tant avec les processus qu’avec les composants Windows chargés de les gérer. Elles sont de ce fait potentiellement impliquées dans un plus ou moins grand nombre de cas de figure, avec plus ou moins de relations entre eux. La liste qui suit énumère quelques-uns des leviers manœuvrés par des options d’exécution. (Pour des raisons de clarté, et afin de vous donner dès ici les bonnes pistes à suivre dans le registre, nous signalons entre parenthèses les noms des clés adéquates.)

  • Contrôle externe (Debugger) Permet à un processus de démarrer automatiquement sous la coupe d’un autre logiciel, généralement un débogueur.

  • Gestion du tas (DisableHeapLookAside) Joue un rôle dans la décision de délaisser l’emploi de listes look-acide parmi les mécanismes d’allocation du tas. Cela est notamment utile pour résoudre d’éventuels problèmes de compatibilité.

  • Débogage de tas (PageHeapFlags) Indique sur le plan des fonctionnalités de débogage de tas lesquelles lesquelles sont actives, et à quel degré.

  • Flags globaux (GlobalFlag) Anime un ensemble de techniques en association avec le diagnostic et le suivi, y compris des données de trace et des fonctions de validation internes.

  • Informations de taille de pile (MinimumStackCommitInBytes) Apporte des garanties en ce qui concerne le dimensionnement et l’accessibilité de l’espace de pile.

  • Application Verifier (VerifierFlags) Base de données des contrôles et des vérifications auxquels se livre le logiciel Microsoft Application Verifier.

Il apparaît clairement à la teneur des mécanismes dans lesquels elles s’insèrent que les options d’exécution d’image ont une dimension pour l’essentiel orientée sur le débogage, et dans une moindre mesure sur le profilage, des applications. Elles mettent en l’occurrence aux mains des concepteurs de logiciels diverses sources de données de trace, ainsi que les fonctions, les caractéristiques, voire les utilitaires, qui s’y réfèrent.

Performances

Compteurs de performance

Les compteurs de performance Windows permettent de mesurer l’évolution de certaines données de performance liées à une machine (taux d’occupation du processeur, mémoire utilisée, E/S) ou à un ou plusieurs processus (taille des piles, quantité de mémoire utilisée, etc). Windows offre nativement un large éventail de compteurs de performance, qu’administrateurs et utilisateurs peuvent étoffer en définissant les leurs propres.

Les compteurs de performance sont affichables sous forme graphique à l’aide de l’Analyseur de performance, ou sous forme textuelle à l’aide de l’utilitaire Logman.

L’architecture sous-jacente aux compteurs de performance se présente dans les grandes lignes comme suit :

  • Objets Les objets de performance sont issues de la répartition logique des ressources système en plusieurs catégories distinctes. Il existe par exemple un objet de performance pour le processeur, un autre pour la mémoire, pour les services, et ainsi de suite.

  • Compteurs Les compteurs forment la base de l’observation de l’usage des ressources, et constituent ainsi les paramètres réels mesurés.

  • Instances Les instances d’objets de performance sont des ensembles d’un même type d’objet. Par extension, une instance identifie le paramètre de performance que le compteur mesure. Certains types d’objets comportent plusieurs instances. Par exemple, sur un système multi processeur, le type d’objet Processeur dispose de plusieurs instances. Si un système contient deux disques, le type d’objet Disque physique possède deux instances. Certains objets, tels que ceux relatifs à la mémoire, ne disposent que d’une seule instance.

Analyseur de performances (Perfmon)

Analyseur de performances permet de créer des ensembles interactifs de compteurs système ou des ensembles de collecteurs de données. (Lesdits ensembles sont étudiés plus en détail dans la section "Ensembles de collecteurs de données", plus loin dans ce chapitre.

Comme socle technique, l’utilitaire Performance s’appuie sur les fonctions de l’API Performance Data Helper afin d’interagir avec les diverses sources de données de performances, dont les compteurs de performance en temps réel ou les fichiers journaux spécifiques à cet égard.

L’Analyseur de performances se présente sous la forme d’un composant logiciel enfichable de la console MMC, mis en oeuvre dans perfmon.msc.

Utilisez l’une ou l’autre des méthodes suivantes afin d’accéder à l’utilitaire Performances.

  • Ouvrez la console Gestion de l’ordinateur (compmgmt.msc), développez Outils système, puis cliquez sur Performance.

  • Depuis Outils d’administration, sélectionnez le raccourci nommé Analyseur de performances.

  • Saisissez perfmon.msc ou perfmon.msc et appuyez sur Entrée dans le menu Démarrer, la boite de dialogue Exécuter ou encore dans une fenêtre d’invite de commandes.

Ajouter des compteurs dans l’Analyseur de performances

L’Analyseur de performances affiche uniquement les informations relatives aux compteurs suivis. Plusieurs milliers de compteurs sont disponibles, réparties en un petit nombre de catégories tels que Processus, Threads, Mémoire, Cache, et ainsi de suite. Les compteurs les plus utiles en matière de suivi du système du système et de ses composants incluent ceux que voici :

  • Processus Rend visible des compteurs de performance apparentés aux différentes applications en cours d’exécution, par exemple l’activité CPU en mode utilisateur et noyau, le nombre de handles ouverts, etc.

  • Processeur Rend visible des compteurs de performance concernant l’activité du processeur, par exemple le nombre d’interruptions par seconde, le nombre de DPC par seconde, etc.

  • Mémoire Rend visible des compteurs de performance au sujet de la consommation mémoire, par exemple la quantité de mémoire disponible sur le moment, le nombre de pages et défauts de pages par seconde, etc.

Lorsque l’Analyseur de performances surveille un objet particulier, il peut suivre toutes les instances de tous les compteurs de cet objet. Les instances correspondent à toutes les instances d’un compteur particulier. Par exemple, si vous vous êtes engagés sur la piste de compteurs concernant les processus, vous avez le choix de suivre les instances de tous les processus ou celles de processus spécifiques.

Voici comment procéder en vue de sélectionner les compteurs à surveiller :

  1. Démarrez l’Analyseur de performances (les méthodes pour ce faire ont été indiquées plus haut).

  2. L’Analyseur de performances comporte plusieurs modes d’affichage. Assurez-vous d’afficher l’activité en cours en cliquant sur le bouton Affiche l’activité actuelle ou en appuyant sur CTRL+T. Pour basculer entre les types de vues (Ligne, Barre d’histogramme et Rapport), cliquez sur le bouton Modifier le type de graphique ou cliquez sur CTRL+G.

  3. Pour ajouter des compteurs, cliquez sur le bouton Ajouter de la barre d’outils, ou appuyez sur CTRL+I. La boîte de dialogue Ajouter des compteurs apparait alors.

  4. Dans le panneau Compteurs disponibles, les objets de performances sont classés par ordre alphabétique. Cliquez sur un objet pour le sélectionner : tous les compteurs correspondants le sont aussi. Si vous développez l’entrée d’un objet, vous affichez tous les compteurs associés et pouvez sélectionner des compteurs individuels en cliquant dessus.

  5. Quand vous sélectionnez un objet ou l’un de ses compteurs, les instances en cours s’affichent dans le panneau Instances de l’objet sélectionné. Sélectionnez une instance particulière ou Toutes les instances. Pour rechercher une instance particulière, entre quelques lettres dans le champ déroulant sous Instances de l’objet sélectionné et cliquez sur Rechercher.

  6. Lorsque vous avez sélectionné un objet ou un groupe de compteurs pour un objet, ainsi que les instances de l’objet, cliquez sur Ajouter pour intégrer ces compteurs à la liste Compteurs ajoutés.

  7. Lorsque vous avez terminé, cliquez sur OK.

La manière la plus simple, et le meilleur moyen, d’appréhender les compteurs véhiculées par l’Analyseur de performance consiste à lire les explications disponibles dans la boîte de dialogue Ajouter des compteurs. Accédez dans cette optique audit élément d’interface et cochez ensuite la case Afficher la description dans l’angle inférieur gauche de la fenêtre.

Droits utilisateurs de l’analyseur de performances

Les droits utilisateurs de l’analyseur de performances sont spécifiés comme suit.

  • Administrateurs Contrôle total local et distant.

  • Utilisateurs des journaux de performances Peuvent accéder et mettre en journal des données de compteur de performance localement et à distance (créer, manipuler et voir les journaux).

  • Utilisateurs de l’Analyseur de performances Peuvent accéder aux données de compteur de performance localement et à distance (voir les journaux).

Ensembles de collecteurs de données

Les ensembles de collecteurs de données sont des objets de performance qui permettent de gérer comme un tout plusieurs types de collecteurs de données : compteurs de performance, données de suivi d’événements et informations de configuration système (comme les valeurs de certaines clés spécifiques du Registre).

Introduits sous Windows Server 2008, les ensembles de collecteurs de données ressemblent dans une certaine mesure aux journaux de performance employés dans les versions précédentes de Windows. Ils sont cependant beaucoup plus élaborés, tant sur le plan de la réalisation que des schémas qu’ils rendent possibles.

Windows offre la possibilité d’interagir avec des ensembles de collecteurs de données au travers notamment de deux outils : Analyseur de performance et Logman.

Ensembles de collecteurs de données intégrés

Windows propose par l’intermédiaire de la console Performances plusieurs ensembles de collecteurs de données intégrés situés dans Ensembles de collecteurs de données\Système.

  • Performances du système Regroupe un certain de compteurs de performance liés au disque, à la mémoire et au réseau, ainsi que différentes informations de suivi concernant le noyau. Utilisez cet ensemble de collecteurs pour auditer un ordinateur lent, et de la sorte diagnostiquer les facteurs qui diminuent ses performances générales.

  • Diagnostics du système Enregistre toutes les informations comprises dans l’ensemble de collecteurs de données Performances du système, plus des métriques système détaillées. Utilisez cet ensemble de collecteur lorsque vous résolvez des problèmes de fiabilité, et faites par exemple face à du matériel défaillant, des pilotes défectueux ou des effondrements inopinés du système.

Pour employer un ensemble de collecteurs de données, effectuez dessus un clic avec le bouton droit de la souris, puis sélectionnez Démarrer. Dans la configuration par défaut, les ensembles Performances du système et Diagnostics du système s’arrêtent automatiquement au bout d’une minute.

Création d’un ensemble de collecteurs de données

Procédez comme suit afin d’enregistrer des informations de performances par le biais d’un ensemble de collecteurs de données.

  1. Ouvrez Analyseur de performances.

  2. Dans le volet gauche, effectuez un clic droit de la souris sur ensemble de collecteurs de données\Personnalisés, sélectionnez Nouveau, puis Ensemble de collecteurs de données.

  3. Dans l’assistant Créer un nouvel ensemble de collecteurs de données, spécifiez un nom pour l’ensemble, idéalement qui reflète la nature des objets que vous voulez suivre, par exemple Performances du système ou Moniteur de l’état du processeur.

  4. Sélectionnez l’option Créer manuellement et cliquez sur Suivant.

  5. Sur la page Quels type de données inclure, l’option Créer des journaux de données est sélectionnée par défaut. Cochez la case Compteur de performance et cliquez sur Suivant.

  6. Sur la page Quels compteurs de performance enregistrer dans un journal, cliquez sur Ajouter pour provoquer l’apparition de la boite de dialogue Ajouter des compteurs. Une fois les compteurs de performance selectionnés, cliquez sur le bouton Ok.

  7. Toujours sur la page Quels compteurs de performance enregistrer dans un journal ?, personnalisez si besoin l’intervalle d’échantillonnage et sélectionnez l’unité de temps en secondes, minutes, heures, jours ou semaines. Cet intervalle spécifie quand collecter les nouvelles données. Cliquez sur Suivant pour poursuivre.

  8. Sur la page Où enregistrer les données, spécifiez l’emplacement d’enregistrement des journaux (%systemdrive%\PerfLogs\Admin par défaut). Comme alternative, cliquez sur Parcourir et servez-vous de la boite de dialogue Rechercher un dossier afin de sélectionner un autre répertoire. (Voir note plus loin en ce qui concerne les proportions que peuvent atteindre les fichiers journaux.) Cliquez sur Suivant pour continuer.

  9. Sur la page Créer l’ensemble de collecteurs de données, la zone Exécuter en tant que contient <Par défaut> de sorte à indiquer que le collecteur de données s’exécutera avec les privileges et les autorisations de l’utilisateur actuel. Cliquez éventuellement sur le bouton Modifier pour indiquer d’autres informations d’identification. Sélectionnez une des trois options avant de cliquer sur le bouton Terminer :

    1. Ouvrir des propriétés pour cet ensemble de collecteurs de données Personnalise immédiatement l’ensemble de collecteurs de données.

    2. Démarrer maintenant cet ensemble de collecteurs de données Commence sur-le-champ à enregistrer des données sans passer par la personnalisation de l’ensemble de collecteurs de données.

    3. Enregistrer et fermer Ferme l’ensemble de collecteur de données sans le démarrer. Vous pouvez modifier les propriétés et le démarrer à tout moment après l’avoir enregistré.

Notez que les paramètres que vous aurez choisis au niveau de l’intervalle d’échantillonnage ont un impact direct plus ou moins significatif sur la charge de travail demandée à l’ordinateur d’une part, et le volume des données résultant d’autre part (autrement dit la taille du fichier journal). C’est précisément la raison pour laquelle, au titre de ce second point, il est généralement conseillé d’utiliser comme lieu de stockage des journaux une partition différente de celle où le système est installée.

Création de collecteurs depuis l’invite de commandes

Vous pouvez créer des collecteurs de données depuis une invite de commandes à l’aide de l’utilitaire logman. Les commandes admissibles en la circonstance comptent entre autres celles voici.

  • Logman create counter Cette commande crée un collecteur de données de compteur de performance. Par exemple, la commande logman create counter perf_log -c "\Processor{_ Total/)\% Processor Time" crée un compteur nommé perf_log qui enregistre les valeurs du compteur Pourcentage de temps processeur de l’instance de compteur Processeur(_Total).

  • Logman create trace Cette commande crée un collecteur de données de suivi d’événement. Par exemple, la commande logman create trace trace_log -o c:\ trace_log_file crée un collecteur de données de suivi d’événement nommé trace_log et enregistre les résultats dans le fichier trace_log_file à la racine du disque.

  • Logman create alert Cette commande crée une alerte de compteur de performances. Par exemple, la commande logman create alert alert -th "\ Processor(_Total)\% Processor Time>90" crée une alerte nommée alert qui se déclenche lorsque le compteur de performances Pourcentage temps processeur de l’instance de compteur Processeur(_Total) excède 90.

Moniteur de fiabilité

Moniteur de fiabilité procure des informations en lesquelles jouxtent les aspects robustesse et stabilité de la station de travail. Les ordinateurs les moins frappés par des événements causés par des défaillances sont considérés comme stables et peuvent éventuellement obtenir l’index de stabilité maximum (10). Plus le système enregistre des dysfonctionnements de toute nature, plus la stabilité du système décroit. La valeur minimale de l’index est zéro.

Les événements de fiabilité suivants peuvent être enregistrées dans le rapport de stabilité du système.

  • Modification de l’horloge système

  • Installations et désinstallations de logiciels

  • Défaillances d’applications

  • Défaillances matérielles

  • Echec Windows

  • Echecs divers

Moniteur de fiabilité conserve un historique d’un an des événements de stabilité système et de fiabilité.

Pour prendre les bonnes décisions, le moniteur de fiabilité produit des rapports détaillés permettant une juste compréhension des évènements qui ont contribué à abaisser l’index de stabilité système. Vous pouvez cliquer sur Afficher tous les rapports de problèmes pour afficher l’intégralité des problèmes rencontrés triés par logiciels.

Accéder au moniteur de fiabilité

Pour accéder au moniteur de fiabilité de Windows, rendez-vous dans le Panneau de configuration puis cliquez ensuite sur Sécurité et maintenance. Déroulez le panneau Maintenance puis cliquez sur Afficher l’historique de fiabilité. Plus simplement, saisissez perfmon /rel à l’intérieur d’une fenêtre d’invite de commandes. Une fenêtre semblable à la figure suivante s’affiche.

Pour obtenir des informations détaillés sur les problèmes rencontrés un certain jour ou une certaine semaine, il suffit de cliquer sur la bande temporelle correspondante et de lire les données affichées dans la partie inférieure de la fenêtre.

En bas de la fenêtre de Moniteur de fiabilité figurent plusieurs options :

  • Enregistrer l’historique de fiabilité Permet d’enregistrer des détails complets sur l’ordinateur pour référence ultérieure. L’information est enregistrée comme rapport Moniteur de fiabilité au format XML.

  • Afficher tous les rapports de problèmes Ouvre la fenêtre d’historique des problèmes, qui affiche l’historique de tous les problèmes rencontrés et leur statut.

  • Rechercher des solutions à tous les problèmes Lance le processus d’examen automatique des problèmes. Une fois celui-ci achevé, Centre de maintenance est actualisé de sorte à montrer les solutions à tous les problèmes nouvellement découverts.

Index de stabilité système

Dans la perspective Windows, la stabilité d’un ordinateur est exprimée par un indice variant entre 1 (stabilité déplorable) et 10 (stabilité parfaite), qui est une mesure pondérée dérivant du nombre de problèmes matériels et logiciels observées pendant une durée historique continue (période roulante). Dès qu’un événement a une influence sur la stabilité globale de l’ordinateur, Windows procède à une réévaluation de ladite valeur. Au premier lieu, cet effet de rééquilibrage permet de refléter au plus près l’amélioration ou la dégradation qui s’est produite au fil du temps dans un index de stabilité du système ascendant ou descendant lorsqu’un problème de fiabilité a été rencontré, ou au contraire résolu.

Fondée sur des données collectés au cours de la durée de vie d’un système, la valeur d’index est calculée sur les 28 jours précédents. Les jours où le système est éteint, en état de veille ou d’hibernation ne sont pas pris en compte. S’il n’y a pas assez de données pour établir un index de stabilité système fiable et sérieux, Moniteur de fiabilité affiche une ligne pointillée (continue autrement).

A titre informatif, notez pour finir que l’index de stabilité ne constitue pas une mesure exacte de fiabilité. Il existe à cet égard un petit nombre de situations spéciales qui tendent à diminuer la valeur d’index mais rendent finalement le système plus fiable qu’il ne l’était par le passé. Entre dans cette catégorie notamment toute forme de mise à jour nécessitant à terme un redémarrage de l’ordinateur, y compris service packs et mises à niveau d’édition.

Windows System Assessment Tool (WinSAT)

L’outil d’évaluation système Windows (WinSAT, Windows System Assessment Tool) mesure les performances de divers équipements intégrés à la station de travail, et donne ce faisant un pressenti de l’utilisation du système d’exploitation s’exécutant dessus.

Les résultats des mesures effectués par WinSAT sont présentés sous la forme d’un indice de performance, sujet qui sera approfondi plus loin.

Emplacements du registre

WinSAT enregistre les résultats d’évaluation sous la clé HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\WinSAT.

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\WinSAT
    LastExitCode    REG_DWORD    0x0
    LastExitCodeCantMsg    REG_SZ    Évaluation terminée.
    LastExitCodeWhyMsg    REG_SZ    Les évaluations ou les autres opérations se sont terminées avec succès.
    CKCLStart    REG_QWORD    0x0
    PrimaryAdapterString    REG_SZ    NVIDIA GeForce GTX 770
    VideoMemoryBandwidth    REG_DWORD    0x2fe741c
    VideoMemorySize    REG_DWORD    0x7ae61000
    DedicatedVideoMemory    REG_DWORD    0x7c5d0000
    SharedVideoMemory    REG_DWORD    0xfe891000
    NumMonitors    REG_DWORD    0x1
    TotalMonitorPixels    REG_DWORD    0xe1000
    DedicatedSystemMemory    REG_DWORD    0x0
    MOOBE    REG_DWORD    0x2
    WindeployTimeDate    REG_QWORD    0x5446fa42
    GraphicsFPS    REG_DWORD    0x2d2404
    WsSwapResult    REG_DWORD    0x74c00
    WsSwapInterference    REG_DWORD    0xd0004
    WsSwapThroughput    REG_DWORD    0x74c00
    MFMediaMaxRunTime    REG_DWORD    0x1d4c0
    MediaMaxRunTime    REG_DWORD    0x1d4c0
    Disk0RandomReadThroughput    REG_DWORD    0x6588f
    Disk1RandomReadThroughput    REG_DWORD    0x5e1
    CpuUPExpressCompressThroughput    REG_DWORD    0x164
    MemoryThroughputMBS    REG_DWORD    0x4a9d
    RandomReadDiskScore    REG_DWORD    0x6588f
    SequentialReadDiskScore    REG_DWORD    0x79e43
    WinCRSScore    REG_DWORD    0x51
    MemoryScore    REG_DWORD    0x54
    CPUScore    REG_DWORD    0x54
    DWMScore    REG_DWORD    0x55
    D3DScore    REG_DWORD    0x63
    DiskScore    REG_DWORD    0x51
    HistoryVersionRead    REG_DWORD    0x0
    TimeLastFormalAssessment    REG_QWORD    0x1d1d7908df3b8e5
WEI (Windows Experience Index)
  1. Ouvrez une fenêtre d’invite de commandes et tapez la commandes winsat formal. Votre ordinateur devrait alors travailler pendant quelques temps.

  2. Depuis Explorateur de fichiers, rendez-vous sur C:\Windows\Performance\WinSAT\DataStore. En toute logique, ce dossier devrait héberger deux sous-ensembles de fichiers, l’un concernant les fichiers générés par le programme d’installation de Windows, l’autre les fichiers générés à l’instant.

  3. Ouvrez le fichier Format.Assessment, par exemple en utilisant Internet Explorer, Edge ou tout autre outil via lequel visualiser facilement du contenu XML, et intéressez-vous plus particulièrement à la section nommée WinSPR (pour Windows System Performance Rating). Le résultat devrait ressembler à quelque chose comme ce qui suit.

    <WinSPR>
     <SystemScore>8.15</SystemScore>
     <MemoryScore>8.4</MemoryScore>
     <CpuScore>8.4</CpuScore>
     <CPUSubAggScore>8.3</CPUSubAggScore>
     <VideoEncodeScore>8.4</VideoEncodeScore>
     <GraphicsScore>8.5</GraphicsScore>
     <Dx9SubScore>9.9</Dx9SubScore>
     <Dx10SubScore>9.9</Dx10SubScore>
     <GamingScore>9.9</GamingScore>
     .
     .
     .
    </WinSPR>
Emplacements de registre pour WinSAT

WinSAT enregistre les résultats des évaluations auxquelles il procède par l’intermédiaire des diverses clés et valeurs situés sous HKLM\Software\Microsoft\Windows NT\CurrentVersion\WinSAT.

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\WinSat
    LastExitCode    REG_DWORD    0x0
    LastExitCodeCantMsg    REG_SZ    ...valuation terminÈe.
    LastExitCodeWhyMsg    REG_SZ    Les Èvaluations ou les autres opÈrations se sont terminÈes avec succËs.
    CKCLStart    REG_QWORD    0x0
    PrimaryAdapterString    REG_SZ    NVIDIA GeForce GTX 770
    VideoMemoryBandwidth    REG_DWORD    0x2fe741c
    VideoMemorySize    REG_DWORD    0x7ae61000
    DedicatedVideoMemory    REG_DWORD    0x7c5d0000
    SharedVideoMemory    REG_DWORD    0xfe891000
    NumMonitors    REG_DWORD    0x1
    TotalMonitorPixels    REG_DWORD    0xe1000
    DedicatedSystemMemory    REG_DWORD    0x0
    MOOBE    REG_DWORD    0x2
    WindeployTimeDate    REG_QWORD    0x5446fa42
    GraphicsFPS    REG_DWORD    0x2d2404
    WsSwapResult    REG_DWORD    0x65000
    WsSwapInterference    REG_DWORD    0xa0001
    WsSwapThroughput    REG_DWORD    0x65000
    MFMediaMaxRunTime    REG_DWORD    0x1d4c0
    MediaMaxRunTime    REG_DWORD    0x1d4c0
    Disk0RandomReadThroughput    REG_DWORD    0x6588f
    Disk1RandomReadThroughput    REG_DWORD    0x5e1
    CpuUPExpressCompressThroughput    REG_DWORD    0x164
    MemoryThroughputMBS    REG_DWORD    0x4a9d
    RandomReadDiskScore    REG_DWORD    0x6588f
    SequentialReadDiskScore    REG_DWORD    0x79e43
    WinCRSScore    REG_DWORD    0x51
    MemoryScore    REG_DWORD    0x54
    CPUScore    REG_DWORD    0x54
    DWMScore    REG_DWORD    0x55
    D3DScore    REG_DWORD    0x63
    DiskScore    REG_DWORD    0x51
    HistoryVersionRead    REG_DWORD    0x0
    TimeLastFormalAssessment    REG_QWORD    0x1d1d7908df3b8e5

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\WinSat\MediaEx
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\WinSat\WindowsExperienceIndexOemInfo

Composants de l’architecture Performances

La liste qui suit décrit quelques-uns des composants binaires spécifiques à l’architecture Performances.

  • pdh.dll Sert à interagir avec les différences sources de compteurs de performance. Pour plus d’informations, consultez la section PDH (Performance Data Helper).

  • pdhui.dll Procure les boîtes de dialogue réutilisables qui sont communes à toutes les applications liés aux performances.

  • pla.dll DLL sous-jacente au service Journaux et alertes de performance (PLA, Performance Logs and Alerts).

  • perftrack.dll Suivi des performances.

  • perfdisk.dll Recueille des données liées à la performance des disques physiques et logiques.

  • relmon.dll Moniteur de fiabilité.

PLA (Performance Logs and Alerts)

L’outil Journaux et alertes de performance prend en charge la définition d’objets de performance, de compteurs de performance et d’instances d’objets de performance. Il permet également de définir des intervalles d’échantillonnage pour l’analyse de données relatives aux ressources matérielles et aux services système.

Le service PLA intervient à la demande et démarre lorsqu’il est nécessaire de mettre en journal des données de performance. Il s’exécute dans un processus hôte partagé (svchost) avec comme nom abrégé PLA. Les informations de configuration du service PLA sont dans la clé nommé pla sous HKLM\System\CurrentcontrolSet\Services.

Paramètres de registre pour la configuration PLA
HKEY_LOCAL_MACHINE\System\CurrentcontrolSet\Services\pla
    DisplayName    REG_SZ    @%systemroot%\system32\pla.dll,-500
    ErrorControl    REG_DWORD    0x1
    ImagePath    REG_EXPAND_SZ    %SystemRoot%\System32\svchost.exe -k LocalServiceNoNetwork
    Start    REG_DWORD    0x3
    Type    REG_DWORD    0x20
    Description    REG_SZ    @%systemroot%\system32\pla.dll,-501
    DependOnService    REG_MULTI_SZ    RPCSS
    ObjectName    REG_SZ    NT AUTHORITY\LocalService
    ServiceSidType    REG_DWORD    0x3
    RequiredPrivileges    REG_MULTI_SZ    SeImpersonatePrivilege
    FailureActions    REG_BINARY    840300000000000000000000030000001400000001000000C0D4010001000000E09304000000000000000000

HKEY_LOCAL_MACHINE\System\CurrentcontrolSet\Services\pla\Configuration
HKEY_LOCAL_MACHINE\System\CurrentcontrolSet\Services\pla\Parameters
HKEY_LOCAL_MACHINE\System\CurrentcontrolSet\Services\pla\Security

PDH (Performance Data Helper)

L’API Performance Data Helper (Pdh.dll) offre des moyens d’accès structurés aux informations de performance et de diagnostic issues des différentes sources établies en la matière, y compris les compteurs de performance en temps réel, les fichiers binaires stockés et d’autres plus anciens formats de journaux de compteurs.

Les interfaces PDH présentent un niveau d’abstraction plus fort et une meilleure flexibilité que les fonctions du registre Windows. Les concepteurs de logiciels peuvent, entre autres, employer les interfaces PDH pour lire les valeurs des compteurs de performances, configurer, analyser et agréger des journaux de compteurs, et accéder à bien d’autres fonctionnalités indisponibles autrement.

Fonctions PHD
  • PdhOpenQuery Crée une nouvelle requête utilisable pour gérer la collecte des données de performance.

Codes d’erreur

La liste qui suit énumère les codes d’erreur spécifiques à PDH. Ces valeurs sont définies dans le fichier d’entête pdhmsg.h.

  • 0x00000000 - PDH_CSTATUS_VALID_DATA

  • 0x00000001 - PDH_CSTATUS_NEW_DATA

  • 0x800007D0 - PDH_CSTATUS_NO_MACHINE

  • 0x800007D1 - PDH_CSTATUS_NO_INSTANCE

  • 0x800007D2 - PDH_MORE_DATA

  • 0x800007D3 - PDH_CSTATUS_ITEM_NOT_VALIDATED

  • 0x800007D4 - PDH_RETRY

  • 0x800007D5 - PDH_NO_DATA

  • 0x800007D6 - PDH_CALC_NEGATIVE_DENOMINATOR

  • 0x800007D7 - PDH_CALC_NEGATIVE_TIMEBASE

  • 0x800007D8 - PDH_CALC_NEGATIVE_VALUE

  • 0x800007D9 - PDH_DIALOG_CANCELLED

  • 0x800007DA - PDH_END_OF_LOG_FILE

  • 0x800007DB - PDH_ASYNC_QUERY_TIMEOUT

  • 0x800007DC - PDH_CANNOT_SET_DEFAULT_REALTIME_DATASOURCE

  • 0xC0000BB8 - PDH_CSTATUS_NO_OBJECT

  • 0xC0000BB9 - PDH_CSTATUS_NO_COUNTER

  • 0xC0000BBA - PDH_CSTATUS_INVALID_DATA

  • 0xC0000BBB - PDH_MEMORY_ALLOCATION_FAILURE

  • 0xC0000BBC - PDH_INVALID_HANDLE

  • 0xC0000BBD - PDH_INVALID_ARGUMENT

  • 0xC0000BBE - PDH_FUNCTION_NOT_FOUND

  • 0xC0000BBF - PDH_CSTATUS_NO_COUNTERNAME

  • 0xC0000BC0 - PDH_CSTATUS_BAD_COUNTERNAME

  • 0xC0000BC1 - PDH_INVALID_BUFFER

  • 0xC0000BC2 - PDH_INSUFFICIENT_BUFFER

  • 0xC0000BC3 - PDH_CANNOT_CONNECT_MACHINE

  • 0xC0000BC4 - PDH_INVALID_PATH

  • 0xC0000BC5 - PDH_INVALID_INSTANCE

  • 0xC0000BC6 - PDH_INVALID_DATA

  • 0xC0000BC7 - PDH_NO_DIALOG_DATA

  • 0xC0000BC8 - PDH_CANNOT_READ_NAME_STRINGS

  • 0xC0000BC9 - PDH_LOG_FILE_CREATE_ERROR

  • 0xC0000BCA - PDH_LOG_FILE_OPEN_ERROR

  • 0xC0000BCB - PDH_LOG_TYPE_NOT_FOUND

  • 0xC0000BCC - PDH_NO_MORE_DATA

  • 0xC0000BCD - PDH_ENTRY_NOT_IN_LOG_FILE

  • 0xC0000BCE - PDH_DATA_SOURCE_IS_LOG_FILE

  • 0xC0000BCF - PDH_DATA_SOURCE_IS_REAL_TIME

  • 0xC0000BD0 - PDH_UNABLE_READ_LOG_HEADER

  • 0xC0000BD1 - PDH_FILE_NOT_FOUND

  • 0xC0000BD2 - PDH_FILE_ALREADY_EXISTS

  • 0xC0000BD3 - PDH_NOT_IMPLEMENTED

  • 0xC0000BD4 - PDH_STRING_NOT_FOUND

  • 0x80000BD5 - PDH_UNABLE_MAP_NAME_FILES

  • 0xC0000BD6 - PDH_UNKNOWN_LOG_FORMAT

  • 0xC0000BD7 - PDH_UNKNOWN_LOGSVC_COMMAND

  • 0xC0000BD8 - PDH_LOGSVC_QUERY_NOT_FOUND

  • 0xC0000BD9 - PDH_LOGSVC_NOT_OPENED

  • 0xC0000BDA - PDH_WBEM_ERROR

  • 0xC0000BDB - PDH_ACCESS_DENIED

  • 0xC0000BDC - PDH_LOG_FILE_TOO_SMALL

  • 0xC0000BDD - PDH_INVALID_DATASOURCE

  • 0xC0000BDE - PDH_INVALID_SQLDB

  • 0xC0000BDF - PDH_NO_COUNTERS

  • 0xC0000BE0 - PDH_SQL_ALLOC_FAILED

  • 0xC0000BE1 - PDH_SQL_ALLOCCON_FAILED

  • 0xC0000BE2 - PDH_SQL_EXEC_DIRECT_FAILED

  • 0xC0000BE3 - PDH_SQL_FETCH_FAILED

  • 0xC0000BE4 - PDH_SQL_ROWCOUNT_FAILED

  • 0xC0000BE5 - PDH_SQL_MORE_RESULTS_FAILED

  • 0xC0000BE6 - PDH_SQL_CONNECT_FAILED

  • 0xC0000BE7 - PDH_SQL_BIND_FAILED

  • 0xC0000BE8 - PDH_CANNOT_CONNECT_WMI_SERVER

  • 0xC0000BE9 - PDH_PLA_COLLECTION_ALREADY_RUNNING

  • 0xC0000BEA - PDH_PLA_ERROR_SCHEDULE_OVERLAP

  • 0xC0000BEB - PDH_PLA_COLLECTION_NOT_FOUND

  • 0xC0000BEC - PDH_PLA_ERROR_SCHEDULE_ELAPSED

  • 0xC0000BED - PDH_PLA_ERROR_NOSTART

  • 0xC0000BEE - PDH_PLA_ERROR_ALREADY_EXISTS

  • 0xC0000BEF - PDH_PLA_ERROR_TYPE_MISMATCH

  • 0xC0000BF0 - PDH_PLA_ERROR_FILEPATH

  • 0xC0000BF1 - PDH_PLA_SERVICE_ERROR

  • 0xC0000BF2 - PDH_PLA_VALIDATION_ERROR

  • 0x80000BF3 - PDH_PLA_VALIDATION_WARNING

  • 0xC0000BF4 - PDH_PLA_ERROR_NAME_TOO_LONG

  • 0xC0000BF5 - PDH_INVALID_SQL_LOG_FORMAT

  • 0xC0000BF6 - PDH_COUNTER_ALREADY_IN_QUERY

  • 0xC0000BF7 - PDH_BINARY_LOG_CORRUPT

  • 0xC0000BF8 - PDH_LOG_SAMPLE_TOO_SMALL

  • 0xC0000BF9 - PDH_OS_LATER_VERSION

  • 0xC0000BFA - PDH_OS_EARLIER_VERSION

  • 0xC0000BFB - PDH_INCORRECT_APPEND_TIME

  • 0xC0000BFC - PDH_UNMATCHED_APPEND_COUNTER

  • 0xC0000BFD - PDH_SQL_ALTER_DETAIL_FAILED

  • 0xC0000BFE - PDH_QUERY_PERF_DATA_TIMEOUT

Event Tracing for Windows

Le suivi d’événements Windows (ETW, Event Tracing for Windows) est une infrastructure de journalisation qui fournit des données de trace et permet l’analyse dynamique des événements déclenchés par les différents composants du système, dont le noyau et divers pilotes de périphérique.

Dans les grandes lignes, ETW fonctionne sur la base d’un modèle de prestataires et d’abonnés. Des applications et des composants du système peuvent conformément à cette perspective enregistrer et rendre visible des données de trace, et d’autres applications et composants peuvent récupérer et exploiter ces données, le plus souvent à des fins de dépannage ou d’audit. Il est possible d’accéder aux informations émises depuis ETW de nombreuses façons : langages natifs et gérés, scripts, PowerShell, utilitaire Performances, entres autres.

Les applications utilisant ETW entrent dans l’une au moins des catégories suivantes :

  • Contrôleur Un contrôleur démarre et arrête les sessions de journalisation.

  • Fournisseur Un fournisseur définit des classes d’événements pour lesquelles il peut produire des traces.

  • Consommateur Un consommateur sélectionne une ou plusieurs sessions de trace dont il veut lire les données.

Les fonctions mises en œuvre par ETW le sont par l’intermédiaire de la bibliothèque Advapi32 jusque Windows 8, et de la bibliothèque Sechost pour ce qui concerne les versions supérieures du système. Les interfaces idoines, prototypes d’appels et structures de données notamment, sont quant à elles déclarés dans le fichier en-tête EvnTrace.h du kit de développement Windows.

Windows Resource Protection

Pour préserver l’intégrité du système d’exploitation et maintenir au mieux ses capacités opérationnelles, Windows possède une technologie appelée Windows Resource Protection (WRP) qui permet de détecter tout changement suspect de la configuration ou au sein de fichiers, réduisant par là même la possibilité d’altérations nuisibles induites par des logiciels ou des utilisateurs.

Suite logique des fonctionnalité WFP (Windows File Protection) et SFP (System File Protection) des versions de Windows précédant Vista, WRP couvre les éléments que voici :

  • Composants impliqués dans le processus de démarrage

  • Fichiers exécutables et bibliothèques (DLL)

  • Répertoires et fichiers

  • Clés de registre essentielles au bon fonctionnement du système

En interne, la protection offerte par WRP l’est par l’intermédiaire de listes de contrôle d’accès minimales attribués aux paramètres, fichiers et emplacements critiques de la plateforme, listes qui sont configurés pour n’accorder l’accès qu’à un seul compte, en l’occurence le service Trusted Installer. Autrement dit, dans la perspective WRP, même les administrateurs et utilisateurs disposant d’informations d’identification administratives ne peuvent opérer de changements parmi les ressources protégées.

WRP possède une copie des fichiers indispensables au démarrage de Windows. Ces fichiers sont sauvegardés dans le répertoire servant de cache à l’emplacement \Windows\winsxs\Backup. Les fichiers du système protégés par WRP mais non utiles au démarrage ne sont pas copiés dans le répertoire de cache. La taille de ce répertoire ainsi que la liste des fichiers qu’il contient ne sont pas modifiables.

Vérificateur de ressources (Sfc)

Expression parmi les plus manifestes de la protection des ressources Windows, le Vérificateur de ressources est un outil en ligne de commandes qui vérifie que la plateforme possède les versions correctes des fichiers système protégés. Pour utiliser le Vérificateur de ressources, ouvrez une fenêtre d’invite de commandes en tant qu’administrateur et tapez la commande Sfc suivie du paramètre approprié. Le tableau suivant liste les paramètres admissibles en matière d’interaction avec le programme Vérificateur de ressources.

Table 22. Paramètres du Vérificateur de ressources.

/SCANNOW

Analyse les fichiers protégés et répare ceux éventuellement endommagés.

/VERIFYONLY

Analyse les fichiers protégées mais n’effectue aucune pas de réparation.

/VERIFYFILE

Analyse le fichier dont le chemin d’accès est spécifié.

/OFFBOOTDIR

Pour les réparations hors ligne. Spécifie l’emplacement du répertoire d’amorçage hors ligne.

/OFFWINDIR

Pour les réparations hors ligne. Spécifie l’emplacement du répertoire Windows hors ligne.

Dans l’éventualité où Sfc découvre qu’un fichier sous sa tutelle a été remplacé, modifié ou est corrompu, l’utilitaire se met alors en quête d’une mouture correcte dudit fichier depuis le répertoire cache prévu à cet égard : \Windows\System32\Dllcache pour les versions de Windows antérieures à Vista et \Windows\Winsxs\Backup pour les versions de Windows depuis Vista. S’il en trouve une, l’élément incriminé est alors supprimé afin de céder la place à une version attendue, dûment approuvée - et par ailleurs signée.

Les investigations menées sous la houlette du Vérificateur de ressources, de même que les actions qui potentiellement en découlent (autrement dit les réparations), peuvent s’étendre à l’ensemble des fichiers protégées du système, ou à plus petite échelle ne concerner qu’un seul d’entre eux. Dans ce second cas de figure, indiquez auprès des commutateurs verifyfile et scanfile le le chemin d’accès complet à un fichier. Par exemple, sfc /verifyfile=c:\windows\system32\kernel32.dll vérifie si le fichier kernel32.dll est valide.

Sfc consigne les détails relatifs aux opérations effectuées par ses soins via le fichier CBS.log, situé sous \Windows\Logs\CBS. Chaque entrée dans ce journal en lien avec Sfc comporte la balise prédéfinie [SR], de sorte que vous puissiez repérer facilement quelles procédures de vérification et/ou de réparation ont eu lieu. Pour effectuer des recherches parmi ce fichier, utilisez la commande findstr.

Threads système auxiliaires

Tôt dans la phase d’amorçage du système, Windows orchestre la création parmi le processus System de plusieurs threads, appelés threads système auxiliaires, chargés d’effectuer des taches pour le compte d’autres threads.

L’un des rôles premiers des threads système auxiliaires est d’agir en tant qu’intermédiaire entre des threads exécutés au niveau IRQL haut et des opérations dont la nature et/ou les caractéristiques les prédisposent à un IRQL inférieur. Par exemple, une routine DPC exécutée dans un contexte de thread à l’IRQL DPC/dispatch (car l’exécution DPC peut usurper n’importe quel thread du système) pourrait avoir besoin d’accéder au pool paginé. Etant donné, d’une part, qu’il est impossible de satisfaire aux défauts de page au niveau DPC/dispatch, et d’autre part, qu’une routine DPC ne peut pas diminuer l’IRQL, elle doit en l’occurrence passer le relais pour ce genre de traitement à un thread exécuté à un IRQL inférieur, ce à quoi répond précisément le mécanisme des threads auxiliaires.

Un autre avantage procuré par les threads système auxiliaires, du reste non le moindre, réside dans la diminution de la surcharge d’ordonnancement et de mémoire induite par la multiplication des threads dans le système.

Pilotes de périphériques et composants de l’exécutif interagissent avec les threads auxiliaires en premier lieu par l’intermédiaire des fonctions ExQueueWorkItem et IoQueueWorkItem, toutes deux chargées d’insérer un élément de travail (work item) dans une file d’attente où le système recherche des tâches à accomplir. Chaque élément de travail contient un pointeur vers une routine de rappel et un paramètre spécifiant les informations de contexte qui seront utiles quand ladite routine prendra vie. A un moment ultérieur, un thread système auxiliaire supprimera l’élément de travail de sa file et exécutera la routine idoine. Lorsque cette dernière se termine, le thread système auxiliaire vérifie si d’autres éléments de travail sont en attente et, si oui, les traite. Cette approche et ses effets se poursuivent indéfiniment.

Il existe trois types de thread système auxiliaires :

  • Les threads auxiliaires différés, exécutés au niveau de priorité 12, prennent en charge des fonctions qui ne sont pas considérés comme temporellement critiques et peuvent voir leur pile remisée dans un fichier de pagination.

  • Les threads auxiliaires critiques, exécutés au niveau de priorité 13, prennent en charge des fonctions temporellement critiques.

  • L’unique thread auxiliaire hypercritique est exécuté au niveau de priorité 15 et a sa pile toujours présente en mémoire physique.

Le nombre de threads auxiliaires critiques est revue en permanence en fonction de la charge de travail de l’ordinateur. Chaque seconde, un sous-ensemble du balance set manager examine le besoin de nouveaux threads auxiliaires critiques et, si ce dernier est jugé réel, en crée un. Les threads créés par ce biais sont dits threads auxiliaires dynamiques ; la création d’un tel thread exige que soient remplies un certain nombre de conditions, à savoir :

  • La file de travail critique contient des éléments à traiter.

  • Le nombre de threads auxiliaires critiques inactifs est inférieur au nombre de processeurs dont dispose le système. (Les threads critiques inactifs le sont du fait d’attendre soit des éléments de travail, soit des objets dispatcher.)

  • Le nombre de threads auxiliaires dynamiques est inférieur à 16.

Dans la configuration par défaut, le nombre initial de threads auxiliaires différés et critiques dépend de la capacité mémoire du système (valeur retournée par MmQuerySystemSize) et de la version de Windows. Les administrateurs peuvent apporter des modifications sur ces aspects en modifiant les valeurs AdditionalCriticalWorkerThreads et AdditionalDelayedWorkerThreads sous la clé de registre HKLM\SYSTEM\CurrentControlSet\Control\SessionManager\Executive.

La commande !exqueue du débogueur noyau affiche des informations détaillées en ce qui concerne les threads système auxiliaires.

Une chose importante à garder à l’esprit lors de l’utilisation des threads système auxiliaires se situe dans le fait que tous les composants noyau se partagent à cet égard les mêmes ressources (une file de travail ne peut satisfaire qu’un nombre limité de threads). Les opérations exécutés de la sorte, quand elles sont couteuses en temps, retardent l’exécution d’autres services, et peuvent de ce fait entrainer une diminution plus ou moins accentuée des performances du système. Par conséquent, l’exécution par l’intermédiaire d’éléments de travail devrait dans l’idéal ne concerner que des séquences de traitement relativement courtes.

LPC (Local Procedure Call)

L’appel de procédure locale (Local Procedure Call, mais aussi Lightweight Procedure Call ou Local Inter-Process Communication) est une technologie de communication inter processus pour transmission rapide de messages. S’imposant comme l’une des clés de voûte du modèle de communication de Windows (architecture client-serveur), LPC se rencontre très fréquemment partout dans le système d’exploitation, y compris les scénarios que voici :

  • Les programmes applicatifs requièrent des services de la part des différents sous-systèmes de Windows via LPC. Par exemple, quelques API Windows aboutissent à l’envoi de messages au processus du sous-système Windows, Csrss.

  • Les applications Windows qui emploient RPC (Remote Procedure Call) utilisent indirectement LPC quand elles spécifient RPC local (protocole ncalrpc), variante de RPC employée pour la communication entre processus d’un même système.

  • Le processus serveur d’authentification de sécurité locale (Lsass), le gestionnaire de session (Smss) et le gestionnaire de contrôle des services (Scm) se servent de LPC pour communiquer avec leur processus client respectifs.

  • Certains processus système s’appuient sur LPC de sorte à interagir entre eux, par exemple Winlogon et Lsass, ou encore le moniteur de références de sécurité et Lsass.

Essentiellement fondé sur le paradigme du passage de messages, LPC s’utilise en principe entre un processus serveur et un ou plusieurs processus client. Il est possible de créer une connexion LPC entre deux processus mode utilisateur, ou entre un composant mode noyau et un processus utilisateur.

Similaire par bien des aspects à RPC (Remote Procédure Call), lequel protocole est utilisé dans une vaste gamme de systèmes d’exploitation (y compris, du reste, Windows) pour faire du traitement distribué sur un réseau, LPC est par contraste optimisé pour l’usage local et est spécifique à Windows.

Les fonctions mettent en oeuvre LPC ont comme point d’ancrage ntdll et ntoskrnl.exe. Elles ne sont en l’occurence pas directement accessibles depuis l’API Windows.

Le composant LPC distingue deux types de ports : les ports de connexion et les ports de communication. Les ports de connexion sont des objets dotés d’un nom, visibles de tous les processus, qui donnent aux applications un moyen commode de mettre un canal de communication, lequel canal est dans la perspective LPC constitué d’une paire de ports privés de communication : un pour les message du client vers le serveur et l’autre pour les messages du serveur vers le client. Les canaux de communication supportent un mécanisme de rappel. Le client et le serveur peuvent donc accepter des requêtes tandis qu’ils attendent une réponse. Voici, en définitive, quelles sont les différentes extrémités d’une communication LPC. Voici, en définitive, quelles sont les différentes sorts de port potentiellement visibles parmi une communication LPC.

  • Port de connexion serveur Port nommé créé par le serveur de façon à être à l’écoute des éventuelles connexions entrantes, et sur lequel les processus client peuvent se connecter pour dialoguer avec le serveur.

  • Port de communication serveur Port non nommé permettant au processus serveur de dialoguer avec un processus client donné. Le serveur a un seul port de ce genre par client actif.

  • Port de communication client Port non nommé utilisé par un processus client pour communiquer avec un processus serveur donné.

  • Port de communication anonyme Port non nommé utilisé par deux threads d’un même processus pour communiquer.

LPC s’utilise généralement comme ceci :

  1. Un serveur crée un objet de type port de connexion nommé (NtCreatePort) puis donne lieu à une écoute du port en question (NtListenPort).

  2. Un client fait une demande de connexion à ce port (NtConnectPort).

  3. Le serveur détermine si la demande est valide et, si elle l’est, l’accepte (NtAcceptConnectPort, suivie d’un appel à NtCompleteConnectPort). Il y a à ce moment création de deux ports sans nom, un port de communication serveur et un port de communication client. Le client et le serveur se servent alors de ces nouveaux ports pour leur communication.

  4. Le serveur enregistre une boucle par l’intermédiaire de laquelle il continue à traiter de nouveaux messages et à y répondre en conséquence (NtReplyWaitReceivePort).

  5. Le client envoie une nouvelle demande au serveur et attend que ce dernier lui donne suite (NtRequestWaitReplyPort). Cette étape et la précédente se répètent tout le temps du lien entre serveur et client. 
 LPC offre trois méthodes d’échange de messages :

    • La première méthode, également la plus simple d’entre elles, est adaptée aux petits messages (d’au plus 256 octets). Dans ce cas, la file d’attente de messages du port est employée comme espace de stockage intermédiaire et les messages sont copiées d’un processus à l’autre. Le noyau effectue une copie du tampon contenant le message depuis l’espace d’adressage du processeur émetteur vers l’espace d’adressage système, puis réitère l’opération dans le sens nécessaire, autrement dit depuis l’espace d’adressage système vers l’espace d’adressage du processus récepteur.

    • La seconde méthode, approprié aux messages plus grands, s’appuie sur un object section de mémoire partagée donnant lieu auprès des processus émetteur et récepteur à une représentation du canal de communication. Dans cette configuration, l’émetteur écrit tout d’abord dans la section partagée les informations qu’il souhaite publier, puis envoie dans la file d’attente du port un court message (en utilisant la méthode décrite plus haut) qui contient des pointeurs vers l’emplacement des données dans la section partagée, permettant de cette façon au receveur de les voir.

    • La troisième technique de messages LPC, mise en place du moment qu’un serveur veut interagir avec des données trop volumineuses pour être hébergées dans une section partagée, s’appuie sur des API qui lisent/écrivent directement dans l’espace d’adressage d’un processus. Le composant LPC fournit un petit nombre de fonctions permettant au serveur de procéder de la sorte, et ainsi pouvoir accéder à une donnée dans un client. (Pour d’évidentes raisons de sécurité, l’inverse n’est bien entendu pas possible.)

Table 23. Services concernant LPC

NTSTATUS

NtAcceptConnectPort (PHANDLE PortHandle, PVOID PortContext, PPORT_MESSAGE ConnectionRequest, BOOLEAN AcceptConnection, PPORT_VIEW ServerView, OUT PREMOTE_PORT_VIEW ClientView)

NTSTATUS

NtCreateWaitablePort (PHANDLE PortHandle, POBJECT_ATTRIBUTES ObjectAttributes, ULONG MaxDataSize, ULONG MaxMessageSize, ULONG Reserved)

NtImpersonateClientOfPort

NTSTATUS

NtListenPort (HANDLE PortHandle, PPORT_MESSAGE Message)

NTSTATUS

NtQueryInformationPort (HANDLE PortHandle, PORT_INFORMATION_CLASS PortInformationClass, PVOID PortInformation, ULONG PortInformationLength, PULONG ReturnLength)

NtQueryPortInformationProcess

NTSTATUS

NtReplyPort (HANDLE PortHandle, PPORT_MESSAGE ReplyMessage)

NTSTATUS

NtRequestPort (HANDLE PortHandle, PPORT_MESSAGE LpcMessage)

NTSTATUS

NtRequestWaitReplyPort (HANDLE PortHandle, PPORT_MESSAGE LpcReply, PPORT_MESSAGE LpcRequest)

Table 24. Variables noyau concernant LPC
Variable Type Description

AlpcpPortMapping

GENERIC_MAPPING

Mappage générique des droits d’accès aux ports (A)LPC

LpcPortObjectType

POBJECT_TYPE

LpcWaitablePortObjectType

POBJECT_TYPE

APC (Asynchronous Procedure Calls)

Les APC (Asynchronous Procedure Calls) offrent un moyen aux programmes utilisateur et aux composants système d’exécuter du code dans le contexte (et partant, dans l’espace d’adressage) d’un thread spécifique. Étant donné que les APC sont mis en file pour exécution dans le contexte d’un thread choisi (par opposition à un thread arbitraire) et qu’ils sont exécutés à un IRQL inférieur au niveau DPC/dispatch, ils ne sont pas soumis aux mêmes restrictions qu’un DPC. Une routine APC peut ainsi acquérir des ressources, attendre des handles d’objet, subir des défauts de page, et ainsi de suite.

Il existe deux sortes d’APC : mode noyau et mode utilisateur, l’un et l’autre se différenciant essentiellement par les conditions attendues et par la temporalité dans laquelle le traitement qui résulte d’une interruption APC peut entrer en lice (du point de vue de l’ordonnancement). Ainsi, les APC mode noyau interrompent un thread et exécutent une procédure à l’insu et sans le consentement des parties concernées (autrement dit le thread cible) ; les APC mode utilisateur sont quant à eux livrés à un thread seulement quand ce dernier se trouve dans une situation spécifique, à savoir l’état d’attente alertable. La catégorie des APC mode noyau se subdivise encore en deux sous-types : normal et spécial. Les APC mode noyau normales sont exécutées au niveau passif, les APC mode noyau spéciales au niveau APC. Un thread peut désactiver les APC normales par le biais de la routine KeEnterCriticalRegion, la livraison des APC spéciales étant dans cette configuration toujours maintenue. Un thread peut désactiver à la fois les APC normales et les APC spéciales soit par augmentation de l’IRQL au niveau APC (KeRaiseIrql), soit en s’en remettant à une région gardée (KeEnterGuardedRegion).

Plusieurs des mécanismes centraux pris en charge par Windows le sont via des APC. Le système emploie par exemple des APC pour initier l’exécution des threads, compléter les entrées/sorties, mettre fin à des processus et des threads, attacher un débogueur à une applications, gérer les expirations de minuterie, etc.

Du code mode utilisateur peut mettre en file d’attente un APC pour un thread par le biais de la fonction QueueUserAPC, laquelle s’appuie en interne sur le service système NtQueueUserApcThread. Suite à cet appel, le noyau alloue alors depuis le pool paginé un objet de contrôle KAPC, associé à l’APC en vue de le représenter. Dans l’éventualité où la quantité de mémoire disponible est trop faible pour répondre positivement à la demande, l’opération échoue, empêchant de ce fait la distribution de l’APC - ce qui dans le cas contraire serait susceptible d’entraver le fonctionnement efficace du système d’exploitation (relativement quand même à ce à quoi l’APC est employé). Pour anticiper un tel scénario, une application peut lors de son démarrage utiliser NtAllocateReserveObject afin de demander au noyau l’allocation préalable de la structure susmentionnée.

Comme nous l’avons déjà dit, les APC mode utilisateur sont livrés à un thread seulement quand il est dans un état d’attente alertable, ce qui peut potentiellement impliquer un délai plus ou moins long entre le moment où un APC est mis en file et le moment où la routine APC apparentée est réellement exécutée. Quand un thread en état alertable a un APC mode utilisateur en suspens, le noyau alerte le thread, passe le relais à la routine APC puis, du moment que cette dernière a fini, reprend l’exécution du thread. Dans l’éventualité où un thread en état alertable voit son attente satisfaite avant mise en file de l’APC (ce qui a pour effet en définitive de court-circuiter l’état alertable), la routine n’est pas exécutée, et le sera quand les circonstances se montreront propices (autrement dit la prochaine fois que le thread sera en état d’attente d’altertable.

Chaque APC est au niveau du noyau représenté par le biais d’une structure KAPC.

KAPC
lkd> dt nt!_KAPC
   +0x000 Type             : UChar
   +0x001 SpareByte0       : UChar
   +0x002 Size             : UChar
   +0x003 SpareByte1       : UChar
   +0x004 SpareLong0       : Uint4B
   +0x008 Thread           : Ptr64 _KTHREAD
   +0x010 ApcListEntry     : _LIST_ENTRY
   +0x020 KernelRoutine    : Ptr64     void
   +0x028 RundownRoutine   : Ptr64     void
   +0x030 NormalRoutine    : Ptr64     void
   +0x020 Reserved         : [3] Ptr64 Void
   +0x038 NormalContext    : Ptr64 Void
   +0x040 SystemArgument1  : Ptr64 Void
   +0x048 SystemArgument2  : Ptr64 Void
   +0x050 ApcStateIndex    : Char
   +0x051 ApcMode          : Char
   +0x052 Inserted         : UChar

IRQL

Au delà de l’importance préférentielle donnée aux interruptions sur le plan matériel, Windows met en exergue de cette dynamique divers niveaux de requête d’interruptions (IRQL, Interrupt Request Level), lesquelles servent à prioriser les interruptions émanant des différents composants du système, autant physiques que logiques. Le noyau représente les IRQL en interne sous forme de numéros compris entre 0 et 31 sous x86 et entre 0 et 15 sous x64 ; plus le numéro est élevé, plus la priorité est forte.

Chaque processeur a une configuration IRQL qui détermine quelles sont les interruptions que peut recevoir ce processeur. Les interruptions servies dans ce contexte le sont par ordre de priorité, une interruption préemptant le traitement d’une autre de priorité inférieure. Les interruptions ayant pour origine une source dont l’IRQL est supérieur au niveau courant, impliquant dès lors une prise en charge la plus rapide possible, interrompent le processeur, tandis que les interruptions provenant de sources ayant des IRQL inférieurs ou égaux au niveau courant ne l’interrompent pas, et sont de la sorte remises à plus tard. Modifier l’IRQL d’un processeur étant une opération délicate, elle ne peut s’effectuer qu’en mode noyau, les threads mode utilisateur n’ayant dans ce domaine, et à quelque niveau que ce soit, aucun impact. Sur le plan factuel, cela signifie que l’IRQL d’un processeur est toujours au niveau le plus faible (autrement dit le plus sujet aux interruptions de toutes sortes) quand il exécute du code mode utilisateur, et ce n’est dès lors que quand le processeur exécute du code mode noyau que l’IRQL peut être supérieur.

Un thread ajuste (augmente ou diminue) l’IRQL du processeur sur lequel il est exécuté selon la nature des tâches qu’il envisage d’accomplir (attendre des objets dispatcher, accéder au pool paginé, et ainsi de suite). Ainsi, quand une interruption à haute priorité se manifeste, le gestionnaire d’interception augmente l’IRQL du processeur afin de lui donner la valeur de l’IRQL assignée à la source de l’interruption. Cette augmentation masque toutes les interruptions égales ou inférieures à cet IRQL (sur ce processeur uniquement), ce qui a pour effet de garantir que le processeur assurant le traitement de l’interruption ne pourra être monopolisé qu’au bénéfice d’une interruption de priorité supérieure. Après exécution de de la routine de service idoine, le dispatcher abaisse l’IRQL, faisant au passage éventuellement apparaitre des interruptions jusqu’alors masquées. (Les interruptions masquées sont soit traitées par un autre processeur, soit suspendues jusqu’à ce que la configuration IRQL du processeur s’y prête). Par conséquent, tous les composants du système, y compris le noyau et les pilotes de périphérique, s’efforcent de maintenir l’IRQL à son seuil le plus faible (en l’occurence le niveau passif, sur lequel nous reviendrons plus loin).

S’ils peuvent sembler apparentés, les niveaux de priorité d’interruption n’existent pas à la même échelle ni n’ont la même signification que les priorités d’ordonnancement de thread. Une priorité d’ordonnancement est une valeur dont la portée ne va pas au-delà d’un thread, éventuellement d’un groupe de threads, tandis qu’un IRQL est un attribut de source d’interruption (processeur, clavier, souris, etc.).

  • L’IRQL le plus faible, à quoi correspond le niveau passif (parfois appelé niveau bas), se rapporte au contexte d’exécution normale de threads, dans lequel toutes les interruptions peuvent survenir.

Les niveaux DPC/dispatch et APC sont des interruptions logicielles générées par le noyau et les pilotes de périphériques en différentes occasions.

Les IRQL périphérique servent à prioriser les interruptions émanant des périphériques.

Le niveau horloge est employé pour l’horloge du système, que le noyau utilise pour gérer l’heure ainsi que pour mesurer et allouer le temps processeur aux threads.

Mécanismes de gestion

Ce chapitre procure une vue détaillée de quelques-uns des dispositifs fondamentaux de Microsoft Windows en rapport avec l’administration et la configuration du système :

  • Registre

  • Services

  • WMI (Windows Management Instrumentation)

  • Événements

Registre

Jouant un rôle clé dans la supervision et le contrôle des systèmes, composants et logiciels Windows, le registre sert de lieu d’hébergement à moult paramètres de configuration, qu’ils soient de niveau global ou spécifiques à l’utilisateur. Cela inclut, par exemple, les options d’amorçage du noyau, les paramètres d’applications et de pilotes, les préférences et affinités des utilisateurs, leur profil de sécurité, et bien d’autres.

Une large majorité des utilisateurs voient le registre tel un ensemble de données statiques rangées sur le disque dur, à la façon, par exemple, d’une boite de dépôt. Si elle a de solides raisons d’exister, cette perceptive est aussi très réductrice, dans la mesure où, ainsi que vous le verrez plus loin, le registre constitue en réalité une passerelle vers toutes sortes de données mouvantes dans le temps : état du système, liste des services actifs, reflets des structures gérées en mémoire par l’exécutif et le noyau, compteurs de performance, etc.

Table 25. Fonctions Windows concernant le registre

Fonction

Description

RegCloseKey

Ferme la clé spécifiée.

RegCreateKey

Crée, ou éventuellement ouvre, une clé de registre.

RegDeleteKey

Supprime une clé.

RegEnumKeyEx

Liste les sous-clés présentes sous une clé.

RegEnumValue

les valeurs contenues dans une clé.

RegOpenKeyEx

Ouvre une clé de registre.

RegQueryValueEx

Interroge la clé spécifié.

RegSetValueEx

Crée ou modifie les valeurs contenues dans une clé.

Origines du registre

S’il dispose aujourd’hui bel et bien d’une place prépondérante au sein des systèmes Microsoft, le registre n’a pas toujours toujours endossé des responsabilités aussi lourdes. Les versions initiales de Windows se passaient du reste totalement de ce genre de procédé, et les quelques déclinaisons qui suivirent (jusqu’à Windows 95 en réalité) ne l’employaient que de façon très superficielle.

Avant Windows 3.1, les plateformes Windows utilisaient pour la mémorisation des paramètres relatifs aux composants systèmes et aux programmes des fichiers INI. Hébergeant des données de nature uniquement textuelle (donc facilement manipulable au travers une large gamme de logiciels), ces fichiers étaient divisées en sections comportant chacune un nombre plus ou moins important de déclarations. Chaque donnée était déclarée par un nom de variable, suivi par un signe égal, lui-même suivi par la valeur de la variable. Les noms des sections étaient indiqués entre crochets et tout ce qui suivait ce nom appartenait à la section. Partant de cette nomenclature, un fichier INI ressemble à ce qui suit.

[section 1]
Parameter1=Value1
Parameter2=Value2
Parameter3=Value3

Avec l’apparition d’OLE dans Windows 3.1, et plus généralement des composants basés sur COM, les besoins en stockage et consultation de paramètres divers augmentèrent considérablement, cela avec comme effet secondaire d’attirer l’attention sur les limites, tant pratiques que conceptuelles, des fichiers INI. Depuis la sortie du système d’exploitation Windows NT, en 1993, l’essentiel des éléments de la configuration est enregistré à l’échelle d’une base de données dévolue spécifiquement à cet usage, en l’occurence le registre.

Composants du registre

Les éléments suivants sont à considérer pour leurs relations (plus ou moins directes) avec le registre :

  • Gestionnaire de configuration Le gestionnaire de configuration est le composant de l’exécutif Windows chargé d’implémenter la base de données du registre.

  • Ruches La sauvegarde physique (sur disque) de la base de données du registre se présente comme un ensemble de fichiers appelés ruches. Chaque ruche correspond à un fichier, et contient une arborescence de registre.

  • Regedit Windows inclut nativement plusieurs outils afin de superviser le registre, dont Regedit, qui permet d’agir de manière très fine dans la configuration du système, et met entre les mains d’utilisateurs avancés la possibilité de modifier la base, et d’attribuer des droits spécifiques sur les clés du registre. Un portait plus large de l’Editeur de Registre est donné plus loin dans ce chapitre.

  • Clés, sous-clé, valeurs La base de données du registre est faite de clés, de sous-clés et de valeurs. Une clé peut contenir d’autres clés (sous-clés) ou des valeurs. Une valeur contient des données.

  • Synchronisation de ruche Un thread système fait de la synchronisation de ruche, opération rendue nécessaire par le fait que les données mémoire correspondant au registre doivent un temps après leur modification être conservées (écrites) sur le disque (ce que l’on appelle l’écriture différée).

Scénarios d’utilisation du Registre

Windows sollicite les données de configuration stockées dans le registre en de multiples occasions :

  • Amorçage du système Lors de l’amorçage, le système lit des paramètres spécifiant quels sont les pilotes de périphérique et les services à charger et comment les divers composants (gestionnaire de mémoire, gestionnaire de processus, et d’autres.) interagissent entre eux et optimisent le comportement du système. La structure initiale du registre et nombre de paramètres par défaut sont définis par un prototype du registre qui est copié sur le disque lors d’une nouvelle installation de Windows.

  • Ouverture de session Lors d’une ouverture de session, le registre sert à la mise en conformité de l’environnement par rapport aux préférences de l’utilisateur connecté. Cela comprend, par exemple, les désignations (les lettres) de lecteur réseau, l’économiseur d’écran, l’environnement de bureau (comprendre l’explorateur), le style des menus, le papier peint du bureau, l’emplacement des icônes, etc.

  • Démarrage d’application Lors de son démarrage, une application peut éventuellement orienter son comportement en fonction de paramètres de niveau système, en rapport par exemple à des informations de licence ou à d’autres données qualitatives, ou de niveau utilisateur, par exemple l’emplacement des menus et barres d’outils ou la liste des derniers documents manipulés. Certaines applications surveillent leurs données de configuration dans le registre et lisent les paramètres modifiés quand elles détectent un changement.

  • Installation d’application Le registre permet aux applications de disposer d’un endroit unique où conserver leurs options de configuration. Les programmes d’installation des applications créent des paramètres et des profils qui reflètent les choix de configuration de l’installation.

  • Ajout de nouveau pilote Lors de l’installation d’un pilote de périphériques, le système de prise en charge Plug and Play créé dans le registre des paramètres indiquant au gestionnaire d’E/S comment démarrer et configurer le pilote.

  • Création de profils utilisateur La création de nouveaux utilisateurs alimente implicitement le registre, dans la mesure où c’est à cet endroit qu’est rangé l’ensemble des données spécifiques à un utilisateur et à ses préférences.

  • Modification de la configuration Que vous modifiiez des paramètres de niveau système ou de niveau application, les modifications idoines sont souvent reportées dans le registre. Elles sont de cette façon pérennes et existent au delà une réinitialisation du système.

Organisation du registre

Le Registre est agencée sous une forme analogue à celles de volumes disque, faite en l’occurence d’éléments empruntés aux systèmes de fichiers. Les informations dans le Registre sont rangées dans un système en arbre contenant des clés et des valeurs, équivalents des répertoires et des fichiers. Une clé peut contenir d’autres clés (sous-clés) ou des valeurs. Une valeur, en revanche, contient des données. Les clés de premier niveau (dans l’arbre) sont les clés racine.

Les conventions de nommage à l’intérieur du Registre s’inspirent de celles à l’oeuvre dans une partition Windows. Ainsi, une valeur de nom y stockée dans une clé de nom x est identifié par le nom x\y. On retrouve comme élément utilisé pour la classification la barre contre-oblique. S’il vient seul (\) ce caractère représente la racine du registre. Autrement, il permet de repérer sans ambiguïté clés et valeurs de registre.

Types de données du registre

A l’instar des langages de programmation, le registre Windows offre plusieurs types primitifs grâce auxquels représenter (et donc manipuler) des informations de toutes sortes, tels que chaînes, compteurs, intervalles, booléens (valeurs oui/non), liens symboliques (clé pointant vers une autre), etc.

Le tableau ci-dessous apporte un bref éclairage sur les quelques types de données (au nombre, du reste, de 15) admis dans le Registre, et les sections qui suivent des informations complémentaires en ce qui concerne chacun d’entre eux.

Table 26. Types des valeurs du registre

Type

Description

REG_BINARY

Données binaires de longueur variable

REG_DWORD

Nombre de 32 bits

REG_DWORD_BIG_ENDIAN

Nombre de 32 bits avec octet de poids fort en premier

REG_DWORD_LITTLE_ENDIAN

Nombre de 32 bits avec octet de poids faible en premier (équivaut à REG_DWORD)

REG_EXPAND_SZ

Chaîne Unicode de longueur variable

REG_FULL_RESOURCE_DESCRIPTOR

Description de ressource matérielle

REG_LINK

Lien symbolique

REG_MULTI_SZ

Tableau de chaînes

REG_NONE

Aucun type

REG_QWORD

Nombre de 64 bits

REG_QWORD_BIG_ENDIAN

Nombre de 64 bits avec octet de poids fort en premier

REG_QWORD_LITTLE_ENDIAN

Nombre de 64 bits avec octet de poids faible en premier (équivaut à REG_QWORD)

REG_RESOURCE_LIST

Description de ressource matérielle

REG_RESOURCE_REQUIREMENTS_LIST

Exigences de la ressource REG_SZ

REG_BINARY

Les valeurs REG_BINARY renferment des données binaires brutes, telles que des clés cryptographiques ou des mots de passe chiffrés. Par nature, de telles informations n’incorporent pas de commodité ni au niveau de l’analyse ni de la présentation (pas de caractère de terminaison, d’expansion de chaines, etc.) Une large majorité des utilitaires permettant de visualiser le registre montrent ces informations au format hexadécimal. Pour voir concrètement à quoi ressemble des données du type REG_BINARY, consultez par exemple la valeur nommée FailureActions sous la clé HKLM\SYSTEM\CurrentControlSet\Services\lmhosts.

REG_DWORD

Le type REG_DWORD stocke un nombre entier sur 4 octets (32 bits). Moults paramètres sont dépeints à l’échelle de ce format, par exemple des compteurs, intervalles, booléens (valeurs oui/non), masques binaires, etc. Les valeurs connexes sont DWORD_LITTLE_ENDIAN, où l’octet le moins important se trouve à l’adresse la plus basse, et REG_DWORD_BIG_ENDIAN, où l’octet le moins important se trouve à l’adresse la plus haute.

REG_EXPAND_SZ

Les valeurs REG_EXPAND_SZ renferment des chaînes extensibles qui elles-mêmes intègrent des variables résolues lors de leur utilisation. Les applications peuvent intégrer un jeton spécial dans la chaîne de caractères, signifiant que la chaîne contient un élément dont le système devra se charger de remplacer le contenu. Le jeton est une variable dont le nom est délimité par le caractère %. Par exemple, la variable d’environnement %SystemRoot% est un type REG_EXPAND_SZ représentant le dossier Windows effectif. Quand le système lit la chaine de caractères, il remplace %SystemRoot% par le chemin d’accès complet au répertoire d’installation du système d’exploitation.

REG_FULL_RESOURCE_DESCRIPTOR

Le type REG_FULL_RESOURCE_DESCRIPTOR enregistre des informations sur les ressources système requises par un périphérique particulier. Etant donné sa nature, ce type n’est visible que parmi les sous-clés de HKLM\HARDWARE.

Le type REG_LINK instaure dans le registre différents niveaux d’indirection et, à l’instar des liens symboliques des systèmes de fichier, permet à une clé de pointer de façon transparente vers une autre clé ou valeur. Quand vous traversez le registre via un lien, la recherche de chemin continue à partir de la cible du lien. Par exemple, si \Root1\Link à une valeur REG_LINK \Root2\RegKey, et que RegKey contient la valeur RegValue, alors deux chemins identifient RegValue : \Root1\Link\RegValue et \Root2\RegKey\RegValue. Windows fait un usage intensif des liens : trois des six clés de premier niveau définies dans le registre sont en réalité des liens vers des sous-clés des trois autres clé racine. Les liens sont recréés dynamiquement après chaque réamorçage du système.

REG_MULTI_SZ

Le type REG_MULTI_SZ est un ensemble de valeurs REG_SZ et correspond à ce titre à une collection de chaine. Les valeurs qui contiennent des listes ou plusieurs valeurs dans un format que l’utilisateur peut lire sont généralement enregistrées sous cette forme. Les entrées sont séparées par des espaces, des virgules ou autre forme de ponctuation - c’est donc aux applications de savoir comment extraire une portion spécifique d’une valeur REG_MULTI_SZ.

REG_NONE

Très certainement le plus basique des types de données exprimables au sein du registre, REG_NONE a trait au seul fait qu’un emplacement soit laissé vacant ou est au contraire occupé. Les composants utilisant ce schéma le font généralement dans l’optique de vérifier la présence d’une clé ou d’une valeur pour adapter leur comportement au moment de l’exécution.

REG_QWORD

Le type REG_QWORD représente des données par un nombre entier 64 bits. Les valeurs connexes sont REG_QWORD_LITTLE_ENDIAN (nombre de 64 bits avec octet de poids faible en premier) et REG_QWORD_BIG_ENDIAN (nombre de 64 bits avec octet de poids fort en premier). Notez que, Windows étant conçu pour fonctionner sur des architectures informatiques little-endian, les valeurs REG_QWORD et REG_QWORD_LITTLE_ENDIAN sont équivalentes.

REG_RESOURCE_LIST

Le type REG_RESOURCE_LIST stocke des informations sur les ressources utilisée par un pilote de périphérique matériel ou l’un des périphériques physiques qu’il contrôle. Ces données sont détectées et écrites par le système dans l’arborescence HKLM\HARDWARE\ResourceMap.

REG_SZ

Le type REG_SZ correspond à une chaine de caractères de longueur variable. Les valeurs REG_SZ renferment généralement des messages, des noms de fichier, des données de chemin, etc.

Structure du registre

Si les informations publiées via le Registre sont de forme et de nature diverses (un système comme Windows est entouré d’un nombre important de logiciels et matériels, donc a fortiori de très nombreux paramètres de configuration), il est possible de dresser la cartographie dudit lieu en fonction des données qui y sont stockées.

Clés volatiles

Certaines clés et valeurs du Registre sont volatiles, c’est-à-dire qu’elles peuvent disparaitre à tout moment, et ne perdurent surtout pas au-delà de l’extinction de la machine. Par exemple, aucune des données que renferme la clé HKLM\HARDWARE n’ont d’existence sur le disque, mais uniquement en mémoire. Les clés volatiles sont pratiques pour les données qu’il n’est pas nécessaire de conserver entre deux démarrages.

Clés racines

Le registre est organisé à la façon d’une structure arborescente à six niveaux, dites clés racines (il est impossible d’en ajouter ou supprimer), montrées au tableau suivant.

Table 27. Clés racine
Clé racine Description

HKEY_CLASSES_ROOT

Contient les données d’associations de fichier et de déclarations d’objet COM

HKEY_CURRENT_CONFIG

Contient des données relatives au le profil matériel courant

HKEY_CURRENT_USER

Contient les données associées à l’utilisateur courant

HKEY_LOCAL_MACHINE

Contient des informations de configuration spécifiques à l’ordinateur

HKEY_PERFORMANCE_DATA

Contient des données concernant les performances.

HKEY_USERS

Contient les données concernant les comptes/profils utilisateur

Les noms des clés racine commencent par la lettre H, car ils représentent des handles (H) Windows vers les clés (KEY). Pour des raisons de concision, les noms des clés racine sont souvent montrés sous une forme plus brève, par exemple HKCU pour HKEY_CURRENT_USER, HKLM pour HKEY_LOCAL_MACHINE, et ainsi de suite.

Les sections qui suivent apportent plus de précisions sur chacune des clés racine.

HKEY_CURRENT_USER

La ruche HKEY_USERS contient une clé, enregistrée sous forme de SID, pour chaque compte d’utilisateur sur l’ordinateur. Quand un utilisateur ouvre une session, le système repère le SID du compte auquel le profil correspond et charge depuis HKEY_USERS vers la branche HKEY_CURRENT_USER la portion du profil d’utilisateur.

HKEY_CURRENT_USER

La clé racine HKEY_CURRENT_USER contient des données relatives aux préférences et à la configuration logicielle de l’utilisateur actif. Les informations dans cette clé sont créées pendant le processus d’ouverture de session, ce à partir du profil de l’utilisateur ayant ouvert la session courante, profil situé sur le disque dans \Users\<username>\Ntuser.dat.

Chaque fois qu’un profil utilisateur est chargé (par exemple, lors d’une ouverture de session ou lors du démarrage d’un service exécuté sous le contexte d’un certain utilisateur), HKEY_CURRENT_USER est créé sous forme de lien vers la clé associée à l’utilisateur sous HKEY_USERS. (Pas étonnant, donc, que toutes les données trouvées dans la clé HKEY_CURRENT_USER soient par défaut une copie de la sous-clé HKEY_USERS\nom d’utilisateur, où nom d’utilisateur est le nom de l’utilisateur actif.) Le tableau suivant énumère quelques-unes des sous-clés de HKEY_CURRENT_USER.

Table 28. Sous-clés de HKEY_CURRENT_USER
Sous-clé Description

AppEvents

Associations son/événement (par exemple, quand un message d’erreur s’affiche).

Console

Paramètres de fenêtre d’invite de commandes (hauteur, largeur, couleurs, etc.)

Control Panel

Paramètres concernant l’économiseur d’écran, l’aspect du bureau, le clavier et la souris, plus quelques paramètres concernant l’accessibilité et l’internationalisation/régionalisation

Environnement

Variables d’environnement

Keyboard Layout

Paramètres concernant la disposition du clavier (par exemple, US ou FR)

Network

Mappages et paramètres des lecteurs réseau

Printers

Paramètres concernant les connexions aux imprimantes

RemoteAccess

Adresses et profils pour l’accès réseau à distance

Software

Préférences logicielles spécifiques à l’utilisateur

HKEY_LOCAL_MACHINE

HKEY_LOCAL_MACHINE (HKLM) est une sous arborescence du registre où sont définit l’ensemble des paramètres associés à la configuration de l’environnement local. La clé racine englobe toutes les sous clés de configuration de niveau système : HARDWARE (processeur, carte mère…​), SOFTWARE (options des logiciels installés), SYSTEM (dernière bonne configuration connue), SECURITY (Sam et stratégies de sécurité locales), et BCD (données d’amorçage).

C:\>reg QUERY HKEY_LOCAL_MACHINE

HKEY_LOCAL_MACHINE\BCD00000000
HKEY_LOCAL_MACHINE\HARDWARE
HKEY_LOCAL_MACHINE\SAM
HKEY_LOCAL_MACHINE\SECURITY
HKEY_LOCAL_MACHINE\SOFTWARE
HKEY_LOCAL_MACHINE\SYSTEM

HKLM\BCD contient les données de configuration définies pour l’amorçage du système, lesquelles suppléent au fichier boot.ini des anciennes versions de Windows. Plus proche de l’époque actuelle, les fichiers de données de configuration de démarrage (BCD, Boot Configuration Data) fournissent un répertoire d’informations sur les applications de démarrage et les paramètres de ces dernières. Les magasins BCD remplissent essentiellement les mêmes fonctions que leurs ainés (les fichiers ini donc), mais offrent un éventail d’options de démarrage plus large et améliorent la prise en charge de l’écriture de script.

HKLM\SAM contient les informations sur les comptes et groupes locaux, par exemple les mots de passe utilisateur, les associations de groupe et de domaine. HKLM\SECURITY contient les stratégies de sécurité.

HKLM\SECURITY

HKLM\SECURITY restitue de façon tangible bon nombre des aspects de Windows liés à la sécurité. Les informations stockées à cet égard incluent les paramètres de stratégie, les valeurs de sécurité par défaut, les secrets partagés par les serveurs, les informations de compte, telles que les informations d’identification mises en cache d’ouverture de session, et bien d’autres informations apparentées à la protection de l’ordinateur. Une copie de la base de données SAM est également enregistrée à cet endroit, même s’il est protégé.

Par défaut, les mécanismes de protection en oeuvre concernant HKLM\SECURITY se montrent particulièrement restrictifs, cela en considération de la nature critique des informations que ladite clé héberge, et sont en l’occurence configurés pour accorder l’accès uniquement au compte système local. Vous pouvez néanmoins modifier le descripteur de sécurité pour permettre l’accès en lecture aux administrateurs, ou éventuellement utiliser PsExec pour exécuter Regedit (ou n’importe quel autre utilitaire dévolu à la lecture du Registre) dans le contexte du compte système local.

HKLM\HARDWARE

HKLM\HARDWARE contient les descriptions des matériels de l’ordinateur et toutes les associations périphérique-à-pilote. Elle permet ce faisant à Windows et à ses pilotes de périphériques d’enregistrer et de partager les informations sur les équipements présents au démarrage du système, ou reconnus par la suite lors d’une procédure Plug and Play.

De nombreuses commandes d’administration permettant l’examen de données relatives au matériel, dont l’utilitaire Gestionnaire de périphériques et la boite de dialogue Système, prennent leur source à partir de valeurs appropriées dans la clé HKLM\HARDWARE.

HKLM\SOFTWARE

HKLM\SOFTWARE fait office de racine de stockage des paramètres globaux des composants et applications Windows, renfermant de la sorte autant des données de configuration de niveau système (mais qui ne sont pas requises pour l’amorçage) que des paramètres de niveau application.

Une large majorité des logiciels, tierce partie ou livré avec Windows, enregistre sous HKLM\SOFTWARE leurs paramètres, par exemple les chemins des fichiers et répertoires, les informations de licence et date d’expiration, etc. Les paramètres présents à cet endroit s’appliquent à tous les utilisateurs. D’autres paramètres spécifiques à l’utilisateur se trouveront dans les clés HKEY_USERS ou HKEY_CURRENT_USER.

HKLM\SYSTEM

HKLM\SYSTEM contient les options de configuration requises lors de l’amorçage du système, par exemple quels sont les pilotes à charger et les services à démarrer.

HKLM\SYSTEM\CurrentControlSet

Une fois terminée la procédure d’amorçage de l’ordinateur, Windows met à jour le Registre afin qu’il reflète les derniers composants et contrôles utilisés pour démarrer correctement. La clé CurrentControlSet fait pour l’occasion référence à l’ensemble de contrôles actuellement en vigueur sur la plateforme (sous entendu l’ensemble le plus récent qui ai permis de démarrer). Dans un contexte parallèle, la sous-clé HKLM\SYSTEM renferme un nombre variable de clés ControlSetXXX, qui chacune représente un ensemble de contrôles ayant existé, indépendamment du succès ou de l’échec de l’entreprise auquel il donnait lieu.

Visualisation des jeux de contrôle dans HKLM\SYSTEM
C:\>reg query HKLM\SYSTEM /f ControlSet

HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet
Fin de la recherche : 2 correspondance(s) trouvée(s).

C:\>reg query HKLM\SYSTEM\ControlSet001

HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Enum
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Hardware Profiles
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Policies
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Software

CurrentControlSet renferme plusieurs sous-clés :

  • Control Contient des informations de contrôle pour les services et les outils du système.

  • Enum Contient une entrée pour chaque périphérique physique ou logique détectable par le système. Certaines de ces informations sont accessibles depuis le gestionnaire de périphériques de Windows.

  • Harware Profiles Contient une entrée par profil matériel défini sur la machine. De la même façon que le système de numérotation de l’arborescence HKLM\SYSTEM, chaque profil possède un numéro, le premier étant 0001. HKLM\SYSTEM\Harware Profiles\Current pointe toujours vers le profil sélectionné lors de l’amorçage du système. Les informations relatives aux profils matériels peuvent être configurés depuis Panneau de configuration / onglet Système / Matériel / Profils Matériels.

  • Services Contient une sous-clé par service installé. Ces sous-clés incluent les informations de configuration nécessaires aux services Windows.

HKEY_PERFORMANCE_DATA

HKEY_PERFORMANCE_DATA est utilisée de sorte à accéder aux valeurs des compteurs de performance sous Windows, ce qui donne par ailleurs une dimension toute nouvelle au relevé de ces informations. Déjà spéciale par nature, HKEY_PERFORMANCE_DATA l’est encore plus du fait de n’être accessible que du point de vue de la programmation, c’est à dire par l’intermédiaire des fonctions de l’API Windows (Kernel32.dll) ou de l’API Performance Data Helper (Pdh.dll).

Les informations que véhicule HKEY_PERFORMANCE_DATA ne sont pas en réalité stockés dans le registre - et n’ont de toutes les façons pas vocation à l’être. Il faut en l’occurence imaginer une telle clé non comme un intermédiaire direct vers les valeurs des compteurs de performances, mais plutôt comme une rampe d’accès vers divers fournisseurs de données de performance.

HKEY_CURRENT_CONFIG

HKEY_CURRENT_CONFIG est un lien vers le profil matériel courant, stocké sous HKLM\SYSTEM\CurrentControlSet\Hardware Profiles\Current. Les profils matériels permettent de décrire quelles pièces de matériel sont activés ou désactivés quand le système est démarré sous un profil donné. Ils donnent ainsi la possibilité à l’administrateur d’adapter les paramètres des pilotes du système aux variations de l’environnement matériel de l’ordinateur. Par exemple, sur un ordinateur portable avec un plug and play compatible station d’accueil, deux profils pourraient être créés et chargés automatiquement selon les besoins : un pour quand l’ordinateur est amarré à la station, un autre pour quand il ne l’est pas. Si plusieurs profils matériels sont connus du système, ce dernier affiche au démarrage un menu spécifique, attendant le choix d’une configuration appropriée à charger.

HKEY_CLASSES_ROOT

HKEY_CLASSES_ROOT renferme principalement trois sortes d’information : des associations d’extension de fichier, la vue virtualisée du Registre, et des détails de configuration concernant les objets COM.

Il existe sous HKEY_CLASSES_ROOT une clé pour toute extension de nom de fichier connue. La plupart des clés contiennent une valeur REG_SZ qui pointe vers une autre clé de HKCR incluant les données d’association concernant la classe de fichiers que cette extension représente. Ainsi, par exemple, HKCR\.doc pointe vers des informations sur les fichiers Microsoft Word stockées dans Word.Document.8. S’ajoute à cela, les propriétés, la commande associée à un double clic et les commandes disponibles dans le menu contextuel du dit document.

Les données sous HKEY_CLASSES_ROOT proviennent de deux sources (la branche en elle-même est en quelque sorte le produit de ce couple) :

  • Les données de déclaration de classe de niveau utilisateur sous HKCU\SOFTWARE\Classes (correspondant au fichier \Users\<username>\AppData\Local\Microsoft\Windows\Usrclass.dat) 


  • Les données de déclaration de classe de niveau système sous HKLM\SOFTWARE\Classes.

La raison pour laquelle il existe une séparation entre données de déclaration de classe de niveau utilisateur et données de déclaration de classe de niveau système vient de ce qu’on veut que les profils itinérants puissent contenir ces personnalisations. En outre, une telle manière de procéder referme d’emblée une potentielle brèche de sécurité : un utilisateur non privilégié ne peut ni modifier ni supprimer des clés dans la version HKEY_CLASSES_ROOT de niveau système, et ne peut donc pas affecter le fonctionnement global des applications.

Visualisation et modification du Registre

S’il reste communément admis que la manipulation du registre ne devrait pas s’effectuer de manière directe (les paramètres des applications et du système susceptibles de modifications devraient légitimement avoir une interface utilisateur associée rendant visible les possibilités les concernant), certains paramètres du système n’ont aucun intermédiaire pour les restituer, raison pour laquelle Windows offre plusieurs outils permettant de visualiser et modifier le registre.

  • Éditeur du Registre

  • Reg.exe

  • Windows PowerShell

Editeur du Registre

L’Éditeur du Registre est composé de deux parties : un volet de navigation à gauche et un volet d’informations à droite. Le volet de navigation contient la liste hiérarchique des ruches de Registre correspondant au Registre d’un ordinateur cible (une riche est un groupe de clés, de sous-clés et de valeurs dans le Registre). Quand une ruche de Registre est sélectionnée dans le volet de navigation, toutes les entrées du Registre ajoutées pour cette ruche sont affichées dans le volet de droite.

Manipuler le registre via Windows PowerShell

Conçu spécialement pour l’administration du système, dont une des attributions courantes consiste à surveiller voire modifier le Registre, Windows PowerShell intègre en la matière diverses commandes et fonctionnalités. En utilisant le fournisseur Registry de Windows PowerShell, vous pouvez faire des recherches entre les informations du Registre, créer de nouvelles clés, supprimer des clés existantes et modifier des listes de valeurs et de contrôles d’accès (ACL) depuis Windows PowerShell.

Afin de permettre l’accès aux informations du Registre, externes à l’environnement du Shell, le fournisseur Registry maintient un espace de noms hiérarchique organisé à partir des clés et sous-clés de la base de données du Registre. Ces données, des éléments sur les lecteurs Windows PowerShell, sont rendues visibles comme s’il s’agissait d’une structure de fichiers de disque ; leur utilisation est en conséquence très semblable à celle des fichiers et dossiers. Les valeurs et données, considérées dans Powershell comme des propriétés des éléments (et non des éléments distincts), ne sont pas des composants de cette hiérarchie.

Le fournisseur Registry prend en charge pour l’interaction avec les clés de Registre tous les applets de commande Item (- Item), telles que Get-Item, Copy-Item et Rename-Item. Utilisez les applets de commande Item lors de l’utilisation de clés et sous-clés de Registre. Par exemple, Vous pouvez afficher tous les éléments situés directement dans une clé de Registre en utilisant Get-ChildItem. Le fournisseur Registry prend également en charge les applets de commande ItemProperty (- ItemProperty). Utilisez les applets de commande ItemProperty lors de l’utilisation de valeurs et données de Registre. Par exemple, L’applet de commande Remove-ItemProperty supprime une propriété et sa valeur d’un élément. Vous pouvez l’utiliser pour supprimer des valeurs de Registre et les données qu’elles contiennent.

Fichiers d’inscription

Établis comme un moyen commode de gérer le registre autrement que par l’intermédiaire d’utilitaires dédiés, les fichiers d’inscription (extension .reg) sont des fichiers à base de texte (donc facilement lisibles par l’homme) qui permettent l’importation et l’exportation de constituants (clés, sous-clés et valeurs) depuis et vers la base de registre. Lorsque vous exécutez un tel fichier, son contenu est fusionné dans le Registre local. Les administrateurs peuvent du même coup utiliser ces fichiers pour distribuer à distance des modifications du Registre sur plusieurs ordinateurs Windows.

Vous pouvez envoyer un fichier d’inscription à des utilisateurs dans un message électronique, placer un fichier .reg sur un partage réseau et demander aux utilisateurs du partage réseau de l’exécuter, ou encore ajouter une commande aux scripts d’ouverture de session des utilisateurs pour importer automatiquement le fichier .reg lorsqu’ils se connectent.

Lorsque les utilisateurs exécutent le fichier .reg, ils reçoivent les messages suivants : "Éditeur du Registre / Voulez-vous vraiment ajouter les informations contenues dans chemin_fichier_.reg au Registre ?". Si l’utilisateur clique sur Oui, il reçoit le message suivant : "Éditeur du Registre / Les informations de chemin_fichier_.reg ont été inscrites dans le Registre.". Regedit.exe prend en charge un commutateur de ligne de commande /s pour ne pas afficher ces messages. Par exemple, pour exécuter silencieusement le fichier .reg (avec le commutateur /s) à partir d’un fichier de commandes de script de connexion, utilisez la syntaxe chemin_fichier_.reg.

Utilitaire Reg (Reg.exe)

L’utilitaire Reg (Reg.exe) permet de visualiser, de modifier ou d’ajouter des entrées dans le Registre à partir de l’invite de commandes. Aussi performant que n’importe lequel de ses homologues en mode graphique, Reg est essentiellement destinée aux administrateurs système, lesquels l’utilisent surtout dans des fichiers de commandes appliquant de manière successive et répétitive des modifications au Registre. L’emploi de la commande Reg reste néanmoins un choix stratégique dans la plupart des scénarios et pour de nombreux utilisateurs.

Comme tant autres utilitaires sollicités depuis l’invite de commandes, l’utilitaire Reg possède sa propre série de sous-commandes. Les options disponibles sont nombreuses et se passent en tant que paramètres à l’exécutable. Voici la syntaxe générale de la commande Reg :

reg action [options]

Reg correspond au nom de l’exécutable Reg, action à la commande de registre à effectuer et options à la liste des paramètres spécifiques à la commande. Les principales commandes reconnues par Reg sont listées dans le tableau suivant.

Table 29. Commandes Reg

Commande

Action

Add

Ajoute une nouvelle sous-clé ou entrée au Registre

Compare

Compare les valeurs de deux sous-clés ou de deux entrées

Copy

Copie les informations du Registre à un nouvel emplacement d’un Registre local ou réseau

Delete

Supprime des informations du Registre

Export

Crée une copie des sous-clés ou valeurs spécifiées dans un fichier. Ce fichier permet de transférer les données du Registre vers d’autres ordinateurs à l’aide de la commande Import.

Import

Importe un fichier registre et crée et modifie les clés du fichier dans le Registre local.

Load

Permet de déplacer les données du registre à un nouvel emplacement.

Query

Affiche toutes les informations du Registre sous la clé spécifiée.

Restore

Restaure les informations du Registre à partir d’un fichier crée avec la commande Save.

Save

Enregistre les informations du Registre dans un fichier. Cela est utile pour effectuer une sauvegarde avant de modifier une clé.

Unload

Supprime les données du Registre ajoutées avec la commande Load.

Plusieurs remarques additionnelles concernant la syntaxe de Reg.exe :

  • Reg.exe exige que les noms des clés des racines figurent sous forme abrégée. Saisissez HKLM, par exemple, et non HKEY_LOCAL_MACHINE

  • Dans l’éventualité où un nom de clé ou de valeur comporte des espaces, il est impératif de le faire apparaitre entre guillemets.

  • Si vous introduisez une commande Reg.exe dans un programme batch et qu’elle renferme une variable d’environnement, il est impératif de placer le nom de la variable entre deux paires de symboles de pourcentage (et non un seul). Autrement, l’interprète de commandes développe le nom de la variable avant de la passer à Reg.exe.

Registre et sécurité

Compte tenu du rôle clé joué par la base de registre au sein de la configuration du système d’exploitation, il est facile de concevoir l’importance de conserver, rétablir, et garantir sa sécurité.

Regedit permet d’ajuster la sécurité des clés du Registre via la commande Autorisations du menu Edition. Les autorisations des clés sont identiques à celles des fichiers.

Table 30. Autorisations du Registre

Autorisation

Implication de cette autorisation

Contrôle total

L’utilisateur peut ouvrir, modifier et prendre possession d’une clé.

Requête sur une valeur

L’utilisateur peut interroger la valeur que renferme une clé.

Définir la valeur

L’utilisateur peut créer de nouvelles valeurs sous une clé ou remplacer une valeur existante.

Créer une sous-clé

L’utilisateur peur créer une nouvelle sous-clé sous une clé

Énumérer les sous-clés

L’utilisateur a accès à la liste de toutes les sous-clés d’une clé particulière (dans la perspective NTFS, cette possibilité à traverser un répertoire).

Avertir

L’utilisateur peut enregistrer une fonction qui se déclenche lorsque la valeur sélectionnée a fait l’objet de modifications.

Créer une liaison

L’utilisateur peut créer une liaison vers une clé.

Supprimer

L’utilisateur peut créer une clé ou une valeur.

Accès en écriture à la liste de contrôle d’accès

L’utilisateur dispose d’un accès en écriture aux contrôles d’accès de la clé sélectionnée.

Accès du propriétaire

L’utilisateur peut prendre possession de la clé sélectionnée.

Contrôle en lecture

L’utilisateur peut lire la liste de contrôle d’accès discrétionnaire (DACL) de la clé.

Par défaut, le profil de sécurité attribué à certains composants sensibles de la base de registre empêche l’accès par un compte autre que le compte système local. Citons par exemple les clés HKLM\SECURITY et HKLM\SAM, qui contiennent pas moins que les politiques de sécurité du système, les affectations de droits d’usagers, et les mots de passe. Un moyen rudimentaire d’accéder à ces données consiste simplement à réinitialiser leur sécurité, ce qui en plus de n’être pas conforme aux bonnes pratiques en matière d’administration, pourrait avoir des résultats malencontreux sur la sécurité d’ensemble du système. Une autre façon consiste à exécuter l’utilitaire Regedit.exe, ou tout autre outil offrant la possibilité d’éditer le registre, sous le compte système local. L’utilitaire PsExec prend en charge une option permettant de procéder ainsi.

Callbacks de registre

Windows donne aux composants de l’exécutif, pilotes et autres codes système l’occasion de surveiller les activités se déroulant dans le registre, ce par l’intermédiaire de routines de rappel (callbacks) spéciales. Un thread mode noyau emploie la fonction CmRegisterCallbackEx en vue de déclarer auprès du gestionnaire de configuration un point d’entrée RegistryCallback, que Windows exécute chaque fois qu’une opération liée au registre a lieu (comprendre chaque fois qu’un service système apparenté au registre est sollicité). Ce genre de fonctionnalités s’illustre, par exemple, dans divers produits de sécurité, qui examinent les données du registre afin de détecter d’éventuelles malveillances.

Registre et droits d’accès

Table 31. Droits d’accès concernant clés et valeurs de registre
Constante Valeur Description

KEY_QUERY_VALUE

0x0001

Requis pour interroger les valeurs présentes dans une clé. Voir service NtEnumerateValueKey, NtEnumerateKey (KeyInformationClass = KeyNameInformation), NtQueryValueKey.

KEY_ENUMERATE_SUB_KEYS

0x0008

Requis pour énumérer des sous-clés.

KEY_NOTIFY

0x0010

Requis pour effectuer un audit (recevoir des notifications de modification) d’un clé.

KEY_SET_VALUE

0x0002

Requis pour créer, supprimer ou modifier une valeur. Voir service NtDeleteValueKey.

KEY_CREATE_SUB_KEY

0x0004

Requis pour créer une sous-clé.

KEY_CREATE_LINK

0x0020

Requis pour créer un lien symbolique.

Table 32. Mappage générique des droits d’accès au registre
Droit générique Signification

KEY_ALL_ACCESS

STANDARD_RIGHTS_ALL

KEY_QUERY_VALUE

KEY_SET_VALUE

KEY_CREATE_SUB_KEY

KEY_ENUMERATE_SUB_KEYS

KEY_NOTIFY

KEY_CREATE_LINK

KEY_EXECUTE

KEY_READ

KEY_READ

STANDARD_RIGHTS_READ

KEY_QUERY_VALUE

KEY_ENUMERATE_SUB_KEYS

KEY_NOTIFY.

KEY_WRITE

STANDARD_RIGHTS_WRITE

KEY_SET_VALUE

KEY_CREATE_SUB_KEY

NtQueryKey

Table 33. KEY_INFORMATION_CLASS
ID Classe Type de données associé

0x0000

KeyBasicInformation

KEY_BASIC_INFORMATION

0x0001

KeyNodeInformation

KEY_NODE_INFORMATION

0x0002

KeyFullInformation

KEY_FULL_INFORMATION

0x0003

KeyNameInformation

KEY_NAME_INFORMATION

typedef struct _KEY_BASIC_INFORMATION {
  LARGE_INTEGER LastWriteTime;
  ULONG         TitleIndex;
  ULONG         NameLength;
  WCHAR         Name[1];
} KEY_BASIC_INFORMATION, *PKEY_BASIC_INFORMATION;
typedef struct _KEY_CACHED_INFORMATION {
  LARGE_INTEGER LastWriteTime;
  ULONG         TitleIndex;
  ULONG         SubKeys;
  ULONG         MaxNameLen;
  ULONG         Values;
  ULONG         MaxValueNameLen;
  ULONG         MaxValueDataLen;
  ULONG         NameLength;
} KEY_CACHED_INFORMATION, *PKEY_CACHED_INFORMATION;
typedef struct _KEY_FULL_INFORMATION {
    LARGE_INTEGER LastWriteTime;
    ULONG   TitleIndex;
    ULONG   ClassOffset;
    ULONG   ClassLength;
    ULONG   SubKeys;
    ULONG   MaxNameLen;
    ULONG   MaxClassLen;
    ULONG   Values;
    ULONG   MaxValueNameLen;
    ULONG   MaxValueDataLen;
    WCHAR   Class[1];
} KEY_FULL_INFORMATION, *PKEY_FULL_INFORMATION;
typedef struct _KEY_NAME_INFORMATION {
  ULONG NameLength;
  WCHAR Name[1];
} KEY_NAME_INFORMATION, *PKEY_NAME_INFORMATION;
typedef struct _KEY_NODE_INFORMATION {
  LARGE_INTEGER LastWriteTime;
  ULONG         TitleIndex;
  ULONG         ClassOffset;
  ULONG         ClassLength;
  ULONG         NameLength;
  WCHAR         Name[1];
} KEY_NODE_INFORMATION, *PKEY_NODE_INFORMATION;
typedef struct _KEY_VALUE_BASIC_INFORMATION {
  ULONG TitleIndex;
  ULONG Type;
  ULONG NameLength;
  WCHAR Name[1];
} KEY_VALUE_BASIC_INFORMATION, *PKEY_VALUE_BASIC_INFORMATION;
typedef struct _KEY_VIRTUALIZATION_INFORMATION {
  ULONG VirtualizationCandidate : 1;
  ULONG VirtualizationEnabled : 1;
  ULONG VirtualTarget : 1;
  ULONG VirtualStore : 1;
  ULONG VirtualSource : 1;
  ULONG Reserved : 27;
} KEY_VIRTUALIZATION_INFORMATION, *PKEY_VIRTUALIZATION_INFORMATION;

Le champ NameLength précise la taille, en octets, de la chaine de caractères véhiculée par le tableau Name, représentant le nom de clé dans le registre. Le champ Name constitue un tableau de caractères larges (dont la taille est indiquée par l’attribut NameLength) qui renferme le nom de la clé.

Ruches

Les données s’apparentant au Registre Windows sont le disque enregistrées sous la forme de plusieurs fichiers appelées ruches. Chaque ruche fait miroir à une arborescence de registre, avec une clé servant de racine (autrement dit de point de départ) à cette arborescence.

Lorsque le Gestionnaire de configuration manipule (charge ou décharge) des ruches, il le fait à l’aide des informations contenues sous la clé HKLM\SYSTEM\CurrentControlSet\Control\hivelist, dont les valeurs internes définissent les noms de chemins de toutes les ruches.

Quelques-uns des sous-ensembles définis dans le Registre sont volatiles, et ne sont en conséquence pas associés à des fichiers. Le système crée et gère ces ruches en mémoire uniquement ; elles sont donc temporaires et ne perdurent pas au-delà de l’extinction de l’ordinateur. Windows recrée les ruches volatiles à chaque démarrage. Exemple de ruche volatile : HKLM\HARDWARE, qui stocke des informations sur les périphériques matériels et sur les ressources qui leur sont assignées. La détection des périphériques et l’assignation des ressources ayant lieu à chaque réinitialisation du système, il est alors tout à fait logique de ne pas pérenniser les données issues de ces procédures et, partant, de ne pas les enregistrer sur disque.

Table 34. Correspondance entre fichiers disque et chemins de registre
Chemin registre Chemin fichier

HKEY_LOCAL_MACHINE\BCDOOOOOOOO

\Boot\BCD

HKEY_LOCAL_MACHINE\COMPONENTS

%SystemRoot%\System32\Config\Components

HKEY_LOCAL_MACHINE\HARDWARE

Ruche volatile

HKEY_LOCAL_MACHINE\SAM

%SystemRoot%\System32\Config\Sam

HKEY_LOCAL_MACHINE\SECURITY

%SystemRoot%\System32\Config\Security

HKEY_LOCAL_MACHINE\SOFTWARE

%SystemRoot%\System32\Config\Software

HKEY_LOCAL_MACHINE\SYSTEM

%SystemRoot%\System32\Config\System

HKEY_USERS\.DEFAULT

%SystemRoot%\System32\Config\Default

Tout comme le système de gestion de fichiers, qui s’appuie pour afficher un espace de noms virtuels sur un certain nombres d’artifices, le gestionnaire de configuration procède sensiblement de la même manière en utilisant des liaisons symboliques (type de données REG_LINK) pour relier les ruches, donnant ainsi au Registre la forme structurelle qu’on lui connaît. Les branches HKEY_CLASSES_ROOT et HKEY_CURRENT_USER, par exemple, correspondent en réalité à des emplacements de HKLM et HKU.

Services

Presque tous les systèmes d’exploitation disposent d’un mécanisme pensé pour des tâches non attachées explicitement à l’utilisateur interactif. Sous Windows, ce genre de processus porte le nom de service ou service Windows. Analogues des "démons" UNIX, qui fonctionnent en arrière-plan plutôt que sous le contrôle direct d’un utilisateur, les services Windows sont des programmes qui se chargent automatiquement dans le cadre du processus de démarrage d’une application ou du processus de démarrage de système pour prendre en charge les différentes tâches nécessaires au système d’exploitation.

Les fonctionnalités implémentées au niveau service, souvent orientés réseau et dont la durée d’exécution est généralement longue, rendent les services parfaitement adaptés à une utilisation sur un serveur. Ils sont aussi particulièrement utiles lorsqu’une fonctionnalité du système doit n’être pas tributaire d’une identité numérique directe (utilisateurs comme administrateurs). Les exemples de composants Windows existants sous forme de services incluent le spouleur d’impression, le journal des événements et le planificateur de tâches.

Les services Windows sont constitués de trois composants : une application service, un programme de contrôle de service (SCP), et le gestionnaire de contrôle de service (SCM). Dans cette section, nous commencerons par d’écrire les applications et le fonctionnement du SCM. Nous expliquerons ensuite comment se fait le démarrage des services automatiques lors de l’amorçage du système. Nous verrons aussi les mesures que prend le SMC lorsqu’un service échoue lors de son démarrage et la façon dont le SMC arrête les services.

Le tableau qui suit énumère les fonctions Windows utilisées dans le contexte des services.

Table 35. Fonctions de gestion de services
Fonction Description

ChangeServiceConfig/2

Modifie la configuration d’un service

ControlService/Ex

Envoie un code de contrôle à un service

CreateService

Crée un service (l’ajoute au Registre)

DeleteService

Supprime un service (du Registre)

EnumDependentServices

Énumère les dépendances de service

EnumServicesStatusEx

Énumère les services sur la base d’un niveau d’information

ControlService/Ex

Envoie une requête de contrôle à un service

GetServiceDisplayName

Obtient le nom d’affichage d’un service

GetServiceKeyName

Obtient le nom de la clé de service d’un service

OpenSCManager

Établit une connexion au gestionnaire de contrôle de service sur l’ordinateur spécifié

QueryServiceConfig

Retourne les paramètres de configuration d’un service

SetServiceObjectSecurity

Modifie la sécurité d’un service

StartService

Démarre un service

Applications service

Une application service est un ensemble logiciel dont au moins un composant fonctionne en tant que service Windows.

Quand vous installez une application qui inclut un service, le programme d’installation de cette application a pour obligation préalable de déclarer ledit service auprès du système, chose qu’il accomplit en sollicitant CreateService, laquelle fonction a dans ce contexte pour rôle de partager au SCM l’ensemble des informations nécessaires (pas moins de 13 paramètres) à une future prise en charge. Comme tant d’autres des fonctions de gestion de services, CreateService est implémentée dans Advapi32.dll, DLL qui recueille en réalité toutes les API coté client du SCM.

Tout utilisateur qui interagit avec un service le fait par non pas directement mais par le biais d’un programme de contrôle de service (SCP). Windows fournit des SCP intégrés dotés de fonctionnalités génériques de démarrage, d’arrêt, de suspension et de reprise. Certaines applications service incluent toutefois leurs propres SCP, cela essentiellement en vue de pouvoir instaurer des dispositions spécifiques (des paramètres de configuration particuliers) au service concerné.

Lors de la mise en avant d’un service par un programme d’installation, il y a envoi d’un message au SCM de la machine appelée à accueillir le service (l’ordinateur local dans une large majorité des cas). Le SCM crée à cette occasion une clé de registre pour le service sous HKLM\SYSTEM\CurrentControlSet\Services.

Le SCM enregistre chacune des caractéristiques relatives un service ou à un pilote par l’intermédiaire de la clé HKLM\System\CurrentControlSet\Services. (Une caractéristique particulière ne s’applique pas forcément à tous les types de service, ni non plus à tous les types de pilote.) Les paramètres admissibles en la matière sont les suivants :

  • Type de démarrage (Start) Indique si le démarrage de ce service est effectué automatiquement, défini de manière manuelle ou s’il est désactivé. Les services automatiques sont démarrés à l’amorçage. Les services manuels sont démarrés à la demande par les utilisateurs ou par d’autres services. Les services désactivés ne peuvent être démarrés tant qu’ils sont en l’état.

  • Niveau de contrôle d’erreur (ErrorControl) Oriente la manière dont le système sanctionne avec plus ou moins de sévérité les ratés et dysfonctionnements émanant d’un service ou d’un pilote : ignorer le problème, afficher un avertissement, faire s’effondrer et réamorçer le système avec la dernière bonne configuration connue, etc. Pour plus d’informations, consultez la section Erreurs des services.

  • Type de composant (Type) Type auquel se rapporte un composant. Comme les services et les pilotes de périphériques Windows stockent tous deux leurs paramètres de configuration sous la même clé de registre, il est de ce fait nécessaire de faire une distinction entre les deux. Voir tableau plus loin.

  • Nom de groupe (Group) Désigne le groupe auquel appartient le pilote ou le service. Cela permet à des pilotes ou services apparentés de démarrer conjointement (par exemple, des pilotes de système de fichiers). L’entrée de registre List de la sous-clé HKLM\SYSTEM\CurrentControlSet\Control\ServiceGroupOrder spécifie l’ordre de démarrage du groupe.

  • Numéro de tag (Tag) Désigne l’ordre de démarrage d’un pilote au sein d’un groupe de pilotes. Ce paramètre ne concerne pas les services.

  • Dépendance de service (DependOnService) Enumère les services spécifiques qui doivent être chargés avant le chargement de ce service. Ce paramètre ne s’applique pas aux pilotes autres que ceux ayant le type de démarrage SERVICE_AUTO_START.

  • Dépendance de groupes (DependOnGroup) Au moins un élément de ce groupe doit démarrer avant le chargement de ce service.

  • Chemin de fichier exécutable (ImagePath) Chemin du fichier exécutable sous-jacent au service ou pilote. Dans l’éventualité où ImagePath n’est pas spécifié, le gestionnaire d’E/S recherche les pilotes dans \Windows\System32\Drivers et le SCM dans les différents emplacements du système de fichier auxquels conduit la variable PATH.

  • Compte de service (ObjectName) Nom du compte sous lequel le service est exécuté. Si ObjectName n’est pas spécifié, le système emploie le compte système local (LocalSystem). Ce paramètre ne s’applique pas aux pilotes.

  • Nom de service (DisplayName) Nom par lequel se fait connaitre le service auprès des différents logiciels, par exemple l’application Services. Dans l’éventualité où aucun nom n’a été donné, c’est le nom de la clé de registre renfermant les informations du service qui est utilisé.

  • Description de service (Description) Contient une brève description textuelle du service et de son but (32767 octets maximum)

  • Actions en cas d’échec (FailureActions) Description des actions que doit exercer le SCM dans l’éventualité où le processus service se termine de manière inattendue ; plusieurs cas de figure ici : le redémarrage du processus service, l’exécution d’un programme spécifié et le réamorçage du système. Ce paramètre ne concerne pas les pilotes.

  • Commande de processus (FailureCommand) Le SCM ne s’appuie sur cette valeur que si FailureActions a enjoint le SCM à exécuter un programme spécifique en cas d’échec du service. Ce paramètre ne concerne pas les pilotes.

  • Descripteur de sécurité (Security) Contient la descripteur de sécurité qui définit qui a accès à l’objet service créé en interne par le SCM.

Type de services

Chaque service a parmi ses propriétés définitoires un certain nombre d’attributs qui le caractérisent auprès du SCM, par exemple si le service est exécuté dans un seul processus ou au contraire partage un processus avec d’autres composants, s’il peut interagir avec le bureau actif, etc. En interne, toutes ces informations sont regroupées sous la valeur Type de la clé associée au service. Le tableau suivant décrit les valeurs susceptibles d’apparaitre à ce niveau.

Table 36. Valeurs de registre Type
Constante Valeur Description

SERVICE_ADAPTER

0x00000004

Spécifie un adaptateur. Cet attribut est désormais obsolète.

SERVICE_FILE_SYSTEM_DRIVER

0x00000002

Spécifie un pilote de système de fichiers mode noyau.

SERVICE_KERNEL_DRIVER

0x00000001

Spécifie un pilote de périphérique.

SERVICE_RECOGNIZER_DRIVER

0x00000008

Spécifie un pilote reconnaisseur de système de fichiers.

SERVICE_WIN32_OWN_PROCESS

0x00000010

Spécifie un service qui s’exécute dans un processus qui héberge un seul service

SERVICE_WIN32_SHARE_PROCESS

0x00000020

Spécifie un service qui s’exécute dans un processus qui héberge plusieurs services.

SERVICE_INTERACTIVE_PROCESS

0x00000100

Spécifie un service autorisé à afficher des fenêtres sur la console et à recevoir des saisies de la part de l’utilisateur.

Chaque service peut éventuellement avoir une description qui le caractérise auprès des autres composants du système, lui permettant de la sorte de mettre en avant son but ou les diverses tâches qu’il accomplit. Pour associer une description à un service, sollicitez ChangeServiceConfig2 en lui spécifiant la valeur SERVICE_CONFIG_DESCRIPTION. Pour voir la description qui accompagne tel ou tel service, employez la commande sc qdescription, suivie d’un nom de service.

États d’un service

Comme d’autres composants opérationnels dans Windows, dont par exemple processus et threads, les services voient leur dynamique marquée par une succession de phases, à quoi ramène en interne différents états.

Table 37. État des services
Constante Valeur Description

SERVICE_STOPPED

0x00000001

Le service est arrêté.

SERVICE_START_PENDING

0x00000002

Le service est en cours de démarrage.

SERVICE_STOP_PENDING

0x00000003

Le service est en cours d’arrêt.

SERVICE_RUNNING

0x00000004

Le service est démarré.

SERVICE_CONTINUE_PENDING

0x00000005

Le service est en cours de reprise après une pause.

SERVICE_PAUSE_PENDING

0x00000006

La mise en pause du service est en cours.

SERVICE_PAUSED

0x00000007

Le service est en pause.

Chaque service a individuellement la responsabilité de signaler les modifications de son état interne au SCM. Un service signale son état actuel par le biais de la fonction SetServiceStatus, spécifiant alors auprès de ladite fonction une structure SERVICE_STATUS dont l’attribut dwCurrentState est établi conformément aux circonstances. (Les programmes de contrôle de service et le système n’ont pour prendre connaissance de l’état et de l’évolution d’un service pas d’autre alternative que le SCM, il est donc important que ce dernier dispose des informations les plus pertinentes.)

Tous les services entament leur cycle de vie dans l’état SERVICE_STOPPED. Lorsque le SCM démarre le service, il modifie l’état de ce dernier en le faisant passer à SERVICE_START_PENDING et appelle la fonction principale du service (ServiceMain). Ce type de fonctions n’à normalement qu’un seul but : terminer l’initialisation du service et préparer le terrain pour répondre aux demandes de contrôle ultérieures. Une fois que le service est prêt, il le signale au moyen de la fonction SetServiceStatus et de la constante SERVICE_RUNNING. La transition de SERVICE_START_PENDING à SERVICE_RUNNING indique au SCM (entres autres outils) que le service a démarré avec succès.

Les changements d’état que connaît un service lors de son exécution résultent le plus souvent de demandes de contrôle spécifiques, dont SERVICE_CONTROL_STOP, SERVICE_CONTROL_PAUSE et SERVICE_CONTROL_CONTINUE.

Les informations qu’émet un service concernant son état déterminent la manière dont le SCM interagit avec lui. Par exemple, quand un service retourne SERVICE_STOP_PENDING, lequel code ramène à une procédure d’arrêt en cours, le SCM ne transmet alors plus au service les requêtes ultérieures. Dans l’ordre légitime des choses, l’état suivant SERVICE_STOP_PENDING devrait être SERVICE_STOPPED, signe que l’arrêt s’est déroulé sans incident et a effectivement eu lieu.

Démarrage des services

La façon dont gestionnaire de contrôle des services (Scm) orchestre le démarrage est en interne piloté par l’entrée de registre Start.

Table 38. Valeurs de registre Start

Valeur

Type de démarrage

Description

SERVICE_BOOT_START(0)

Démarrage

Spécifie un pilote chargé (mais pas démarré) par le programme d’amorçage (Winload). En l’absence d’erreur, le pilote est démarré pendant l’initialisation du noyau, avant le chargement de tout pilote non-démarrage.

SERVICE_SYSTEM_START (1)

Système

Spécifie un chargé et initialisé pendant l’initialisation du noyau.

SERVICE_AUTO_START (2)

Chargement automatique

Spécifie un pilote ou un service initialisé lors du démarrage système par le gestionnaire de session (Smss.exe) ou le contrôleur de services (Services.exe).

SERVICE_DEMAND_START (3)

Chargement à la demande

Spécifie un pilote ou un service que le SCM démarre uniquement à la demande.

SERVICE_DISABLED (4)

Désactivé

Spécifie un pilote ou un service désactivé.

5

Démarrage retardé

Spécifie un service démarrant peu après le démarrage de la session utilisateur.

Une activité qui engage l’une des plus importantes, sinon la plus importante, charge de responsabilité au sein de la fonction initiale du SCM (SvcCtrlMain) est d’orchestrer le lancement des services et des pilotes dont les paramètres de configuration (valeur Start sous la clé idoine) stipulent que le démarrage est automatique. En interne, SvcCtrlMain sollicite pour ce genre d’opération la fonction SCM ScAutoStartServices.

L’algorithme de ScAutoStartServices procède par phases, chaque phase correspondant à un groupe et les phases se déroulant selon une chronologie définie par la valeur de registre HKLM\SYSTEM\CurrentControlSet\Control\ServiceGroupOrder\List. La valeur List inclut les noms des groupes dans l’ordre où le SCM doit les démarrer.

Certains pilotes et services exigent que des conditions, connues sous le nom de dépendances, soient satisfaites, comme spécifiées par la présence des entrées DependOnGroup, pour ce qui concerne les dépendances relatives à des groupes, et DependOnService, pour ce qui est des dépendances de service, dans la clé associée au service. Dans l’éventualité où une dépendance de niveau groupe est constatée, il faut que le groupe dont dépend le service ait déjà été initialisé et qu’au moins un service parmi ce groupe ait eu l’occasion de démarrer. Si le service dépend d’un groupe qui démarre après le groupe auquel appartient le service dans l’ordre de démarrage des groupes, le SCM enregistre une erreur de type dépendance circulaire pour le service.

Le SCM prend en charge le démarrage d’un service Windows ou d’un pilote par le biais de la fonction ScStartService, laquelle se comporte différemment selon qu’elle a affaire à l’une ou à l’autre sorte. Quand ScStartService démarre un service, elle commence par déterminer le nom du fichier qui exécute le processus du service en examinant la valeur ImagePath de la clé de registre associée. Elle consulte ensuite la valeur Type, toujours sous le même emplacement, et, si cela correspond à un service destiné à intégrer un processus qui en héberge plusieurs (SERVICE_WIN32_SHARE_PROCESS), vérifie alors que le processus dans lequel fonctionne le service, s’il a déjà démarré, est exécuté sous le même compte que celui spécifié pour le service à démarrer, comme indiquée par la valeur de registre ObjectName. Un service sans ObjectName est exécuté sous le compte système local.

Si le composant dont il entreprend le démarrage a une entrée de registre valant SERVICE_KERNEL_DRIVER ou SERVICE_FILE_SYSTEM_DRIVER, c’est que le SCM est en réalité confronté non à un service mais à un pilote ; auquel cas ScStartService appelle ScLoadDriver pour charger le pilote. ScLoadDriver active le privilège de sécurité SeLoadDriverPrivilege pour le processus SCM, puis passe le relais au service noyau NtLoadDriver.

Acceptation de l’amorçage

Outre lui confier la prise en charge des services, Windows place le SCM au centre de la gestion des configurations de démarrage, et tout particulièrement de la dernière bonne connue (last known good config). Particulièrement utile dans dans les cas où des modifications apportées au système l’empêchent de démarrer correctement, la dernière bonne configuration connue est en interne constituée par les paramètres de registre correspondant au dernier démarrage réussi de l’ordinateur. Par défaut, un tel succès se compose de deux critères : un démarrage réussi des services automatiques, et une ouverture de session utilisateur réussie. Il y a échec de démarrage si le système se bloque parce qu’un pilote de périphérique fait s’effondrer le système lors de l’amorçage ou si un service automatique ayant une valeur ErrorControl définie à SERVICE_ ERROR_SEVERE ou SERVICE_ERROR_CRITICAL fait état d’une erreur lors de son démarrage.

Les configurations de démarrage enregistrées sous HKLM\SYSTEM ont des noms de la forme ControlSet_nnn_, où nnn est un numéro du genre 001 ou 002. La clé HKLM\SYSTEM\Select contient des valeurs qui identifient le rôle de chaque configuration (voir figure ci-après). La Valeur Current sous Select se rapporte au jeu de contrôle actuellement utilisé. Par exemple, si CurrentControlSet pointe vers ControlSet001, la valeur vaut 1. La Valeur LastKnownGood sous Select contient le numéro de la dernière bonne configuration connue, laquelle fait en l’occurence tremplin vers le dernier jeu de contrôle ayant donné lieu à un démarrage réussi. La valeur Default renvoie au jeu de contrôle à utiliser par défaut si aucun autre n’est désigné. Autre valeur que la clé Select est susceptible de renfermer : Failed, qui pointe vers la dernière configuration pour laquelle le démarrage a échoué.

Clé de sélection de configuration de démarrage
HKEY_LOCAL_MACHINE\System\Select
    Current    REG_DWORD    0x1
    Default    REG_DWORD    0x1
    Failed    REG_DWORD    0x0
    LastKnownGood    REG_DWORD    0x1

Comme nous l’avons déjà dit, que le SCM ai été en mesure de traiter correctement l’ensemble des services automatiques ne représente qu’un des facteurs requis pour tirer un bilan positif de la phase d’amorçage du système, dans la mesure où reste dans ce contexte à s’assurer du bon fonctionnement des mécanismes participant à l’ouverture de session utilisateur. Aussi, quand un utilisateur ouvre une session, Winlogon appelle la fonction NotifyBootConfigStatus, laquelle informe le SCM du succès de l’opération. Après démarrage réussi des services automatiques ou réception du message émanant de NotifyBootConfigStatus (de ces deux événements, c’est celui arrivé en dernier qui compte), le SCM appelle la fonction NtInitializeRegistry pour enregistrer la configuration courante en tant que dernière bonne connue.

SCM (Service Control Manager)

Le gestionnaire de contrôle de service (SCM, Service Control Manager) est un processus système spécial responsable du démarrage, de l’arrêt et de l’interaction la gestion des processus de service. Lancé dès l’amorçage du système et exécutant l’image \Windows\System32\Services.exe, le SCM est implémenté sous forme d’un serveur RPC, de sorte que à pouvoir manipuler des services sur des machines distantes.

Le SCM entretient une base de données d’informations concernant les services installés dans le système.

Objectifs de conception des services Windows

Voici quelques-uns des objectifs et règles de fonctionnement auxquels les services Windows doivent se plier.

  • Démarrage immédiat Les services lancés lorsque l’ordinateur est mis sous tension ou redémarré (services à démarrage automatique, qui sont pour la plupart essentiels à la prise en charge de l’environnement) ne devraient pas interférer de manière significative sur les performances du système.

  • Fermeture immédiate Arrêter des services en cours d’exécution devrait n’avoir qu’une incidence mineure sur la capacité du système d’exploitation à s’éteindre rapidement.

  • Consommation des ressources Chaque service devrait être optimisé dans le but de consommer le moins de mémoire et de ressources processeur. Dans la mesure du possible, chaque service devrait éviter d’être un fardeau supplémentaire sur les performances, la fiabilité, la stabilité et la robustesse du système.

  • Chemin de performance Chaque service devrait viser un chemin de performance idéal, ce qui signifie être respectueux des conditions dans lesquelles le système d’exploitation et les autres services s’exécutent. Empêcher le système d’entrer dans un des états d’économie d’énergie, monopoliser une ressource, ou au contraire en abandonner une sans l’avoir libéré (un mutex) sont des exemples de situations préjudiciables pour tous les acteurs du système.

  • Exécution avec le compte à moindres privilèges Chaque service ne devrait posséder que les privilèges et ne réclamer que les ressources nécessaires à son exécution. Sur le plan de la sécurité, les services ayant besoin d’être exécutés avec les données d’identification d’un compte utilisateur devraient choisir celui avec le moins de capacités, autrement dit le moins susceptible d’augmenter la surface d’attaque de l’ensemble du système.

Les règles mentionnés ci-dessus guide la démarche d’une bonne gestion des services. Les sections suivantes décrivent pour la plupart comment les services peuvent les respecter.

Services Windows et tâches planifiées

Pour l’essentiel, la différence entre services Windows et tâches planifiées tient au fait de quand les uns et les autres peuvent agir, et pour quelle longévité.

Les services Windows mettent en œuvre une fonctionnalité particulière du système d’exploitation, généralement pour le compte d’autres processus, et à un assez bas niveau. De telles applications n’interagissent pas avec l’utilisateur et ne nécessitent pas qu’un utilisateur ait ouvert une session pour s’exécuter.

Les tâches planifiées n’effectuent généralement pas non plus d’interaction utilisateur, mais nécessitent qu’un utilisateur ait ouvert une session. Les tâches planifiées sont déclenchées en fonction d’un calendrier ou par des conditions système, et sont gérées par le Planificateur de tâches. Les services ont un cycle de vie orchestré par le Gestionnaire de contrôle des services.

Comptes de services

Le contexte de sécurité d’un service, dans la mesure où c’est par son intermédiaire que sont définies les ressources auxquelles le processus peut accéder, tient lieu de sujet important tant pour les concepteurs de logiciels que pour les administrateurs. Dans la configuration par défaut, chaque service exécuté sous Windows peut l’être en fonction de l’une ou l’autre de trois identités : Système local, Service réseau et Service local. Les permissions de chacun de ces comptes sont ajustées précisément afin de leur octroyer uniquement les permissions nécessaires sur le système, ceci dans le but de limiter l’exposition du système d’exploitation en cas de faille de sécurité ou d’utilisation non autorisée.

Table 39. Privilège des comptes de service
Privilège Système local Service réseau Service local

SeAssignPrimaryTokenPrivilege

SeAuditPrivilege

SeBackupPrivilege

SeChangeNotifyPrivilege

SeCreateGlobalPrivilege

SeCreatePagefilePrivilege

SeCreatePermanentPrivilege

SeCreateTokenPrivilege

SeDebugPrivilege

SeEnableDelegationPrivilege

SeImpersonatePrivilege

SeIncreaseBasePriorityPrivilege

SeIncreaseQuotaPrivilege

SeLoadDriverPrivilege

SeLockMemoryPrivilege

SeMachineAccountPrivilege

SeManageVolumePrivilege

SeProfileSingleProcessPrivilege

SeRemoteShutdownPrivilege

SeRestorePrivilege

SeSecurityPrivilege

SeShutdownPrivilege

SeSyncAgentPrivilege

SeSystemEnvironmentPrivilege

SeSystemProfilePrivilege

SeSystemTimePrivilege

SeTakeOwnershipPrivilege

SeTcbPrivilege

SeUndockPrivilege

Compte système local

Plus haut gradé de la hiérarchie des comptes de services Windows, le compte système local représente auprès des autorités concernés l’identité, par extension le profil de sécurité, du système d’exploitation. Possédant de manière intrinsèque toutes les autorisations et tous les droits requis pour un accès complet à l’ordinateur, le compte système local est ainsi par nature extrêmement puissant, plus puissant que n’importe quel compte local ou domanial quand il s’agit de privilèges de sécurité locaux. Peu de surprise, donc, à ce que ce soit sur cette identité que s’appuie la plupart des services, y compris ceux représentant des composants clé : gestionnaire de sessions (Smss.exe), sous-système d’authentification de sécurité locale (Lsass.exe), processus d’ouverture de session (Winlogon.exe), sous-système Windows (Csrss.exe), et quelques autres encore.

Le compte Système Local peut être utilisé pour exécuter un service lorsque celui-ci requiert des permissions locales élevées, comme par exemple pour écrire dans les quelques sous-ensembles du système (système de fichiers ou base de registre) où seul ce compte a le droit de le faire.

Les caractéristiques principales du compte Système Local sont les suivantes :

  • Il a pour véritable nom NT AUTHORITY\System.

  • Il est membre du groupe Administrateurs locaux. Le tableau x indique les groupes auxquels appartient le compte système local.

  • Il a le droit d’activer presque tous les privilèges (même ceux qui ne sont pas en principe accordés au compte administrateur local, par exemple la création de jetons de sécurité). Voir tableau x pour la liste des privilèges attribués au compte système local. 


  • Il possède plus de droits que le compte administrateur, pour lequel certaines parties du système d’exploitation demeurent dans tous les cas invisibles. Par exemple, alors que la ruche de sécurité HKEY_LOCAL_MACHINE\SECURITE est interdite à l’administrateur (puisque réservée à un rôle particulier), elle est autorisée pour le compte système.

  • Les processus exécutés sous le compte système local le sont avec le profil utilisateur par défaut (HKU\.DEFAULT). Ils ne peuvent par conséquent pas accéder aux données de configuration stockées dans les profils utilisateur d’autres comptes.

Compte service réseau

Autre compte duquel une instance peut se réclamer, Service réseau est utilisé par des services ayant besoin d’accéder à des ressources sur le réseau sans pour autant nécessiter de privilèges particulièrement élevés.

Représentant également le système d’exploitation, Service Réseau possède cependant moins de permissions sur le système que Système Local. En premier lieu, son profil de sécurité englobe une étendue de moindre ampleur - en termes plus techniques, le jeton d’accès attribué à Service Réseau possède moins de privilèges que celui distribué pour son confrère Système Local. D’autre part, les listes de contrôles d’accès (ACL) de nombreux objets du système sont plus restrictives pour Service Réseau qu’elles ne le sont envers Système Local, cela avec comme conséquence de donner moins de latitude aux processus exécutés sous ce compte. Ainsi, ces processus ne peuvent pas par exemple, charger de pilotes dans le système d’E/S, ou ouvrir arbitrairement d’autres processus.

Le compte Service réseau bénéficie du même niveau d’accès aux ressources et aux objets que les membres du groupe Utilisateurs. Les services qui s’exécutent sous le compte Service réseau s’identifient auprès des machines présentes sur le réseau à l’aide des informations d’identification du compte d’ordinateur.

Les processus exécutés sous le compte service réseau utilisent le profil du compte service réseau, chargé dans le registre sous HKU\S-1-5-20, "AUTORITE NT\SERVICE RÉSEAU" en tant que service réseau. (Vous aurez compris que S-1-5-20 est une valeur sous forme de SID).

Le compte Service réseau dispose de privilèges minimaux sur l’ordinateur local. Cela empêche quiconque d’utiliser le compte pour accéder à des ressources protégées du système. Aucun mot de passe n’est associé à ce compte.

Compte service local

Le compte service local est quasiment identique au compte service réseau, à cette différence majeure près qu’il ne peut accéder qu’aux ressources réseau autorisant l’accès anonyme (session nulle).

Tout comme le compte service réseau, dont il se rapproche de bien des manières du point de vue de la sécurité, service local dispose de permissions réduites sur le système d’exploitation, équivalentes à celles d’un utilisateur standard non-administrateur. Ledit compte est par conséquent majoritairement employé parallèlement à des processus qui se satisfont facilement d’un cadre étroit en ce qui concerne les droits et les privilèges qui leur sont accordés, ou qui n’ont tout simplement pas besoin d’accéder au réseau.

Les processus exécutés sous le compte service local le sont par l’intermédiaire du profil se trouvant sous HKU\S-1-5-19, lequel est chargé au niveau du système de fichiers depuis %SystemRoot%\ServiceProfiles\LocalService.

Exemples de services que Windows exécute sous le compte service local : Registre à distance (service RemoteRegistry), qui permet d’accéder à distance à la base de registre du poste ; LmHosts, qui effectue la résolution de noms NetBIOS.

Exécution de service sous un compte suppléant

Compte tenu des restrictions précédemment mentionnées, certains service ont besoin de fonctionner sous un compte de connexion suppléant, compte dont les données d’identification viendront alors alimenter le contexte de sécurité dudit service. Vous pouvez configurer un service pour qu’il soit soit exécuté sous un compte de remplacement, soit lors de la création du service soit en spécifiant un compte et un mot de passe dans l’outil d’administration Services. Pour ce faire, ouvrez la console Services (Services.msc), cliquez avec le bouton droit de la souris sur un service, sélectionnez Propriétés, allez dans l’onglet Connexion, puis cochez l’option Ce compte.

Démarrage automatique différé

Jusqu’à Windows Vista, la gestion des services ne reconnaissait que deux modes de démarrage: manuel et automatique. Du fait qu’un service à démarrage manuel exige l’intervention de l’utilisateur, l’alternative habituelle était le mode automatique, lorsque le service devait démarrer lors du démarrage du système, avant même l’ouverture d’une quelconque session utilisateur. Quel que soit le soin porté à leur optimisation, les services à démarrage automatique ont une incidence non négligeable sur les performances de démarrage du système. Pour complexifier encore ce paysage, il faut aussi noter que les utilisateurs sous Windows tendent généralement à employer la machine immédiatement après l’avoir démarré et ouvert une session, ce qu’ils estiment être antérieur à la fin des préparatifs nécessaires pour une expérience complète du système. Les services à démarrage automatique, qui dans ce contexte effectuent leur initialisation en même temps que l’utilisateur entame diverses activités, contredisent par nature ce schéma.

Pour remédier à ce problème, Microsoft avait incorporé à son système d’exploitation un mécanisme nouveau, appelé démarrage différé, dont le principe consiste en l’introduction d’une courte pour la mise en route des services concernés. Cela permet à l’utilisateur de commencer à interagir avec ses applications sans ressentir l’impact des dits services lors de l’ouverture d’une session.

Un certain nombre de services distribués avec Windows sont automatiquement mis en œuvre avec un départ retardé par rapport aux autres services. Parmi ceux-ci figurent Windows Update, le partage réseau Media Player, Windows Defender, etc.

Les concepteurs de logiciel ont la possibilité pour marquer un service comme à démarrage automatique différé d’employer l’API de contrôle de service ChangeServiceConfig2, accompagnée de la structure SERVICE_DELAYED_AUTO_START_INFO.

Soulignons, pour en terminer à leur sujet, que les services à démarrage automatique, s’ils constituent une amélioration notable, ne règlent pas tout les problèmes liées aux performances de démarrage des composants s’exécutant en marge du système d’exploitation. Il n’existe, par exemple, aucune garantie quant au moment où sera démarré un service, ni quand aura lieu la commande de contrôle émise dans ce but par le SCM. (Notez que ces limitations, loin d’être imputable à une mauvaise conception des services, découlent du fait que Windows ne soit pas un système d’exploitation temps réel.) De plus, et encore une fois du fait qu’ils n’obéissent pas à une temporalité bien définie, les services à démarrage automatique différé sont difficilement conciliables, voire incompatibles, avec les règles communes en matière de dépendances et d’ordre de démarrage des services Windows. De tels services ne peuvent en conséquence rejoindre aucune des hiérarchies prévues pour gérer les enchaînements de démarrage de services, conçues pour donner le départ à des services ayant besoin entre eux de respecter un ordre donné. Un service à démarrage automatique peut par contre dépendre d’un service service à démarrage automatique différé, cela établissant néanmoins le problème du lien qui unit entre les deux services. Ainsi, comme un service ne peut démarrer que lorsque les services dont il dépend ont eux même démarrés, le SCM lancera le service à démarrage automatique différé lors de la séquence d’initialisation du système, avec comme effet de réduire à néant tous les avantages que comptait procurer le dit service.

Gérer les services

Windows propose quatre outils principaux avec lesquels gérer des services :

  • L’outil d’administration Services (Services.msc)

  • Le Gestionnaire des tâches

  • La stratégie de groupe

  • La commande sc.exe

L’ensemble est intégré en standard dans les diverses versions et déclinaisons des systèmes Microsoft.

Service Control (Sc.exe)

La commande Sc.exe permet d’interagir avec les services (démarrage, suspension et reprise, arrêt) et de gérer les différents aspects les concernant : type de démarrage, dépendances, actions en cas d’échec, etc.

Le tableau qui suit inventorie les différents commutateurs, et leurs effets, disponibles auprès de la commande Sc.

Table 40. Commandes SC
Commande Action

query

Interroge l’état d’un service ou énumère l’état des types de services

queryex

Interroge l’état étendu d’un service ou énumère l’état des types de services

start

Démarre un service

pause

Envoie une demande de contrôle PAUSE à un service

interrogate

Envoie une demande de contrôle INTERROGATE à un service

continue

Envoie une demande de contrôle CONTINUE à un service

stop

Envoie une demande STOP à un service

config

Modifie la configuration d’un service (persistant)

description

Modifie la description d’un service

failure

Modifie les actions entreprises par un service en cas d’échec

failureflag

Modifie l’indicateur des actions d’échec d’un service

sidtype

Modifie le type de SID d’un service

privs

Modifie les privilèges requis d’un service

managedaccount

Modifie le service pour marquer le mot de passe du compte de service comme étant géré par LSA

qc

Interroge les informations de configuration d’un service

qdescription

Interroge la description d’un service

qfailure

Interroge les actions entreprises par un service en cas d’échec

qfailureflag

Interroge l’indicateur des actions d’échec d’un service

qsidtype

Interroge le type de SID d’un service

qprivs

Interroge les privilèges requis d’un service

qtriggerinfo

Interroge les paramètres de déclenchement d’un service

qpreferrednode

Interroge le noeud NUMA favori d’un service

qmanagedaccount

Interroge si un service utilise un compte avec un mot de passe géré par LSA

qprotection

Interroge le niveau de protection de processus

quserservice

Interroge une instance locale d’un modèle de service utilisateur

delete

Supprime un service (du Registre)

create

Crée un service (en l’ajoutant au Registre)

control

Envoie un contrôle à un service

sdshow

Affiche le descripteur de sécurité d’un service

sdset

Définit le descripteur de sécurité d’un service

showsid

Affiche la chaîne du SID de service correspondant à un nom arbitraire

triggerinfo

Configure les paramètres de déclenchement d’un service

preferrednode

Définit le noeud NUMA favori d’un service

getdisplayname

Obtient le nom complet DisplayName d’un service

getkeyname

Obtient le nom de clé d’un service (ServiceKeyName)

enumdepend

Énumère les dépendances d’un service

boot

Indique si le dernier démarrage doit être enregistré comme la dernière configuration de démarrage valide connue

lock

Verrouille la base de données des services

querylock

Interroge l’état de verrouillage (LockStatus) d’une base de données du Gestionnaire de contrôle des services

Onglet Services du Gestionnaires des tâches

L’onglet Services du Gestionnaires des tâches répertorie un certain nombre d’informations concernant les services : nom, ID du processus hôte, description, état (arrêté ou en cours d’exécution) et groupe.

Un processus héberge potentiellement plusieurs services. Pour trier les services par numéro d’identification de processus (PID) associé, cliquez sur l’en-tête de la colonne appropriée. Cliquez sur l’en-tête de la colonne État pour trier les services en fonction de leur état.

En effectuant un clic droit sur un service, vous disposez d’un menu contextuel à partir duquel les actions suivantes sont proposées :

  • Démarrer un service arrêté

  • Arrêter l’exécution d’un service démarré

  • Aller dans le processus associé au service (sur l’onglet Détails)

Services.msc

Le composant enfichable Services de la console MMC permet une gestion souple des services Windows. Pour afficher ce complément, saisissez services.msc à l’intérieur d’une invite de commandes, ce qui devrait donner lieu à l’apparition d’une nouvelle fenêtre graphique. // telle que montrée figure x.

Notez que des privilèges d’administrateur sont mobilisés pour donner toutes ses capacités à l’outil. En l’exécutant en tant qu’utilisateur standard, vous afficherez les paramètres des services, mais ne pourrez ni démarrer ni arrêter la plupart d’entre eux, pas plus que modifier le type de démarrage ou procéder à d’autres modifications de configuration.

Erreur de démarrage

Dans l’éventualité où un service ou un pilote signale une erreur en réponse à la commande de démarrage du SCM, la réaction de ce dernier est conditionnée par la valeur ErrorControl de la clé de registre associée au service.

  • Si ErrorControl vaut SERVICE_ERROR_IGNORE (0) ou n’est pas spécifiée, le SCM ignore l’erreur et continue le démarrage des services. Tout se passe dans cette configuration comme si aucun problème n’était advenu.

  • Si ErrorControl vaut SERVICE_ERROR_NORMAL (1), le SCM enregistre l’événement dans le journal Système et poursuit le démarrage.

  • Si ErrorControl vaut SERVICE_ERROR_SEVERE (2), le SCM enregistre l’événement dans le journal Système, bascule la configuration registre du système de sorte à employer la dernière bonne configuration connue (autrement dit les réglages avec lesquels Windows a démarré correctement pour la dernière fois), puis redémarre le système. Si le système était déjà en train de s’amorcer conformément à la dernière bonne configuration connue, il se contente de redémarrer.

  • Si ErrorControl vaut SERVICE_ERROR_CRITICAL (3), le SCM enregistre l’événement dans le journal Système (Il se peut à ce stade qu’il n’y parvienne pas), restaure la dernière bonne configuration connue et redémarre l’ordinateur. Si le système était déjà en train de s’amorcer conformément à la dernière bonne configuration connue, il s’arrête, la procédure de démarrage n’allant pas plus loin.

Sécurité des services

Table 41. Mappage générique des droits d’accès aux fichiers
Droit générique Signification

GENERIC_ALL

SC_MANAGER_ALL_ACCESS

GENERIC_EXECUTE

SC_MANAGER_CONNECT

SC_MANAGER_LOCK

STANDARD_RIGHTS_EXECUTE

GENERIC_READ

SC_MANAGER_ENUMERATE_SERVICE

SC_MANAGER_QUERY_LOCK_STATUS

STANDARD_RIGHTS_READ

GENERIC_WRITE

SC_MANAGER_CREATE_SERVICE

SC_MANAGER_MODIFY_BOOT_CONFIG

STANDARD_RIGHTS_WRITE

Contrôle des services

Programmes d’installation et d’administration interagissent avec le SCM, indirectement avec les applications service, via une technologie de passage de messages. Dans ce scénario, une application en nécessité d’un service quelconque envoie un code de contrôle, non à l’application service elle-même, mais au SCM, puisque c’est à lui que revient la responsabilité de prendre en charge la commande et de la relayer au service approprié.

La fonctionnalité d’envoi d’un code de contrôle vers à un service est rendu visible dans l’API Windows par la fonction ControlService. Une fois établie une connexion avec le SCM, et négociés les droits d’accès requis pour une commande (les permissions nécessaires dépendent d’elle), un programme appelle ControlService et spécifie, entre autre, un code de contrôle qui représente l’opération souhaitée. Il fournit de même un pointeur vers une structure SERVICE_STATUS, alimentée par une application service pendant le traitement et qui reçoit les dernières informations sur l’état du service. Les constantes et valeurs admissibles au titre de code de contrôle sont énumérées dans le tableau suivant.

Table 42. Code de contrôle des services

Code

Valeur

SERVICE_CONTROL_STOP

0x00000001

SERVICE_CONTROL_PAUSE

0x00000002

SERVICE_CONTROL_CONTINUE

0x00000003

SERVICE_CONTROL_INTERROGATE

0x00000004

SERVICE_CONTROL_SHUTDOWN

0x00000005

SERVICE_CONTROL_PARAMCHANGE

0x00000006

SERVICE_CONTROL_NETBINDADD

0x00000007

SERVICE_CONTROL_NETBINDREMOVE

0x00000008

SERVICE_CONTROL_NETBINDENABLE

0x00000009

SERVICE_CONTROL_NETBINDDISABLE

0x0000000A

Le SCM envoie un code de contrôle à un service que si ce dernier a explicitement mentionné prendre en charge la commande, et que si son état le lui permet. Le SCM traite les notifications à destination des services de manière sérialisé, et bloquera un certain temps si un service est occupé. Si le service n’a toujours pas retourné de sa fonction gestionnaire de contrôle, que le service implémente pour traiter les diverses commandes qu’il reçoit du SCM, ControlService échoue avec le code d’erreur ERROR_SERVICE_REQUEST_TIMEOUT.

Les services en cours de fonctionnement acceptent par défaut le code de contrôle SERVICE_CONTROL_INTERROGATE, qui avertit un service qu’il doit communiquer son état au SCM. Les pilotes n’acceptent pas de codes autres que SERVICE_CONTROL_STOP and SERVICE_CONTROL_INTERROGATE. Chaque service indique les codes de contrôle supplémentaire qu’il accepte avec un appel de la fonction SetServiceStatus.

Erreur des services

Le tableau suivant énumère les codes d’erreur Windows utilisés en cas d’erreur des services.

ERROR_ACCESS_DENIED

ERROR_DEPENDENT_SERVICES_RUNNING

ERROR_INVALID_HANDLE

ERROR_INVALID_PARAMETER

ERROR_INVALID_SERVICE_CONTROL

ERROR_SERVICE_CANNOT_ACCEPT_CTRL

ERROR_SERVICE_NOT_ACTIVE

ERROR_SERVICE_REQUEST_TIMEOUT

ERROR_SHUTDOWN_IN_PROGRESS

Chaque service peut au travers sa configuration de base orienter le comportement de l’ordinateur en cas de défaillance. Le SCM s’entend avec le système de sorte que ce dernier lui signale quand un processus de services se termine. Dans l’éventualité où cette fin résulte d’un dysfonctionnement, le SCM détermine quels sont les services que le processus exécutait et effectue les mesures de récupération spécifiées par les valeurs FailureActions et FailureCommand enregistrées sous la clé de registre idoine.

Quand un service entre dans l’état SERVICE_STOPPED et que le code d’erreur retourné au SCM n’est pas synonyme de succès (ERROR_SUCCESS), le SCM vérifie si l’indicateur des actions en cas d’échec (FailureActionsOnNonCrashFailures) associé au service est actif et, s’il l’est, applique la même procédure de récupération que si le service était bloqué. Pour tirer profit de ce paramètre, les concepteurs de logiciels ont à leur disposition l’API ChangeServiceConfig2, et les administrateurs système la commande Sc.exe et ses commutateurs -failureflag et -qfailureflag.

Les actions qu’un service a la possibilité de configurer pour le SCM sont le redémarrage du service, l’exécution d’un programme, le redémarrage de l’ordinateur et, enfin, l’inaction (qui devient dans ce contexte à la fois une action et la conséquence attendue d’un choix). Il est en outre envisageable de définir des actions différentes selon qu’il s’agit de la première fois où le processus de services échoue, de la seconde, et des fois suivantes. À ce panel de mesures s’ajoute un compteur de défaillances.

Pour spécifier les options de récupération d’un service, allez dans l’onglet Récupération de la boite de dialogue des propriétés du service dans le composant enfichable MMC Services.

Arrêt des services

Lors de la phase d’extinction, l’un des comportements attendus de la part du sous-système Windows, est ‎de de boucler sur tous les processus actifs en vue de leur signaler que le système est en cours d’arrêt. Le processus du SCM, compte tenu des composants avec lesquels il interagit, fait en les circonstances l’objet d’un traitement à part. Ainsi, quand Csrss rencontre ledit processus, il attend un délai prédéfini qui diffère de celui des autres processus, cela afin de prendre en compte les éventuelles opérations de nettoyage que des services auraient à effectuer. Le délai que Csrss laisse au SCM pour se terminer est donnée par la valeur HKLM\SYSTEM\CurrentControlSet\Control\WaitToKillServiceTimeout, qui est de 20 secondes par défaut. (Pour ne pas impacter négativement la procédure d’arrêt, ce qui viendrait dégrader l’expérience utilisateur, il est recommandé de ne pas augmenter cette valeur de manière trop significative.)

Le gestionnaire d’arrêt du SCM a la charge d’envoyer des notifications d’arrêt à tous les services ayant demandé ces notifications lors de leur initialisation. Pour chaque service auquel il envoie une commande d’arrêt, le SCM tient compte de l'indication d’attente (wait hint)du service. Après l’envoi des messages d’arrêt, le SCM attend soit qu’un des services auxquels il a notifié l’arrêt se termine, soit que le délai spécifié par l’indication d’attente soit écoulé.

Tandis que le SCM est occupé à mettre fin aux services, Csrss attend que le SCM se termine. Sur les versions de Windows antérieures à Vista, dans l’éventualité où l’attente de Csrss se terminait sans que le SCM se soit arrêté (signe que le délai WaitToKillServiceTimeout avait expiré), Csrss tuait le processus et faisait aller de l’avant le processus d’arrêt. Les concepteurs du noyau ont par la suite estimé que cette méthode n’était pas la meilleure, et introduit des notifications de pré-arrêt et l’application d’un ordre d’arrêt.

Les notifications de pré-arrêt sont transmises, en utilisant le même mécanisme que les notifications d’arrêt, aux services les ayant demandé via l’API SetServiceStatus, suite à quoi le SCM attend leurs accusés de réception respectifs. L’idée motrice sous-jacente aux notifications de pré-arrêt est de donner aux services les plus susceptibles de passer du temps dans une procédure d’arrêt (tels qu’un service faisant la passerelle vers des fonctionnalités de base de données) plus de temps pour la mener à bien. Dans cette optique, le SCM envoie une requête de progression et attend un certain laps de temps que le service réponde à cette notification. Si le service ne répond pas dans ce délai imparti, il sera tué pendant la procédure d’arrêt ; autrement, le service peut continuer à fonctionner aussi longtemps qu’il le faut tant qu’il continue de répondre au SCM. Un service peut augmenter le délai de réponse, 3 minutes dans la configuration par défaut, par le biais de l’API ChangeServiceConfig2.

En plus des notifications, le SCM offre aux services la possibilité de redéfinir l’ordre dans lequel il émet des commandes d’arrêt. Les services qui dépendent d’autres services au niveau de l’arrêt peuvent spécifier leurs dépendances dans la valeur de registre HKLM\SYSTEM\CurrentControlSet\Control\PreshutdownOrder.

Processus partagés entre des services

Si exécuter chaque service dans son propre processus est une solution particulièrement adaptée en termes de robustesse (par extension, de fiabilité), procéder ainsi n’en constitue pas moins un éventuel gaspillage des ressources système. Afin de l’empêcher, Windows permet à plusieurs services de résider sous un même toit (comprendre de partager un même processus), et de la sorte mutualiser les aspects techniques qu’ils ont en commun.

Parmi les services prédéfinis de Windows, certains sont configurés pour s’exécuter dans leur propre processus, tandis que d’autres le sont pour se partager un processus. Par exemple, le processus du LSASS héberge différents services liées à la sécurité, tels le service Gestionnaire de comptes de sécurité (SamSs) ou le service Ouverture de session réseau (Netlogon).

Ainsi que nous l’avons sous-entendu plus haut, partager un processus entre plusieurs services n’a pas que des avantages puisque, dans une telle configuration, si l’un des services d’un processus partagé rencontre un dysfonctionnement qui force l’arrêt du processus, il s’ensuit que tous les services dudit processus prennent automatiquement fin. Il est en outre plus difficile dans ce contexte de mesurer l’utilisation des ressources d’un service spécifique.

Windows assure la complémentarité entre plusieurs services par le biais d’un processus générique appelé Service Host (\Windows\System32\Svchost.exe).

Bon nombre de services Windows s’appuient pour leur fonctionnement interne sur SvcHost, dont Appel de procédure distante (RpcSs), Mises à Jour Automatiques, Pare-Feu, Plug and Play, Client DNS, Partage de fichiers, et d’autres.

Windows implémente les services exécutés dans SvcHost par le biais de modules chargeables dynamiquement (DLL). Il exige des services concernées de se présenter par conséquent sous cette forme, et de montrer conformément à cela une valeur nommée ServiceDll, définie dans une sous-clé Parameters, qui pointe vers le fichier DLL apparenté au service.

Tous les services se partageant un même processus SvcHost mettent en évidence par l’intermédiaire de leur configuration l’appartenance au même ensemble, ce qu’ils font en définissant une valeur ImagePath de la forme \Windows\System32\Svchost.exe -k. Quand le SCM découvre, au démarrage des services, le premier service ayant une valeur ImagePath SvcHost dotée d’un paramètre particulier, il créé une nouvelle entrée dans la base de données d’images et exécute un processus SvcHost avec ce paramètre. Par la suite, ledit processus SvcHost recherche une valeur ayant le même nom que le paramètre sous HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Svchost, qu’il interprète comme une liste de noms de service. Une fois ces éléments réunis, le processus SvcHost informe le SCM qu’il héberge ces services.

Dans l’éventualité où le SCM rencontre un service SvcHost dont la configuration (valeur ImagePath) renvoie à une entrée deja présente dans la base de données d’images, il ne crée pas un nouveau processus, mais envoie une commande de démarrage du service au processus SvcHost auquel il a déjà donné lieu pour cette rubrique. Le processus SvcHost existant lit le paramètre ServiceDll dans la clé de registre associé au service, puis charge la DLL correspondante.

Pour voir depuis une invite de commandes la liste des services exécutés dans des processus, utilisez la commande tasklist /svc.

Balises de service

L’un des inconvénients de partager un processus entre plusieurs services est qu’il est dans ce contexte difficile d’effectuer un bilan fidèle de la consommation isolée de chaque service. (Tous les services hébergés au sein d’un même processus partagent par extension les mêmes ressources, y compris l’espace d’adressage, la table des handles, mais encore différents compteurs qui, à l’échelle d’un processus donné, permettent de mesurer les performances.) Un autre inconvénient de cette approche tient au fait qu’elle peut éventuellement nuire à l’identification des threads appartenant à un même service - soit parce que des threads auxiliaires ont été employés, soit parce ce que l’adresse de début du thread ne met pas en évidence le nom de la DLL à laquelle s’apparente le service. Pour proposer une solution à ces difficultés, Windows intègre la notion de balises de service (service tags).

Le SCM génère la balise correspondante à un service à l’aide de la fonction ScGenerateServiceTag.

Tâches planifiées

SchTasks

La commande schtasks offre une gestion souple du dispositif de planifications des tâches intégré à Windows. Elle permet de créer supprimer, effectuer des requêtes, modifier, exécuter et mettre fin à des tâches planifiées sur un système local ou distant.

Sur le plan pratique, schtasks effectue les mêmes opérations que l’utilitaire graphique Planificateur de tâches, en conséquence de quoi les deux sont utilisables ensemble et de manière interchangeable. A titre informatif, notez que schtasks est apparu dans Windows Server 2003 en remplacement de l’illustre commande at, dont l’utilisation est désormais déconseillée. (Si les raisons qui ont conduit Microsoft à ne pas supprimer ladite commande du programme d’installation de Windows restent à ce jour inconnues, il est raisonnable d’imputer cela à la volonté de prendre en charge les anciens scripts.)

Protection et restauration du système

Windows contient diverses fonctionnalités, parmi lesquels Protection du système et sa contrepartie Restauration du système, qui permettent aux utilisateurs et administrateurs de créer des sauvegardes et, le cas échéant, d’effectuer une récupération des composants névralgiques ou les plus importants de l’ordinateur, y compris les paramètres fondamentaux du système d’exploitation.

Windows crée automatiquement des points de restauration. Ces points sont planifiés de façon régulière par Windows ou sont créés automatiquement lors d’un changement notable du système. Des points de restauration sont automatiquement créés lors des événements que voici :

  • Installation d’un pilote.

  • Installation d’une application compatible avec la fonctionnalité de restauration système et qui va, en quelque sorte, commanditer la création d’un point de restauration.

  • Installation d’une mise à jour via Windows Update.

  • Lorsqu’un utilisateur restaure son ordinateur de sorte à le replacer à un état préalablement enregistré.

  • Dans le cadre des outils intégrés à Windows pour la sauvegarde et la restauration de données.

  • Relativement aux paramètres de la tâche intitulée SR dans le Planificateur de tâches.

  • En fonction de la périodicité définie au niveau des clés de registre RPGlobalInterval et RPSessionInterval sous HKLM\Software\Microsoft\Windows NT\CurrentVersion\SystemRestore.

Créer un point de restauration

Windows offre la possibilité de créer manuellement des points de restauration. Cela est potentiellement utile avant d’effectuer une modification susceptible d’impacter négativement le système d’exploitation, en vue de le restaurer plus tard au cas où un problème survenait. Avant toute chose, vérifiez que la fonctionnalité Protection du système de Windows est activée. Pour ce faire, faite apparaitre la boîte de dialogue des propriétés systèmes, cliquez sur le bouton Configurer, puis activez, si elle ne l’est déjà, l’option Activer la protection système. Procédez ensuite comme indiqué dans ce qui suit :

  1. Dans Propriétés système, onglet Protection du système, cliquez sur le bouton Créer se trouvant en bas de la fenêtre.

  2. Donnez un nom à votre point de restauration. Dans l’idéal, celui-ci doit être représentatif soit de l’état actuel de l’ordinateur ou de l’action que vous comptez mener à terme après la création du point de restauration.

  3. Une fois le point de restauration créé, cliquez sur OK pour quitter l’assistant de création de point de restauration.

Pour voir concrètement comment se matérialise un point de restauration sur le système de fichiers, rendez-vous dans le répertoire nommé System Volume Information à la racine du disque.

Restaurer les fichiers et paramètres système

Si vous estimez que votre système n’a plus sa stabilité d’antan ou offre des performances moindres des suites de l’installation d’un logiciel, d’un pilote ou d’une mise à jour de Windows, il est très simple de remédier à ce problème en effectuant une restauration du système.

L’utilitaire de restauration du système permet de restaurer l’ordinateur à n’importe lequel des points de restauration disponibles. Ceux-ci peuvent être de trois types :

  • Manuels Ils ont été créés en réponse à un besoin expressément formulé par l’utilisateur.

  • Système Ils ont été planifiés automatiquement par le système d’exploitation.

  • Installation Ils ont automatiquement été créés lors de l’installation de certaines applications.

Pour effectuer une restauration du système, dirigez-vous d’abord vers l’onglet Protection du système de la boite de dialogue Propriétés système. Ensuite, cliquez sur Restauration du système, sous Restaurer le système. Une nouvelle boite de dialogue intitulée Restauration du système s’affiche. Cliquez sur Suivant, choisissez un point de restauration dans la liste puis validez. (La quantité de points disponibles dépend de vos paramètres pour la création de telles sauvegardes.)À partir de là, Windows vous laisse une dernière occasion de confirmer, au contraire d’infirmer, vos choix. Cliquez sur Terminer pour procéder à la restauration.

Windows Management Instrumentation (WMI)

Windows Management Instrumentation (WMI) est une infrastructure de commande et contrôle intégrée pour Windows.

WMI est une implémentation du modèle Web-Based Enterprise Management (WBEM) qui a pour objectif de définir des standards de gestion pour les équipements informatiques (systèmes, réseaux et périphériques) sur plusieurs plates-formes. S’appuyant en la matière sur une pluralité de normes industrielles régies par le consortium DMTF (Distributed Management Task Force), WBEM a été pensé de telle sorte à couvrir la mise en oeuvre d’un système d’acquisition et de partage des données évoluant dans un milieu distribuée. WBEM, par extension WMI, autorise l’accès aux données à partir de nombreuses technologies sous-jacentes, parmi lesquelles Win32, DMI (Desktop Management Interface) et le protocole SMTP (Simple Network Management Protocol).

De nombreux utilitaires d’administration des systèmes et réseaux Windows exploitent WMI, par exemple les composants Propriétés système, Informations système. En outre, la plateforme de script Windows PowerShell possède des commandes spéciales en ce qui concerne l’interaction avec des objets WMI.

Les technologies incorporées à WMI sont pour la plupart fondées sur COM et sur DCOM, ce qui permet aux objets WMI de recourir à des techniques de programmation standard comme l’héritage, la composition ou la surcharge.

Fonctionnalités de WMI

Conçu comme une réponse au besoin d’uniformisation de la gestion des systèmes, des applications et des réseaux d’entreprise, WMI propose une infrastructure de gestion évolutive autour de laquelle se développe un riche panel de fonctionnalités.

  • API d’écriture de script uniforme Tous les objets gérés sont définis dans un cadre objet commun fondé sur le modèle objet CIM. Les scripts n’ont besoin d’utiliser qu’une seule API, WMI, pour accéder aux informations concernant des sources très diverses.

  • Administration à distance Par définition, les objets gérés dans WMI sont disponibles pour les applications et les scripts aussi bien localement qu’à distance. La gestion à distance des objets ne requiert aucune tâche supplémentaire.

  • Recherche et navigation Les applications et les scripts peuvent découvrir les informations disponibles sur un système en énumérant les classes disponibles. Les relations entre objets liés peuvent être détectées et parcourues afin de déterminer l’influence d’une entité gérée sur une autre.

  • Fonctionnalité de requête L’infrastructure WMI traite les données qu’elle gère comme une base de données relationnelle et permet l’utilisation de requêtes SQL pour filtrer et concentrer les requêtes uniquement sur les données pertinentes.

  • Fonctionnalités de publication d’événements et d’abonnements Des événements peuvent être demandés pour pratiquement toute modification apportée aux objets gérés du système, que ces objets disposent ou non de fonctionnalités internes d’événement. Les abonnés à des événements peuvent demander la notification d’événements très spécifiques en fonction de leurs intérêts particuliers (et non uniquement des événements prédéfinis par les développeurs). Grâce à une architecture très souple, toute action définie par l’utilisateur peut en principe être effectuée à réception d’un événement donné.

Architecture WMI

WMI se compose de quatre grands composants : applications d’administration, infrastructure WMI, fournisseurs et objets administrés.

  • Applications d’administration Les applications d’administration sont des applications Windows ou des scripts qui interagissent avec l’infrastructure WMI. Elles accèdent à et affichent ou traitent les données concernant les objets administrés, font s’exécuter des méthodes de fournisseurs WMI, et s’abonnent à des événements en appelant l’API COM pour WMI ou l’API de script pour WMI.

  • Infrastructure WMI L’infrastructure WMI relie fournisseurs et consommateurs WMI et comporte deux volets : le service WMI (Winmgmt), agissant en tant que médiateur entre les applications de gestion et les fournisseurs de données WMI, et le magasin WMI, qui sert de zone de stockage pour les données statiques liées à WMI, comme les classes définies par les fournisseurs. (Seules les données statiques sur des objets sont stockés dans cette base de données. WMI obtient la plupart des données de façon dynamique à partir du fournisseur lorsqu’un client en fait la demande.) Le magasin WMI utilise un espace de noms qui contient plusieurs sous-espaces que WMI arrange de manière hiérarchisée. Le service WMI crée des espaces de noms, tels que root\default, root\cimv2, pendant l’amorçage du système et préinstalle un ensemble de définitions des données et des classes, y compris les classes Win32, les classes système WMI, et d’autres. Les espaces de noms restants sont créés et alimentés par les fournisseurs WMI. Pour plus d’informations et une liste de fournisseurs WMI, consultez Fournisseurs WMI.

  • Fournisseurs WMI et objets administrés Les fournisseurs WMI sont des serveurs COM qui surveille un ou plusieurs objets administrés pour WMI. Un objet peut modéliser un composant logique ou physique, par exemple un disque dur, une carte réseau ou un processus, ou un ensemble de composants, par exemple un ordinateur. (L’objet ordinateur contiendrait peut-être l’objet carte réseau, et certainement l’objet disque dur.) En plus de définir des objets, les fournisseurs doivent interfacer WMI avec les objets, et gérer les messages de WMI aux objets administrés.

Chaque fournisseur WMI, qui peut se présenter sous la forme d’une DLL chargée dans le processus gestionnaire de WMI, sous la forme d’une application Windows autonome ou sous la forme d’un service Windows, écrit et publie les définitions des classes pour lesquelles il renvoie les données et effectue des opérations dans le langage MOF (Managed Object Format). MOF est un langage qui conçoit sous forme de classes des représentations d’éléments.

Un exemple de fournisseur est le fournisseur Registry préinstallé, qui accède aux données du Registre. Le fournisseur Registry dispose d’une classe WMI, StdRegProv, avec de nombreuses méthodes mais aucune propriété. D’autres fournisseurs préinstallés, comme le fournisseur Win32, ont généralement des classes avec de nombreuses propriétés, mais peu de méthodes, telles que Win32_Process ou Win32_LogicalDisk. Le fichier DLL du fournisseur, Stdprov.dll, contient le code qui renvoie dynamiquement des données à la demande des scripts ou des applications clientes.

PowerShell

Windows PowerShell, anciennement Microsoft Command Shell (MSH), nom de code Monad, est une interface en ligne de commande et un langage de script au coeur de la stratégie Microsoft pour l’administration de ses nouveaux produits et systèmes. Basé sur la programmation orientée objet, créé à partir du Framework Microsoft .NET, PowerShell aide utilisateurs et administrateurs à contrôler la configuration de Windows, tant coté système qu’applicatif, et fournit une structure logicielle complète via laquelle automatiser les tâches d’administration.

Les buts de PowerShell sont multiples : fournir un environnement à partir duquel gérer l’ordinateur et accéder aux ressources associées, telles que processus, systèmes de fichiers, magasins de certificats, Registre, variables d’environnement, etc., être au moins égal sinon meilleur que le Shell UNIX, direct mètre étalon en matière d’interprétation de commandes, avoir une interopérabilité et une compatibilité avec les commandes et les scripts existants, une meilleure sécurité, et bien d’autres encore.

Combinant interactivité, souplesse et de nombreuses possibilités d’extension, PowerShell ancre dans Windows des technologies qui jusqu’alors faisait défaut, ou ne répondait pas aux critères de qualité requis - il faut à ce sujet reconnaitre que, antérieurement à PowerShell, l’environnement en ligne de commande fourni nativement avec Windows fait pâle figure en comparaison du Shell Unix. Utile pour quiconque souhaite accélérer les tâches répétitives, PowerShell met la puissance du .NET Framework, duquel il est issu, à la portée de personnes qui utilisent la ligne de commande et écrivent des scripts. Il introduit un certain nombre de concepts nouveaux et puissants qui vous permettent d’étendre les connaissances que vous avez acquises et les scripts que vous avez créés dans les environnements de l’invite de commandes Windows et Windows Script Host.

Sur l’origine du nom de code Monad

Le nom de code Monad vient du livre Monadologie, une œuvre de 1714 écrite en français par le philosophe allemand Leibniz. Elle affirme que la réalité est composée d’éléments fondamentaux appelés monades, qui sont intégrés ensemble dans une harmonie pré-établie. De façon analogue, Windows PowerShell est composé d’une série de tâches exécutées par une série de composants. Dans le cas présent, ces composants sont appelés commandlets (abrégées en cmdlets dans la console de commande), on rencontre aussi l’anglicisme commandelettes.

Considérations sur les langages de script dans Microsoft Windows

Les systèmes d’exploitation Microsoft, même si à des degrés et selon des modalités divers, ont de tout temps incorporé la logistique nécessaire à l’interprétation des commandes informatiques et au traitement par lots. (Un traitement par lots, batch processing en anglais, désigne un enchaînement automatique d’une suite de commandes sur un ordinateur sans intervention d’un opérateur.)

C’est en 1981 que le MS-DOS fait son apparition avec les premiers scripts batch. L’interpréteur de commandes standard (command.com) dispose de deux modes de travail distincts. Le premier est le mode interactif, dans lequel l’utilisateur saisit des commandes qui sont ensuite exécutées immédiatement. Le second est le mode de traitement par lots, qui exécute une séquence prédéfinie d’instructions stockées dans des fichiers à l’extension .bat. S’ils possèdent effectivement un jeu de commandes spécifiques pour le traitement par lots (structures de boucle, sauts conditionnels et sauts catégoriques, etc.), les programmes batch pour MS-DOS sont très limités en termes de fonctionnalités.

Après DOS vient Windows, dont l’interface présentée à l’utilisateur est assurée par le programme Explorateur Windows, à la fois shell graphique et gestionnaire de fichiers. Les premières versions de Windows, lesquelles s’appuient encore largement sur MS-DOS, conserve l’interpréteur de commande livré par défaut avec ces systèmes, et du même coup les limitations inhérentes. Cette situation perdurera jusqu’au déclin de la famille de systèmes d’exploitation basée sur Windows 95, incluant Windows 98 et Windows Me, ce dernier se positionnant comme la cinquième, dernière et ultime version de Windows 9x.

Accessible via toutes les versions de Windows à partir de Windows NT, Le programme Cmd (fichier exécutable cmd.exe) remplace COMMAND.COM au titre d’interpréteur de commandes standard. Les fichiers batch du Windows NT sont les fichiers dotés de l’extension .BAT ou .CMD. Leur syntaxe est héritée de COMMAND.COM de MS-DOS, mais est nettement plus puissante.

Apparu avec Windows 98 et l’Option Pack de Windows NT 4.0, Windows Script Host (WSH) dote les systèmes d’exploitation Microsoft d’une puissante technologie de scripts. Concrètement, WSH se présente sous la forme de programmes hôtes, indépendants du langage de programmation utilisé, chargés d’activer l’interpréteur approprié pour un script. Ces interpréteurs peuvent ensuite accéder au système par l’intermédiaire des objets COM/ActiveX scriptables installés sur le système. (Ils peuvent en particulier faire appel à WMI pour interagir avec le système d’exploitation). WSH n’étant pas un langage en soi, il fallait un langage de scripts compatible pour l’exploiter. Les systèmes Windows incluent deux interpréteurs : VBScript et JScript. Des interpréteurs pour d’autres langages, comme Perl ou Python, ont également été́ réalisés.

Si la standardisation de WSH a offert d’indéniables atouts aux systèmes d’exploitation Windows, l’outil présentait de nombreux défauts. L’absence de langage et d’environnement standard pour l’écriture de scripts d’une part, puisque rien ne garantissait que le langage de scripts compatible WSH choisi par l’administrateur serait disponible. La seule manière d’être certain que le langage de scripts ou la version de WSH était compatible avec le système administré consistait à utiliser un langage de scripts natif, beaucoup moins puissants, et à accepter les problèmes afférents. Par ailleurs, WSH ouvrait une porte aux attaques par code malveillant. Cette vulnérabilité a donné naissance à un flot de virus, de vers et autres programmes indélicats qui ont causé de nombreux dégâts sur les systèmes informatiques, et cela à cause de l’accent mis sur l’automation sans intervention de l’utilisateur. En outre, WSH ne permettait pas une utilisation en ligne de commande. Très clairement, une approche différente était nécessaire pour l’administration des systèmes.

Avec le développement de Windows Vista, Microsoft, conscient du besoin d’un shell en ligne de commande robuste et sûr pour l’administration de ses systèmes d’exploitation, crée Windows PowerShell. PowerShell a été conçu comme un shell, avec un accès complet aux composants de Windows, par l’intermédiaire de .NET Framework, des objets COM (Component Object Model) et d’autres méthodes. D’abord distribué séparément, il est intégré nativement dans Windows 7. Depuis Windows 8, PowerShell dispose d’une place plus prononcée au sein du système d’exploitation avec un raccourci dans toutes les fenêtres de l’Explorateur de fichiers, dans le menu Fichier. Dans le futur, PowerShell pourrait remplacer les interfaces actuelles, comme cmd.exe, WSH, les outils en ligne de commande, etc., et être totalement intégré aux systèmes Windows.

Vue d’ensemble de Windows PowerShell

Environnements interactif et de script

Avant toute chose un environnement au service des utilisateurs, Windows PowerShell se présente à ces derniers sous la forme d’un shell. Ce que l’on nomme shell dans le contexte de cet ouvrage est l’interface en ligne de commande, ou CLI (_Command Line Interface), fonctionnant à partir d’instructions en mode texte. Cela dit, et seconde forme au travers laquelle une couche logicielle peut fournir une interface à un système d’exploitation, un shell peut aussi être de type graphique. L’explorateur Windows est un exemple de shell graphique, unifiant dans un ensemble visuel commun différentes perspectives pour interagir avec Windows. Beaucoup d’utilisateurs réduisent la signification du mot shell au sens d’interface en ligne de commande, ignorant que ce mot a d’autres acceptations. Pour en revenir à PowerShell, il est aussi intéressant de noter quelle place l’outil a su se frayer dans l’écosystème Windows, quelles inflexions il a produit sur les stratégies de Microsoft pour l’administration système de ses produits, toutes maintenant clairement orientée ligne de commandes.

Le langage de script PowerShell, basé sur des tâches, spécialement conçu pour l’administration, permet de contrôler tout un système et ses ressources, que ce soit localement ou à distance. Couplant les avantages d’un langage orienté commande, comme le font les shells Unix, et la gestion d’objets, il a le mérite d’être simple à comprendre, bien documenté et de permettre d’atteindre rapidement des résultats.

Les paramètres initiaux de Windows PowerShell, réglés au plus strict, sont conçus dans l’optique d’un maximum de sécurité. Reflet des conditions dans lesquelles PowerShell charge des fichiers de configuration et exécute des scripts (cf. section suivante : Stratégies d’exécution), l’application de la stratégie d’exécution Restricted par défaut, laquelle bloque systématiquement l’exécution de tout script et active l’interpréteur uniquement pour un usage interactif.

Orientation objet

Contrairement aux commandes d’interface de ligne de commande traditionnelles, Windows PowerShell permet d’utiliser des scripts développés en orienté objet (OOP, Object-oriented Programming).

La plupart des shells opèrent dans un environnement de type texte. Cela signifie généralement que la sortie doit être traitée pour effectuer des tâches. Par exemple, si les données d’une commande doivent être envoyées à une autre commande, la sortie de la première doit généralement être remise en forme afin de répondre aux exigences d’entrée de la seconde. A contrario, les commandes Windows PowerShell sont conçues pour traiter des objets, informations structurées allant au-delà de simples chaînes de caractères.

Au lieu de transporter les données sous forme de texte brut, PowerShell le fait sous forme d’objets .NET Framework, ce qui permet aux applets de commande d’accéder directement aux propriétés et aux méthodes d’un objet. Cette évolution simplifie également l’usage du shell, puisque plutôt que de modifier des données textuelles, il est possible de faire référence aux données requises simplement par leur nom, et pour chaque objet voir le type auquel il appartient ainsi que les membres dont il dispose, tout cela depuis l’environnement de commande.

Types de commandes PowerShell

Lorsqu’une commande PowerShell est sollicitée depuis l’interface en ligne de commandes, l’interpréteur en examine le nom afin de définir la tâche à effectuer. Ce processus détermine le type de la commande et la manière de l’exécuter. Il existe quatre types de commandes PowerShell : applets de commande, fonctions shell, scripts et commandes natives.

Les applets de commande, fonctions shell et scripts, dépendants des technologies mises en oeuvre par lui, sont exécutés dans le processus PowerShell (PowerShell.exe). Les commandes natives, des programmes exécutable autonomes, sont exécutés en tant que processus distincts.

Applets de commande

Ressemblant aux commandes natives de divers autres interpréteurs de commandes, telles que les commandes dir et cd de cmd.exe, les applets de commande constituent le type de commande fondamental (fondamental au sens d’intrinsèque) de Windows PowerShell. Les commandes Windows PowerShell intégrées sont appelées commandlets, pour command applets en anglais, abrégées en cmdlets dans l’interface en ligne de commande. On rencontre parfois l’anglicisme commandelettes.

Les cmdlets utilisent un système de dénomination composé à l’aide de paires verbe-substantif, tous deux souvent anglais et toujours séparés par un tiret. Le verbe indique ce que fait la cmdlet en général. Le substantif précise ce avec quoi la cmdlet fonctionne. Par exemple, la cmdlet get-variable récupère toutes les variables de l’environnement PowerShell et retourne leurs valeurs ou récupère une variable d’environnement spécifiquement nommée et retourne ses valeurs. La liste suivante énumére les verbes couramment associés aux cmdlets :

Get Interroge un objet spécifique ou un sous-ensemble d’un type d’objet.

Set Modifie les paramètres spécifiques à un objet.

Enable Active un paramètre.

Disable Désactive un paramètre activé.

New Crée une nouvelle instance d’un élément.

Remove Supprime une instance d’un élément.

Vous pouvez répertorier toutes les commandes qui incluent un verbe particulier au moyen du paramètre -Verb de Get-Command. Par exemple, pour consulter toutes les applets de commande qui utilisent le verbe Get, tapez Get-Command -Verb Get. Vous devriez voir quelque chose comme ce qui suit :

Le paramètre -Noun est plus utile encore, car il vous permet de consulter une famille des commandes affectant un même type d’objet. Par exemple, si vous souhaitez consulter les commandes disponibles pour la gestion des services, tapez Get-Command -Noun Service.

Une commande n’est pas une applet de commande simplement parce que son nom obéit au modèle verbe-substantif. La commande Clear-Host par exemple, laquelle permet d’effacer le contenu de la fenêtre de console, n’est pas une applet de commande, mais en réalité une fonction interne.

Fonctions shell

Le langage de script défini avec avec PowerShell permet l’organisation du code source en unités de travail logiques, nommées fonctions, avec lesquelles découper un problème global en fractions plus simples. Elément fondamental de PowerShell en tant que shell, mais aussi en tant que language, les fonctions sont dans l’écosystème PowerShell considérées comme des commandes à part entière, au même titre que les scripts, cmdlets et les commandes natives Windows. Elles sont en outre des passerelles vers la création de modules.

Une fonction shell permet d’affecter un nom à une liste de commandes. Les fonctions sont comparables aux sous-routines et aux procédures dans d’autres langages de programmation. Un script diffère d’une fonction en cela qu’une nouvelle instance du shell est démarrée pour chaque script alors que les fonctions s’exécutent dans l’instance courante du shell.

Commandes natives

PowerShell permet l’exécution depuis l’interface en ligne de commande des programmes et outils natifs intégrés à Windows. Ce que l’on désigne par le terme de "commandes natives Windows" est constitué de tous les exécutables ou commandes qui ne relèvent pas de l’environnement de PowerShell, comme les cmdlets, et qui ont pour le coup une existence autonome, par exemple Calculatrice (calc.exe), Bloc-notes (notepad.exe), Robocopy (robocopy.exe), et des milliers d’autres.

Fonctionnant hors de toute considération pour PowerShell, les commandes natives sont exécutées comme des processus séparés. Leur exécution est donc plus lente que celles des autres commandes, à cause de la séparation des processus. De plus, le traitement de leurs paramètres est différent selon que l’on se trouve dans un environnement Command Prompt ou PowerShell. Aussi, conséquemment à ces raisons, il est recommandé d’éviter la sollicitation de commandes tierces si l’objectif recherché peut être accompli via seulement PowerShell.

Fonctionnant hors de toute considération pour PowerShell, les commandes natives sont exécutées comme des processus séparés. Puisque l’invocation d’une commande native déclenche la création d’un nouveau processus, elles sont moins efficaces que les autres types. Elles possèdent également leurs propres paramètres pour le traitement des commandes, qui diffèrent généralement selon que l’on se trouve dans un environnement Command Prompt ou PowerShell. Aussi, conséquemment à ces raisons, il est recommandé d’éviter la sollicitation de commandes tierces si l’objectif recherché peut être accompli via seulement PowerShell.

Scripts

Si l’environnement interactif (comprendre l’interprète de commandes)livré avec PowerShell suffit pour lancer quelques commandes occasionnelles, son utilisation devient vite inconfortable s’il s’agit de lancer toute une série de commandes ; le recours à des scripts semble auquel cas plus appropriée. PowerShell considère les scripts comme un type de commandes à part entière. Ils sont constitués d’au moins une commande (ou groupe de commandes) et sont contenus dans un fichier texte, qui doit avoir l’extension .ps1.

Scripts et sécurité

A l’époque de VBScript, à cause surtout de ce dont ce langage profitait en matière d’interactions avec les applications (notamment de messagerie), il était relativement facile de créer des virus performants. (Le lecteur intéressé à ce sujet peut consulter les diverses documentations - techniques ou non - concernant I Love You, un des premiers vers ayant pris une ampleur mondiale, du même coup très célèbre de par son exposition médiatique.) Une fois le code écrit et enregistré dans un fichier idoine (extension .vbs), il suffisait à la victime de double-cliquer sur ce dernier que le code soit exécuté. Aujourd’hui, maintenant que plus d’attention est porté au domaine de la sécurité informatique, si vous essayez de double-cliquer sur un script PowerShell, cette action lancera un éditeur de texte ou de script.

Les scripts peuvent être très simples, mais aussi très complexes avec des paramètres, une documentation intégrée et la possibilité d’être lancés à distance.

Activer le support des scripts

Les paramètres de sécurité implémentés dans PowerShell, communément et collectivement connus comme stratégie d’exécution, désactivent par défaut le support des scripts. Aussi, si vous tentez d’exécuter un script PowerShell sans avoir au préalable modifié la configuration à cet égard, une erreur survient et le script ne s’exécute pas. En l’absence de définition d’une stratégie d’exécution, un message d’erreur s’affiche à l’écran.

Cette position est qualifiée de stratégie d’execution resteinte. En la matière, il s’agit de la stratégie la plus restrictive, au sens où elle bloque systématiquement l’exécution de tout script. Seules les commandes entrées depuis l’invite de commandes PowerShell seront exécutées.

Pour remédier à l’inexécution de script, PowerShell requiert que l’utilisateur change le mode d’exécution avec la commande Set-ExecutionPolicy <mode d’exécution>. Il faut pour ce faire être administrateur de la machine. Dans l’exemple ci-après, nous modifions le niveau autorisation affecté aux scripts pour passer à une stratégie où les scripts locaux sont autorisés :

PS C:\> Set-ExecutionPolicy RemoteSigned

Vous pouvez vérifier que le changement ai bien été pris en compte à l’aide de la commande Get-ExecutionPolicy, laquelle devrait donner lieu à la sortie de commande suivante :

PS C:\> Get-ExecutionPolicy
RemoteSigned
PS C:\>

WER (Windows Error Reporting)

Table 43. Fonctions WER

WerAddExcludedApplication

Exclut une application donnée du processus de rapports d’erreurs

WerGetFlags

Retourne les paramètres de rapports d’erreurs s’appliquant à un processus donné

WerRegisterFile

WerRegisterMemoryBlock

WerRemoveExcludedApplication

WerReportAddDump

WerReportAddFile

WerReportCloseHandle

WerReportCreate

Crée un rapport d’erreurs

WerReportSetParameter

WerReportSetUIOption

WerReportSubmit

WerSetFlags

Définit les paramètres de rapports d’erreurs s’appliquant au processus actuel

WerUnregisterFile

WerUnregisterMemoryBlock

Journaux d’événements

Il existe deux types généraux de fichiers journaux :

  • Journaux Windows Journaux employés par le système d’exploitation pour enregistrer les événements système généraux relatifs aux applications, à la sécurité, à l’installation et aux composants système.

  • Journaux des applications et des services Journaux employés par des applications et des services spécifiques pour enregistrer des événements spécifiques aux applications ou aux services.

Les Journaux Windows sont les suivants :

  • Application Enregistre les événements consignées par les applications. Son emplacement par défaut est \SystemRoot\System32\Winevt\Logs\Application.evtx.

  • Evénements transférés Lorsque la transmission d’événements est configurée (et les abonnements à des fournisseurs d’événements paramétrés en ce sens), ce journal enregistre les événements transmis depuis des ordinateurs distants. Son emplacement par défaut est \SystemRoot\System32\Winevt\Config\ ForwardedEvents.evtx.

  • Installation Enregistre les événements qui résultent de l’instalation de logiciels, donnant des détails sur les tâches d’installation terminées et sur les éventuelles erreurs liées à l’installation. Son emplacement par défaut est \SystemRoot\System32\Winevt\Logs\Setup.evtx.

  • Sécurité Enregistre les événements relatifs à la protection et à la sécurité de la station de travail, tels que les tentatives valides et non valides d’ouverture de session, ainsi que les événements liés à l’utilisation des ressources, comme la création, l’ouverture ou la suppression de fichiers ou d’autres objets. Son emplacement par défaut est \SystemRoot\System32\Winevt\Logs\Security.evtx.

  • Système Contient les événements journalisés par le système d’exploitation ou ses composants, par exemple l’échec du démarrage d’un service à l’amorçage, la mise en veille de l’ordinateur, et bien d’autres. Son emplacement par défaut est \SystemRoot\System32\Winevt\Logs\System.evtx.

Parmi les Journaux des applications et des services, citons :

  • Windows PowerShell Enregistre les activités relatives à l’utilisation de Windows PowerShell. Son emplacement par défaut est \SystemRoot\System32\Winevt\Logs\ Windows PowerShell.evtx.

  • Microsoft\Windows Journaux qui suivent les événements relatifs aux services et fonctionnalités spécifiques à Windows.

  • Microsoft\Windows\Diagnostic-Performance Consigne les événements dont résulte une dégradation des performances, par exemple la surexploitation des ressources mémoire, vidéo, processeur, etc.

Windows intègre deux utilitaires majeurs en ce qui concerne les journaux : l’observateur d’événements et l’outil en ligne de commande wevtutil.

Types d’événements

Les informations contenues dans les journaux d’événements sont classées par rang d’importance, allant de faits mineurs comme la réussite d’une opération dans un programme, à des effets et impacts majeurs pour l’utilisation de Windows (arrêt inopiné de l’ordinateur, dysfonctionnement d’un pilote de périphériques, etc.). Les événements sont en outre organisés selon qu’ils concernent, ou non, la sécurité du système d’exploitation. L’ensemble de ces critères donne lieu à une hiérarchie à cinq niveaux :

  • Critique un événement étiqueté critique rend compte d’un avis négatif sur le fonctionnement global de Windows, ou au moins d’une partie de son écosystème. Par exemple, quand un dispositif matériel génère des erreurs, un événement de type Critique est enregistré, avertissant l’utilisateur que des mesures sont nécessaires.

  • Erreur Une erreur indique un problème important tel qu’une perte de données ou une perte de fonctions à l’échelle du système. Par exemple, si un service n’a pas pu être chargé au démarrage, un événement de type Erreur est enregistré.

  • Avertissement Un avertissement est un événement qui n’est pas nécessairement significatif mais qui peut annoncer des problèmes ultérieurs. Par exemple, lors d’une baisse importante de l’espace disque disponible, un événement de type Avertissement peut être enregistré.

  • Information Un événement d’informations décrit le bon fonctionnement d’un programme, d’un pilote ou d’un service. Par exemple, lorsqu’un pilote est chargé, ou un service démarré correctement, un événement de type Information est enregistré.

  • Audit des succès Indique un événement de sécurité qui a réussi. Par exemple, si l’audit des succès pour les événements d’ouverture de session des comptes est activé, une entrée d’audit est consignée pour chaque utilisateur validé auprès du système.

  • Audit des échecs Événement de sécurité qui a échoué. Par exemple, si un utilisateur tente d’accéder au système sans y parvenir, la tentative est enregistrée en tant qu’événement de type Audit des échecs.

Gestionnaire d’objets

Windows suit une conception orientée objet, et ce faisant réalise une notion fondamentale des sciences de l’informatique, l’abstraction, par laquelle fait force le caractère sémantique des différentes couches du système (rappelez-vous que les services fournis par l’exécutif de Windows peuvent être groupés en catégorie : gestionnaire de processus, gestionnaire d’E/S, gestionnaires de plug-and-play et d’alimentation, etc.). En utilisant un modèle abstrait pour penser l’environnent local, Windows, tant dans sa structure interne que dans les dispositifs visibles au concepteur d’application et pilote tierce partie, rend possible une manipulation aisée (facilitée au moins) des éléments multiples et complexes sous-jacents. Dans ce chapitre, nous allons voir la plastique du modèle objet.

Le chapitre que vous allez découvrir à une place importante, tant dans la structure narrative de ce livre que ce dont il fait son sujet. Il est le premier à user de détails techniques, à rendre compte des fonctions et routines implémentant telle ou telle fonctionnalités ; le premier à démêler l’intrication entre données, attributs, structures de données et services.

Gestionnaire d’objets

Windows est un système d’exploitation à dominante objet et traite comme tel la plupart des ressources de l’environnement informatique. Il met pour ce faire un oeuvre un composant spécialisé, le gestionnaire d’objets, dont les primitives permettent de traiter tout objet (processus, threads, sémaphores, pilotes de périphériques, et bien d’autres) indépendamment de sa signification physique ou technique.

La raison fondamentale et la vocation première premiere du gestionnaire d’objet est de centraliser les opérations de contrôle et de suivi de ressources qui, sans lui, serait éparpillées dans l’ensemble du système d’exploitation.

Sur une vue globale, le gestionnaire d’objets fournit un ensemble générique d’interfaces pour gérer les entités en mode noyau et les manipuler depuis le mode utilisateur. Le dispositif ainsi constitué permet : (1) la distinction des objets ; (2) la recherche d’un objet particulier ; (3) le partage d’un objet entre plusieurs processus.

Outre proposer des méthodes faisant office de tremplin vers les diverses ressources hébergées au sein de l’environnement, le gestionnaire d’objets implémente des opérations telles que la maintenance d’un espace de noms, pour permettre à tout objet de se voir attribuer un nom ; l’application de la sécurité, pour effectuer des contrôles sur les opérations concernant des objets ; ou encore la mémorisation des comptes de référence, qui servent en interne à gérer le cycle de vie de chaque objet.

Le Gestionnaire d’Objets se compose des éléments que voici :

  • Un ensemble de services système de l’exécutif chargés de créer, supprimer, protéger et suivre les objets ; quelques-uns exposés via l’API Windows ou les interfaces mode noyau des pilotes de périphérique.

  • Un ensemble de règles et de services à partir desquelles le noyau, les gestionnaires de l’exécutif et sous-systèmes d’environnement peuvent construire leurs propres versions des objets, ce faisant imaginer d’autres ressources.

  • Un ensemble de primitives génériques, fonctionnelles en différents points du cycle de vie des objets (ouverture, fermeture, interrogation, modification, etc.), qui rendent possible un mécanisme commun uniforme pour l’utilisation des ressources système.

  • Un petit nombre d’interfaces qui font contact avec le sous-système de sécurité pour permettre le contrôle d’accès discrétionnaire et l’audit sur les objets qui doivent être protégés.

  • Un modèle d’espace de noms pour la catégorisation des objets, avec en arrière-plan les objets répertoires d’objets et liens symboliques pour l’organisation de ce lieu (les deux types d’objet appartiennent au gestionnaire d’Objets).

Structure des objets


lkd> dt nt!_OBJECT_HEADER
   +0x000 PointerCount     : Int8B
   +0x008 HandleCount      : Int8B
   +0x008 NextToFree       : Ptr64 Void
   +0x010 Lock             : _EX_PUSH_LOCK
   +0x018 TypeIndex        : UChar
   +0x019 TraceFlags       : UChar
   +0x019 DbgRefTrace      : Pos 0, 1 Bit
   +0x019 DbgTracePermanent : Pos 1, 1 Bit
   +0x01a InfoMask         : UChar
   +0x01b Flags            : UChar
   +0x01b NewObject        : Pos 0, 1 Bit
   +0x01b KernelObject     : Pos 1, 1 Bit
   +0x01b KernelOnlyAccess : Pos 2, 1 Bit
   +0x01b ExclusiveObject  : Pos 3, 1 Bit
   +0x01b PermanentObject  : Pos 4, 1 Bit
   +0x01b DefaultSecurityQuota : Pos 5, 1 Bit
   +0x01b SingleHandleEntry : Pos 6, 1 Bit
   +0x01b DeletedInline    : Pos 7, 1 Bit
   +0x01c Reserved         : Uint4B
   +0x020 ObjectCreateInfo : Ptr64 _OBJECT_CREATE_INFORMATION
   +0x020 QuotaBlockCharged : Ptr64 Void
   +0x028 SecurityDescriptor : Ptr64 Void
   +0x030 Body             : _QUAD
  • Corps d’objet (Body) Données spécifiques à l’objet.

  • Flags Modificateurs facultatifs qui définissent le comportement ou les caractéristiques de l’objet.

  • Compteur de références (HandleCount) Compte le nombre de fois qu’un handle a été ouvert pour l’objet.

  • Lock Encaspule une primitive de verrouillage (type push lock) employée de telle sorte à protéger la structure des accès concurrents.

  • Objet permanent (PermanentObject) Souligne le caractère permanent d’un objet (par opposition à un autre temporaire).

  • Compteur de pointeurs (PointerCount) Compte le nombre de fois qu’un composant mode noyau a référencé l’adresse de l’objet.

  • Quota facturés (QuotaBlockCharged) Énumère les facturations de ressource infligées à un processus quand il ouvre un handle vers l’objet.

  • Descripteur de sécurité (SecurityDescriptor) Détermine qui peut utiliser l’objet et quelles opérations il est possible de réaliser dessus. Voir routines ObGetObjectSecurity et ObReleaseObjectSecurity ; voir attribut OB_FLAG_SECURITY.

Table 44. OBJECT_HEADER InfoMask

Bit

Type

0x01

OBJECT_HEADER_CREATOR_INFO

0x02

OBJECT_HEADER_NAME_INFO

0x04

OBJECT_HEADER_HANDLE_INFO

0x08

OBJECT_HEADER_QUOTA_INFO

0x10

OBJECT_HEADER_PROCESS_INFO

Objets noyau

La tableau qui suit énumère les différents objets qui voient leur existence assurée par l’intermédiaire du noyau Windows.

Table 45. Objets noyau
Type d’objet Symbole (KOBJECTS) Structure

Interruptions APC

ApcObject

KAPC

Appel de procédure différée

DpcObject

KDPC

DPC threadé 

ThreadedDpcObject

Interruption

InterruptObject

KINTERRUPT

Événement (type notification)

EventNotificationObject

KEVENT

Événement (type synchronisation)

EventSynchronizationObject

KEVENT

Evénements appariés

EventPairObject

KEVENT_PAIR

Mutex gardé

KGUARDED_MUTEX

Mutex

MutantObject

KMUTEX, KMUTANT

Processus

ProcessObject

KPROCESS

Profil

ProfileObject

KPROFILE

File

QueueObject

KQUEUE

Sémaphore

SemaphoreObject

KSEMAPHORE

Spin lock

KSPIN_LOCK

Thread

ThreadObject

KTHREAD

Minuterie (type notification)

TimerNotificationObject

KTIMER

Minuterie (type synchronisation)

TimerSynchronizationObject

KTIMER

Bloc d’attente

KWAIT_BLOC

Gate

GateObject

KGATE

L’énumération KOBJECTS dresse une liste effective de tous les objets noyau qui renferment un entête dispatcher.

Objets exécutif

Les objets et services d’objet de l’exécutif sont des primitives que les divers composants de l’exécutif (gestionnaire de processus, gestionnaire de mémoire, sous-système d’E/S, et ainsi de suite) définissent afin de se les approprier au sein des technologies auxquelles ils donnent lieu. Le gestionnaire de processus, par exemple, met en oeuvre les processus, threads, et jobs sous la forme d’objets exécutif idoines.

Les objets et services d’objet de l’exécutif sont des primitives que les divers composants de l’exécutif (gestionnaire de processus, gestionnaire de mémoire, sous-système d’E/S, et ainsi de suite) définissent afin de se les approprier au sein des technologies auxquelles ils donnent lieu. Le gestionnaire de processus, par exemple, met oeuvre les processus, threads, et jobs sous la forme d’objets exécutif idoines.

Une autre clientèle, importante également, des objets exécutif est constituée des sous-système d’environnement, agissant auquel cas le plus souvent pour le compte d’une application utilisateur. Ainsi, pour créer un fichier, une application Windows appelle la fonction CreateFile, implémentée dans la DLL du sous-système Windows et qui sollicite à son tour le service natif NtCreateFile, de sorte à entrainer la création d’un objet exécutif de type fichier.

Une large majorité des ressources exposées au niveau du sous-système Windows correspondent directement à des objets exécutifs (qui s’appuient eux-mêmes sur des objets noyau correspondants), par exemple les processus et les threads. Quelques autres objets, en comparaison, donnent lieu à  plusieurs primitives Windows, par exemple les objets de type fichier, sur lesquelles sont basés les tubes nommés et les mailslots.

La liste qui suit énumère les objets existants parmi la couche exécutive, ainsi que les structures de données associées. Nombre de ces objets sont accessibles en l’état aux API de Windows, tandis que quelques autres servent uniquement aux composants de l’exécutif, et ne sont en l’occurrence pas exportés vers les autres sphères du système d’exploitation. Citons, comme exemples de ces objets, ceux sous-jacents aux périphériques, aux pilotes, ou aux événements à clé.

Table 46. Objets exécutif
Type d’objet Défini par Structure

Boite aux lettres (mailslots)

Gestionnaire d’E/S

FILE_OBJECT

Bureau

Sous-système graphique

Clé de registre

Gestionnaire de configuration

CM_KEY_BODY

Evénements appariés

Exécutif

EEVENT_PAIR

Fenêtre

Sous-système graphique

Fichier

Gestionnaire d’E/S

FILE_OBJECT

Jeton d’accès

Sous-système sécurité

TOKEN

Job

Gestionnaire de processus

EJOB

LPC

Gestionnaire LPC

LPCP_PORT_OBJECT

Lien symbolique

Gestionnaire d’objet

OBJECT_SYMBOLIC_LINK

Minuterie

Exécutif

ETIMER

Processus

Gestionnaire de processus

EPROCESS

Section

Gestionnaire de mémoire

SECTION

Thread

Gestionnaire de processus

ETHREAD

Tube nommé

Gestionnaire d’E/S

FILE_OBJECT

Pilote

Gestionnaire d’E/S

DRIVER_OBJECT

Périphérique

Gestionnaire d’E/S

DEVICE_OBJECT

Etant donné l’étroite proximité entre les sphères hautes et basses du système d’exploitation, il n’est pas rare de voir un objet exécutif encapsuler un ou plusieurs objets noyau. Chaque processus, par exemple, représenté au niveau exécutif par une structure EPROCESS, héberge une sous-structure du type KPROCESS, elle établie sur le plan du noyau.

Objets type

lkd> dt nt!_OBJECT_TYPE
   +0x000 TypeList         : _LIST_ENTRY
   +0x010 Name             : _UNICODE_STRING
   +0x020 DefaultObject    : Ptr64 Void
   +0x028 Index            : UChar
   +0x02c TotalNumberOfObjects : Uint4B
   +0x030 TotalNumberOfHandles : Uint4B
   +0x034 HighWaterNumberOfObjects : Uint4B
   +0x038 HighWaterNumberOfHandles : Uint4B
   +0x040 TypeInfo         : _OBJECT_TYPE_INITIALIZER
   +0x0b8 TypeLock         : _EX_PUSH_LOCK
   +0x0c0 Key              : Uint4B
   +0x0c8 CallbackList     : _LIST_ENTRY
  • Balise de pool (Key) Séquence de quatre octets donnée à l’allocation. Voir routine ObCreateObjectType.

  • Nom du type (Name) Noms des objets de ce type. Voir routine ObCreateObjectType (attribut TypeName).

  • Nombre total des objets (TotalNumberOfObjects) Nombre total des objects actifs de ce type.

  • Nombre total des handles (TotalNumberOfHandles) Nombre total des handles actifs ouverts pour objets de ce type.

  • TypeLock Verrou global posé sur les objets de ce type lors des opérations qui le nécessitent.

lkd> dt nt!_OBJECT_TYPE_INITIALIZER
   +0x000 Length           : Uint2B
   +0x002 ObjectTypeFlags  : UChar
   +0x002 CaseInsensitive  : Pos 0, 1 Bit
   +0x002 UnnamedObjectsOnly : Pos 1, 1 Bit
   +0x002 UseDefaultObject : Pos 2, 1 Bit
   +0x002 SecurityRequired : Pos 3, 1 Bit
   +0x002 MaintainHandleCount : Pos 4, 1 Bit
   +0x002 MaintainTypeList : Pos 5, 1 Bit
   +0x002 SupportsObjectCallbacks : Pos 6, 1 Bit
   +0x002 CacheAligned     : Pos 7, 1 Bit
   +0x003 ObjectTypeFlags2 : UChar
   +0x003 UseExtendedParameters : Pos 0, 1 Bit
   +0x003 Reserved         : Pos 1, 7 Bits
   +0x004 ObjectTypeCode   : Uint4B
   +0x008 InvalidAttributes : Uint4B
   +0x00c GenericMapping   : _GENERIC_MAPPING
   +0x01c ValidAccessMask  : Uint4B
   +0x020 RetainAccess     : Uint4B
   +0x024 PoolType         : _POOL_TYPE
   +0x028 DefaultPagedPoolCharge : Uint4B
   +0x02c DefaultNonPagedPoolCharge : Uint4B
   +0x030 DumpProcedure    : Ptr64     void
   +0x038 OpenProcedure    : Ptr64     long
   +0x040 CloseProcedure   : Ptr64     void
   +0x048 DeleteProcedure  : Ptr64     void
   +0x050 ParseProcedure   : Ptr64     long
   +0x050 ParseProcedureEx : Ptr64     long
   +0x058 SecurityProcedure : Ptr64     long
   +0x060 QueryNameProcedure : Ptr64     long
   +0x068 OkayToCloseProcedure : Ptr64     unsigned char
   +0x070 WaitObjectFlagMask : Uint4B
   +0x074 WaitObjectFlagOffset : Uint2B
   +0x076 WaitObjectPointerOffset : Uint2B
  • Sensibilité à la casse (CaseInsensitive) Détermine si les procédures de résolution de nom que le gestionnaire d’objets effectue pour ce type sont faites de manière sensible à la casse. Voir routine ObInitSystem ; variable noyau ObpCaseInsensitive.

  • DefaultPagedPoolCharge Mesure ce que représente le coût de chaque allocation d’un objet de ce type.

  • InvalidAttributes Indique quels attributs ne sont pas valables au regard de la nature des objets de ce type.

  • Mappage générique des droits d’accès (GenericMapping) Mappage entre les quatre droits d’accès génériques (lire, écrire, exécuter, tout) et les droits d’accès spécifiques au type.

  • Taille (Length) Contient la taille en octets de la structure OBJECT_TYPE_INITIALIZER.

  • Service d’ouverture (OpenProcedure) Pointeur vers une routine que le gestionnaire d’objet exécute chaque fois qu’il crée un handle pour des objets de ce type.

  • PoolType Détermine à partir duquel des pools généraux (pool paginé ou non paginé) sont effectuées les allocations pour des objets de ce type.

  • ValidAccessMask Indique quels droits d’accès sont valides dans la perspective des objets de ce type.

Table 47. Routines concernant les Objets type

Routine

Description

ObCreateObjectType

Crée un nouveau type d’objet

Le tableau suivant dresse une liste des types d’objet.

Table 48. Types d’objet
Symbole Nom Balise Stucture

AlpcPortObjectType

"ALPC Port"

ALPC_PORT

CmpKeyObjectType

"Key"

"Key "

DbgkDebugObjectType

"DebugObject"

DEBUG_OBJECT

EtwpRegistrationObjectType

ExCallbackObjectType

"Callback"

"Call"

CALLBACK_OBJECT

ExDesktopObjectType

"Desktop"

"Desk"

ExEventObjectType

"Event"

"Even"

EEVENT

ExEventPairObjectType

"EventPair"

"Even"

KEVENT_PAIR

ExMutantObjectType

"Mutant"

"Muta"

KMUTANT

ExProfileObjectType

"Profile"

"Prof"

KPROFILE

ExSemaphoreObjectType

"Semaphore"

"Sema"

KSEMAPHORE

ExTimerObjectType

"Timer"

"Time"

KTIMER

ExWindowStationObjectType

"WindowStation"

"Wind"

ExpKeyedEventObjectType

"KeyedEvent"

KEYED_EVENT_OBJECT

ExpWorkerFactoryObjectType

IoAdapterObjectType

"Adapter"

"Adap"

ADAPTER_OBJECT

IoCompletionObjectType

"IoCompletion"

"IoCo"

IO_COMPLETION

IoControllerObjectType

"Controller"

"Cont"

CONTROLLER_OBJECT

IoDeviceHandlerObjectType

IoDeviceObjectType

"Device"

"Devi"

DEVICE_OBJECT

IoDriverObjectType

"Driver"

"Driv"

DRIVER_OBJECT

IoFileObjectType

"File"

"File"

FILE_OBJECT

LpcPortObjectType

"Port"

"Port"

LpcWaitablePortObjectType

"WaitablePort"

"Wait"

ObpDirectoryObjectType

"Directory"

"Dire"

OBJECT_DIRECTORY

ObpSymbolicLinkObjectType

"SymbolicLink"

"Symb"

ObpTypeObjectType

"Type"

"ObjT"

OBJECT_TYPE

PopPowerRequestObjectType

PsJobType

"Job"

"Job "

EJOB

PsProcessType

"Process"

"Proc"

EPROCESS

PsThreadType

"Thread"

"Thre"

ETHREAD

SeTokenObjectType

"Token"

"Toke"

TOKEN

TmEnlistmentObjectType

KENLISTMENT

TmResourceManagerObjectType

KRESOURCEMANAGER

TmTransactionObjectType

KTM

MmSectionObjectType

"Section"

"Sect"

SECTION

WmipGuidObjectType

"WmiGuid"

"WmiG"

GUID

Vous pouvez consulter la liste des objets type déclarés au gestionnaire d’objets au moyen de la commande !object du débogueur noyau.

lkd> !object \ObjectTypes
Object: ffffe78a17a15c50  Type: (ffff910a1d482570) Directory
    ObjectHeader: ffffe78a17a15c20 (new version)
    HandleCount: 0  PointerCount: 66
    Directory Object: ffffe78a17a18ea0  Name: ObjectTypes

    Hash Address          Type                      Name
    ---- -------          ----                      ----
     00  ffff910a1d516f20 Type                      TmTm
     01  ffff910a1d47abe0 Type                      Desktop
         ffff910a1d48d4b0 Type                      Process
     02  ffff910a1d595a80 Type                      EnergyTracker
         ffff910a1d517330 Type                      RegistryTransaction
     03  ffff910a1d47a1e0 Type                      DebugObject
     04  ffff910a1e6e0080 Type                      VRegConfigurationContext
         ffff910a1da34080 Type                      DmaDomain
         ffff910a1d478b80 Type                      TpWorkerFactory
     05  ffff910a1d47c4f0 Type                      Adapter
         ffff910a1d482080 Type                      Token
     06  ffff910a1e6342e0 Type                      DxgkSharedResource
     07  ffff910a1d494dc0 Type                      PsSiloContextPaged
     08  ffff910a1e561d20 Type                      NdisCmState
         ffff910a1d494f20 Type                      ActivityReference
     09  ffff910a1e3378c0 Type                      PcwObject
         ffff910a1d5a7320 Type                      WmiGuid
     11  ffff910a1d464460 Type                      DmaAdapter
         ffff910a1d5a6dc0 Type                      EtwRegistration
     12  ffff910a1d9d9f20 Type                      DxgkSharedBundleObject
         ffff910a1d51ddc0 Type                      Session
         ffff910a1d478e40 Type                      RawInputManager
         ffff910a1d479470 Type                      Timer
     13  ffff910a1d476c80 Type                      Mutant
     14  ffff910a1d48db80 Type                      IRTimer
     16  ffff910a1d9d8b00 Type                      DxgkCurrentDxgProcessObject
         ffff910a1d47ed50 Type                      IoCompletion
     17  ffff910a1d9d89a0 Type                      DxgkSharedProtectedSessionObject
         ffff910a1d9d8f20 Type                      DxgkSharedSyncObject
         ffff910a1d46d390 Type                      WindowStation
         ffff910a1d48da20 Type                      Profile
     18  ffff910a1d50ef20 Type                      File
     20  ffff910a1d48d080 Type                      Partition
     21  ffff910a1d4795d0 Type                      Semaphore
     22  ffff910a1d47a080 Type                      PsSiloContextNonPaged
     23  ffff910a1d5a6b00 Type                      EtwConsumer
         ffff910a1d47aa80 Type                      Composition
     24  ffff910a1d5a6c60 Type                      EtwSessionDemuxEntry
         ffff910a1d478ce0 Type                      CoreMessaging
     25  ffff910a1d516dc0 Type                      TmTx
         ffff910a1d469f20 Type                      SymbolicLink
     26  ffff910a1e428210 Type                      FilterConnectionPort
         ffff910a1d517490 Type                      Key
         ffff910a1d46d4f0 Type                      KeyedEvent
         ffff910a1d482a00 Type                      Callback
     27  ffff910a1d47ebf0 Type                      WaitCompletionPacket
     28  ffff910a1d46a8f0 Type                      UserApcReserve
         ffff910a1d46f9c0 Type                      Job
     29  ffff910a1d9d8c60 Type                      DxgkDisplayManagerObject
         ffff910a1d9d8dc0 Type                      DxgkSharedSwapChainObject
         ffff910a1d47c390 Type                      Controller
         ffff910a1d46a790 Type                      IoCompletionReserve
     30  ffff910a1d47c230 Type                      Device
         ffff910a1d482570 Type                      Directory
     31  ffff910a1d51df20 Type                      Section
         ffff910a1d516b00 Type                      TmEn
         ffff910a1d48dce0 Type                      Thread
     32  ffff910a1d47f600 Type                      Type
     33  ffff910a1e429f20 Type                      FilterCommunicationPort
         ffff910a1d594b50 Type                      PowerRequest
     35  ffff910a1d516c60 Type                      TmRm
         ffff910a1d46ea30 Type                      Event
     36  ffff910a1d596b40 Type                      ALPC Port
         ffff910a1d47eeb0 Type                      Driver

Méthodes d’objet

Les objets sont pour ce qui concerne leur manipulation traités par l’intermédiaire d’un ensemble de services génériques, communément appelées méthodes, que le gestionnaire d’objets anime en quelques occasions ciblées, habituellement quand il y a création, suppression ou modification d’un objet.

Quand un composant de l’exécutif donne lieu à un type d’objet, il peut déclarer des méthodes auprès du gestionnaire d’objets. Certains types d’objet spécifient l’ensemble des implémentations potentielles (comprendre que toutes les adresses des fonctions virtuelles sont renseignées), et d’autres seulement une partie, selon que telle ou telle opération ai un sens dans le contexte.

Le tableau suivant dresse la liste des méthodes prises en charge par le gestionnaire d’objets.

Table 49. Méthodes d’objet
Méthode Moment de l’appel

Open

Quand le gestionnaire d’objets crée un handle d’objet

Close

Quand le gestionnaire d’objets ferme un handle d’objet

Delete

Quand le gestionnaire d’objets supprime un objet

Query Name

Quand un thread demande le nom d’un objet qui existe dans un espace de noms d’objets secondaires

Parse

Quand le gestionnaire d’objets recherche un nom d’objet qui existe dans un espace de noms d’objets secondaires

Security

Quand un processus lit ou modifie la protection d’un objet qui existe dans un espace de noms d’objets secondaires

Le gestionnaire d’objet appelle la méthode open chaque fois qu’il crée un handle pour un objet, ce qu’il fait lors de la création ou de l’ouverture d’un objet. Les objets du type processus, threads, fichiers, et quelques autres, montrent un exemple d’utilisation de méthode open.

Lorsque le handle associé à un objet est refermé, la procédure close correspondant à l’objet est appelée. Par exemple, le gestionnaire d’E/S déclare une méthode close pour le type d’objet fichier, et le gestionnaire d’objets sollicite ladite procédure chaque fois qu’il ferme un handle d’objet fichier. En règle générale, cette démarche donne le départ à un certain nombre d’opérations de nettoyage dont l’exécution entraine la suppression de tout état spécifique à l’utilisation de l’objet par l’appelant, y compris les verrous en instance et les restrictions de partage. Le gestionnaire d’objets n’ayant pas de visibilité sur la façon dont un processus emploie tel ou tel objet, il ne peut dès lors procéder lui-même à de tels travaux.

Le gestionnaire d’objets appelle une méthode delete, s’il y en a une de déclarée, avant de supprimer un objet temporaire en mémoire, créant de cette manière l’occasion (du reste, la dernière) de libérer les ressources qui ne l’ont pas été jusqu’à présent, par exemple les structures de données internes indispensables au cycle de vie de l’objet. Si l’on considère une nouvelle fois les objets fichiers comme exemple, le gestionnaire d’E/S déclare pour le type d’objet fichier une méthode delete dont l’appel entraine l’envoi d’une notification à l’objet périphérique représentant le système de système de fichiers. Le gestionnaire de mémoire, autre exemple, met en oeuvre pour le type d’objet section une méthode delete qui libère les pages physiques assignées à la section. Là encore, le gestionnaire d’objets ne peut mener à bien ce travail sans un partenaire spécialisé. Les méthodes delete des autres types d’objets remplissent des fonctions semblables. Lorsque la procédure delete d’un objet temporaire se termine, l’objet disparait tout à fait.

Les opérations qui relèvent de la méthode parse ont lieu quand le gestionnaire d’objets recherche un objet qui existe dans un espace de noms secondaire. Quand le gestionnaire d’objets recherche un nom d’objet, il interrompt sa recherche quand il rencontre un objet du chemin qui a une méthode parse associée. Le gestionnaire d’objets appelle la méthode parse en lui passant le reste du nom de l’objet qu’il cherche à retrouver. Il existe deux espaces de noms dans Windows, en plus de celui du gestionnaire d’objets : l’espace de noms du registre, implémenté par le gestionnaire de configuration, et l’espace de noms du système de fichiers, que le gestionnaire d’E/S met en oeuvre avec l’aide des pilotes de système de fichiers.

La méthode query name est employée quand quand le gestionnaire d’objets recherche un nom d’objet existant dans un espace de noms secondaire.

Employée comme niveau supplémentaire de protection contre l’usage indu (ou incorrect) des compteurs que le gestionnaire d’objet maintient pour chaque objet, la méthode okay to close vient s’ajouter aux contrôles habituels effectués au préalable du démantèlement des ressources, et est l’occurrence mise en oeuvre chaque fois que la suppression d’une référence au compteur de références d’un objet serait susceptible d´entrer en conflit avec une stratégie système. La partie mode noyau du sous-système Windows (Win32k.sys) déclare par exemple une méthode okay to close pour les objets de type bureau et station-fenêtre, de sorte qu’aucun thread ayant des fenêtres visibles ne soit orphelin à ce niveau.

Vous pouvez observer à l’intérieur du débogueur noyau quelles fonctions virtuelles sont définies pour quel type d’objet. Commencez par repérer un type d’objet, ici par exemple le type objet Processus.

lkd> dt nt!_OBJECT_TYPE poi(nt!ObTypeIndexTable + 7 * @$ptrsize)
   +0x000 TypeList         : _LIST_ENTRY [ 0xfffffa80`0245db70 - 0xfffffa80`0245db70 ]
   +0x010 Name             : _UNICODE_STRING "Process"
   . . .
   +0x040 TypeInfo         : _OBJECT_TYPE_INITIALIZER

lkd> dt nt!_OBJECT_TYPE Name TypeInfo. poi(nt!ObTypeIndexTable + 7 * @$ptrsize)
   +0x010 Name      : _UNICODE_STRING "Process"
   +0x040 TypeInfo  :
      +0x000 Length    : 0x78
      . . .
      +0x030 DumpProcedure : (null)
      +0x038 OpenProcedure : 0xfffff802`79ff6320        long  nt!PspProcessOpen+0
      +0x040 CloseProcedure : 0xfffff802`7a01438c        void  nt!PspProcessClose+0
      +0x048 DeleteProcedure : 0xfffff802`7a02e780        void  nt!PspProcessDelete+0
      +0x050 ParseProcedure : (null)
      +0x058 SecurityProcedure : 0xfffff802`7a07c880        long  nt!SeDefaultObjectMethod+0
      +0x060 QueryNameProcedure : (null)
      +0x068 OkayToCloseProcedure : (null)

Noms des objets

Tous les systèmes d’exploitation offrent la possibilité de nommer certaines des ressources vers lesquelles ils fournissent un tremplin. Si l’on pense à cet égard instinctivement aux fichiers et aux répertoires, il faut aussi considérer les disques, les volumes, les tubes, les blocs de mémoire partagée, et quelques autres. L’exécutif Windows, en comparaison, permet de donner un nom à toute ressource représentée par un objet. Les noms d’objet permettent de répondre à plusieurs exigences fondamentales concernant la localisation et l’accès aux objets, mais aussi le partage d’objets entre processus.

Les noms d’objets permettent aux processus de se partager des objets. L’espace de noms des objets de l’exécutif est visible à tous les processus du système. Un processus peut dès lors créer un objet en lui conférant un nom et un autre processus ouvrir un handle vers l’objet en spécifiant le nom de l’objet. Un objet, s’il n’est pas censé être partagé (du moins pas de cette manière), peut ne pas avoir de nom.

Résoudre un nom peut sur le plan des performances s’avérer une procédure coûteuse, si ce n’est en temps en nombre d’opérations. De ce fait, pour plus d’efficacité, le gestionnaire d’objets ne recherche pas le nom d’un objet chaque fois qu’un composant utilise l’objet. En réalité, le gestionnaire d’objets ne recherche des noms que dans deux cas : création d’un objet nommé et création d’un handle vers un objet nommé. Quand un processus crée un objet nommé, le gestionnaire d’objets recherche le nom pour vérifier qu’il n’existe pas déjà et, le cas échéant, stocke le nouveau nom dans l’espace de noms global. Quand un processus ouvre un handle vers un objet nommé, le gestionnaire d’objets recherche le nom, trouve l’objet, puis retourne un handle à l’appelant. Toutes les opérations subséquentes sont réalisées à l’aide du handle.

Quand il recherche un nom, le gestionnaire d’objets permet à l’appelant de choisir entre recherche tenant compte de la casse et recherche ne tenant pas compte de la casse. Cette fonctionnalité assure la compatibilité avec POSIX et autres environnements sensibles sur ces aspects.

Où sont stockés les noms des objets dans l’espace de noms dépend du type auquel appartient l’objet. Le tableau suivant énumère les répertoires d’objets standard de Windows, en indiquant les types d’objets dont les noms sont enregistrées dans ces répértoires.

Table 50. Répertoires d’objets standard

\GLOBAL??

Liens symboliques vers les noms internes des périphériques sous Windows, y compris les lettres de lecteurs définies globalement et les noms de périphériques MS-DOS, tels que CON, PRN, AUX et NUL.

\Callback

Objets callback.

\Device

Objets périphérique.

\Driver

Objets pilote.

\FileSystem

Objets pilote de système de fichiers et objets périphérique reconnaisseur de système de fichier (file system recognizer)

\RPC Control

Objets port (ALPC) employés lors des mécanismes RPC.

\KnownDLLs et \KnownDLLs32

Noms de section et chemin pour les DLL connues (DLL chargées par le système au démarrage). \KnownDLLs32 existe uniquement sur les versions 64 bits de Windows et énumère les versions 32 bits des DLLs connues.

\Nls

Noms de section pour les tables mappées de support de langue nationale (NLS).

\ObjectTypes

Noms des types d’objets.

\Security

Objets spécifiques au sous-système de sécurité.

\Sessions

Données privées des différentes sessions maintenues sur la station de travail.

Les objets noyau de base, tels les événements, sémaphores, mutex, minuteries attendables (waitable timers) et sections, ont leurs noms enregistrés dans un même répertoire d’objets, en conséquence de quoi deux objets ne peuvent pas avoir le même nom même s’ils ne sont pas du même type. Cet aspect restrictif implique de bien penser les noms, de façon qu’ils n’entrent pas en collision les uns avec les autres.

Table 51. Routines connexes aux noms d’objet

Routine

Description

ObOpenObjectByName

Ouvre par le nom un objet.

ObQueryNameString

Retourne s’il en est pourvu le nom d’un objet.

ObReferenceObjectByName

Référence par le nom un objet.

Objets de base nommés

Voici quelques exemples d’objets de base nommés :

  • DBWinMutex Contrôle l’exclusion mutuelle des opérations liées à la sortie de débogage.

  • SC_AutoStartComplete Objet événement utilisé par le SCM de sorte à indiquer quand il a fini de démarrer tous les services et pilotes automatiques.

WinObj

L’utilitaire WinObj permet l’exploration de l’espace de noms interne du gestionnaire d’objets. Que vous soyez un administrateur scrupuleusement attentif du fonctionnement de ses systèmes, un concepteur de logiciel en prise avec des problèmes liés aux objets, ou un utilisateur simplement préoccupé de mieux connaitre les diverses ressources physiques et logiques gérées par Windows, WinObj se révèlera sans nul doute un outil particulièrement efficace, utilisable qui plus est à de nombreuses fins. Il est disponible gratuitement sur le site Microsoft TechNet.

Sur le plan fonctionnel, WinObj repose sur l’emploi d’un petit nombre de services appelables depuis le mode utilisateur, dont NtQuerySystemInformation. Il n’existe autrement dit pas de pilote tiers associé à l’application, laquelle s’exécute en l’occurrence comme n’importe quel autre logiciel prévu pour Windows.

WinObj procure une vue graphique sur la structure générale où sont rangés les objets Windows, elle-même organisée à la façon d’un système de fichiers. Lors du démarrage de l’application, celle-ci commence par ouvrir une fenêtre qui dévoile le niveau racine et les entrées de premier niveau de l’espace de noms du gestionnaire d’objets. Lorsque vous sélectionnez un répertoire dans le volet gauche, le volet de droite répertorie les objets contenus dans ce répertoire. Lorsque vous sélectionnez un répertoire dans volet de gauche ou un objet dans le volet de droite, la barre d’état indique le chemin complet de l’élément. Vous pouvez actualiser l’affichage à tout moment en appuyant sur F5.

Pour voir plus d’informations sur un répertoire ou un objet en particulier, effectuez un clic droit et choisissez Propriétés. Double-cliquer sur un objet permet également de faire apparaitre la boite de dialogue des attributs le concernant, sauf s’il s’agit d’un lien symbolique : le double-clic sur un lien déclenche la navigation vers la cible de celui-ci.

L’onglet Détails de la boîte de dialogue Propriétés affiche pour tout objet les attributs que voici.

  • Le nom de l’objet et le type auquel il appartient.

  • Si l’objet a un caractère permanent.

  • Compteur de références et compteur de handles

  • Quota facturés

La partie inférieure de la fenêtre énumère des valeurs pour des caractéristiques qui sont spécifiques à la nature de l’objet. Dans le cas d’un lien symbolique, par exemple, WinObj affiche des informations temporelles associées à la création de l’objet, de même bien entendu que les données de chemin auxquelles ledit lien fait référence. Si l’objet en question est de type événement, les données incluent la fonction de réinitialisation (automatique ou manuelle) et l’état (signalé ou non) de l’objet. En définitive, les informations présentées à ce niveau dépendent du contexte, et changent selon quelle place a un objet dans le système d’exploitation.

L’onglet Sécurité de la boîte de dialogue Propriétés liste les paramètres d’autorisation concernant un objet. Notez à cet égard que les autorisations en vigueur sur un objet peuvent empêcher l’affichage ou la modification de ses propriétés.

Afin d’aider les utilisateurs à mieux se repérer parmi toutes les informations de l’espace de noms, WinObj fait usage d’une signalétique où les icônes servent à mettre en évidence le type de n’importe quel objet.

  • Les mutex sont dotés d’une icône qui ressemble à un cadenas.

  • Les sections (objets mappage de fichier) sont dotées d’une puce mémoire.

  • Les sémaphores sont munis d’une icône qui ressemble à des feux de signalisation.

  • Les événements sont dotés d’un point d’exclamation à l’intérieur d’un triangle jaune.

  • Les événements à clé ont la même icône que des événements standards, avec le dessin d’une clé en superposition.

  • Les liens symboliques sont indiqués par une flèche incurvée.

  • Les minuteries sont symbolisées par une horloge.

  • Les stations fenêtre sont représentés par un moniteur d’ordinateur.

  • Les pilotes sont représentés par une icône en forme d’engrenage. La même illustration est par ailleurs utilisée dans d’autres contextes, par exemple les objets de type port LPC ou groupes de processus (jobs).

Objet lien symbolique

Les objets lien symbolique implémentés par le gestionnaire d’objets de Windows servent à organiser l’espace de noms. Ils sont également utilisés pour associer un nom standard MS-DOS (a :, c :, etc.) aux lecteurs, ainsi que pour assurer la visibilité des périphériques aux applications (qui ne connaissent pas les noms internes des périphériques).

Un lien symbolique peut figurer n’importe où dans une chaîne de noms d’objet, charge au Gestionnaire d’Objets de le résoudre, et transformer auquel cas un nom abstrait en un autre nom, plus proche des racines du système. Quand un processus fait référence au nom d’un objet lien symbolique, le Gestionnaire d’Objets parcourt son espace de noms jusqu’à rencontrer (s’il s’y trouve) l’objet en question. Il se met alors en quête de la cible associée (représentée par le champ nommé LinkTarget dans la structure OB-JECT_SYMBOLIC_LINK) et trouve une chaîne qu’il substitue au nom du lien symbolique. Après quoi il reprend sa recherche de nom, finalisée qu’au moment où toutes les références concernant des objets lien symbolique auront été résolues.

Tous les utilisateurs de Windows, sans le savoir peut-être, emploient des liens symboliques, habitués d’un certain style pour la désignation des lecteurs et autres périphériques (A:, B:, C:, etc. dans les volumes disque, COM1, COM2, etc. dans les ports série, etc.). En interne de ces associations se trouve le Gestionnaire d’Objets, chargé de la traduction des noms de périphérique tels qu’exprimés en standard MS-DOS vers leurs pendants dans l’espace de noms.

D’ordinaire, un lien symbolique est un objet du système de fichiers qui pointe vers un autre objet du système de fichiers. L’objet pointé est appelé la cible. Dans Windows, cette définition est à nuancer, puisque l’espace de noms est abstrait, et aussi parce que le Gestionnaire d’Objets est conçu pour faire peu de cas de la structure interne du système de fichiers. A l’inverse d’UNIX, qui enracine l’espace de noms système dans le système de fichiers, Windows emploie un espace de noms abstraits, et y connecte les systèmes de fichiers comme des périphériques.

Compte tenu des dangers que serait susceptible d’entraîner une mauvaise utilisation des liens symboliques, la création de tels objets est sévèrement controlé, et nécessite en l’occurence impérativement le privilège SeCreateSymbolicLink, attribué uniquement aux administrateurs. Le système de fichiers intègre en plus de cela une option appelée SymLinkEvaluation qui peut être configurée par l’intermédiaire de la commande fsutil.

Table 52. Services concernant les liens symboliques

Service

Description

NtCreateSymbolicLinkObject

Crée, ou éventuellement ouvre, un objet lien symbolique.

NtOpenSymbolicLinkObject

Ouvre un objet lien symbolique.

NtQuerySymbolicLinkObject

Retourne la cible d’un lien symbolique.

Table 53. Routines concernant les liens symboliques

Routine

Description

ObpCreateSymbolicLinkName

-

ObpDeleteSymbolicLink

-

ObpDeleteSymbolicLinkName

-

ObpParseSymbolicLink

-

ObpProcessDosDeviceSymbolicLink

-

OBJECT_SYMBOLIC_LINK
lkd> dt nt!_OBJECT_SYMBOLIC_LINK
   +0x000 CreationTime     : _LARGE_INTEGER
   +0x008 LinkTarget       : _UNICODE_STRING
   +0x008 Callback         : Ptr64     long
   +0x010 CallbackContext  : Ptr64 Void
   +0x018 DosDeviceDriveIndex : Uint4B
   +0x01c Flags            : Uint4B
   +0x020 AccessMask       : Uint4B
Heure de création de liens symbolique

Le service NtCreateSymbolicLink, à l’issue des opérations qui lui sont confiées, horodate automatiquement tout objet auquel il est parvenu à donner lieu. Les informations recueillies à cet égard le sont en interne par le biais d’un appel à la routine KeQuerySystemTime, et après quoi rendus visibles au moyen du champ CreationTime de la structure OBJECT_SYMBOLIC_LINK. Pour voir à quelle date et quelle heure un lien symbolique a été créé, tapez dt nt!_OBJECT_SYMBOLIC_LINK CreationTime dans le débogueur noyau, suivi de l’adresse d’un quelconque objet de ce type.

lkd> !object \DosDevices
Object: ffffba8a22215640  Type: (ffff930b8ba69f20) SymbolicLink
    ObjectHeader: ffffba8a22215610 (new version)
    HandleCount: 0  PointerCount: 1
    Directory Object: ffffba8a22218de0  Name: DosDevices
    Flags: 00000000 ( Local )
    Target String is '\??'

lkd> dt nt!_OBJECT_SYMBOLIC_LINK CreationTime ffffba8a22215640
   +0x000 CreationTime : _LARGE_INTEGER 0x01d3be56`629f8d63

lkd> .formats 0x01d3be56`629f8d63
Evaluate expression:
  Hex:     01d3be56`629f8d63
  Decimal: 131658092354964835
  Octal:   0007235745314247706543
  Binary:  00000001 11010011 10111110 01010110 01100010 10011111 10001101 01100011
  Chars:   ...Vb..c
  Time:    Sun Mar 18 02:13:55.496 2018 (UTC + 1:00)
  Float:   low 1.47161e+021 high 7.77823e-038
  Double:  7.37036e-300

Répertoires d’objet

L’objet répertoire d’objets est le moyen par lequel le Gestionnaire d’Objets organise l’espace de noms, et agence avec lui une structure de noms hiérarchique analogue à celles de systèmes de fichiers. L’objet contient les noms d’autres objets, voire d’autres répertoires d’objets, qui mis en cascade permettent de structurer les noms d’objet tels des chemins d’accès MS-DOS.

Les composants de l’exécutif, pilotes de périphériques et les sous-systèmes font s’accroître l’espace de noms des objets. Par exemple, le gestionnaire d’E/S crée un répertoire d’objets nommé Device qui contient les noms des objets créés par les pilotes pour représenter les périphériques d’E/S. Ce qui suit énumère les répertoires d’objets de niveau supérieur susceptibles d’être utilisé par les pilotes, les autres étant normalement réservé au système d’exploitation :

  • \Callbacks

  • \Device

  • \KernelObjects

  • \DosDevices

Table 54. Services connexes aux répertoires d’objets

Service

Description

NtCreateDirectoryObject

Crée un répertoire d’objets.

NtQueryDirectoryObject

Retourne des informations concernant un répertoire d’objets donné.

NtOpenDirectoryObject

Crée, ou éventuellement ouvre, un répertoire d’objets.

OBJECT_DIRECTORY
lkd> dt nt!_OBJECT_DIRECTORY
   +0x000 HashBuckets      : [37] Ptr64 _OBJECT_DIRECTORY_ENTRY
   +0x128 Lock             : _EX_PUSH_LOCK
   +0x130 DeviceMap        : Ptr64 _DEVICE_MAP
   +0x138 ShadowDirectory  : Ptr64 _OBJECT_DIRECTORY
   +0x140 NamespaceEntry   : Ptr64 Void
   +0x148 SessionObject    : Ptr64 Void
   +0x150 Flags            : Uint4B
   +0x154 SessionId        : Uint4B

Objets temporaires et objets permanents

Le gestionnaire d’objets de Windows donne lieu à deux sortes d’objet : ceux qui sont temporaires et ceux qui sont permanents. La plupart des objets sont temporaires, et disparaissent par conséquent quand plus aucun thread ne les utilise. Lorsque la procédure delete d’un objet temporaire se termine, le compteur de référence de l’objet chute à la valeur nulle (zéro), moment pour le Gestionnaire de supprimer l’objet de la mémoire. Un objet temporaire peut être rendu permanent en demandant au Gestionnaire d’Objets de compter une référence supplémentaire sur l’objet. Les objets permanents ne sont donc pas supprimés lorsque la dernière référence hors du Gestionnaire d’Objets est supprimée.

Le fait qu’un objet soit temporaire ou permanent est mutuellement exclusif : un objet est temporaire s’il n’est pas permanent (s’il n’a pas été marqué comme tel). Lorsqu’un objet permanent est rendu temporaire de nouveau, le Gestionnaire d’Objets supprime la référence supplémentaire, signe que plus aucun processus n’estime l’objet nécessaire, en conséquence de quoi il faille le démanteler. Les objets permanents sont rares, principalement utilisés pour les périphériques, les objets répertoires et liens symboliques.

Le service natif NtMakeTemporaryObject et la routine ObMakeTemporaryObject modifient les attributs d’un objet afin de le rendre temporaire.

Le tableau suivant répertorie les caractéristiques se rapportant au caractère temporaire ou permanent d’un objet.

Elément Lieu Type Autres références

PermanentObject

OBJECT_HEADER

-

ObMakeTemporaryObject, OB_FLAG_PERMANENT_OBJECT

Partage d’objets entre processus

Windows offre trois méthode de partage des objets entre processus. La première consiste pour un processus à hériter d’un handle d’objet, lequel fait éventuellement partie des caractéristiques que se transmettent les processus d’une même lignée (processus père/fils). Quand un processus fait appel à la fonction CreateXxx, il le fait en indiquant au système (plus précisément, au gestionnaire d’objets) quelles sont les règles à adopter en la matière, à quoi correspond une structure SECURITIES_ATTRIBUTES, dont le champ bInheritHandle indique s’il est à TRUE que le handle est héritable. Un processus peut alors en créer un autre en donnant la valeur TRUE au paramètre bInheritHandle de la fonction CreateProcess.

Une autre manière de partager des objets est de donner un nom à l’objet lors de sa création, ce qui entraine de le rendre visible au sein de l’espace de noms global. L’avantage des objets nommés est que des processus sans aucun lien peuvent aisément se les partager. Dans ce scénario, le premier processus à animer un objet (CreateXxx) le fait en spécifiant lors de l’appel un nom dans le paramètre lpszName. Un autre processus a par la suite la possibilité d’obtenir une référence à cet objet en appelant la fonction OpenXxx (éventuellement CreateXxx) avec le même nom.

La troisième méthode de partage des objets repose sur la fonction DuplicateHandle, laquelle confère au processus appelant un duplicata d’un handle existant dans un autre processus. Par nature, vu que deux processus ne connaissent pas les valeurs des handles que l’un et l’autre utilisent, cette méthode requiert l’utilisation de procédé de communication inter processus comme la mémoire partagée, les messages, ou d’autres. En partant du handle d’un processus et du handle d’un objet manipulé par ce processus, un autre processus peut dans se contexte se voir octroyer un handle menant audit objet.

Handles d’objet et table des handles de processus

Quand un processus crée ou ouvre un objet par le nom, il reçoit un identificateur (handle) qui représente son accès à l’objet. Référencer un objet par son handle est plus rapide que d’utiliser le nom de l’objet, cela dans la mesure où le gestionnaire d’objets peut de la sorte localiser un objet sans effectuer de recherche de nom. Les processus peuvent aussi acquérir des handles vers des objets en héritant des handles de leur parent ou en recevant un duplication de handle d’un autre processus.

Tous les processus mode utilisateur doivent au préalable des interactions avec un objet en particulier posséder un handle vers ledit objet, sans quoi leurs threads ne peuvent y accéder. Dans la perspective de la prise en charge Windows de la sécurité, le principal avantage des handles est qu’ils servent de références indirectes vers les ressources système, et empêchent ainsi les applications de voir et de manipuler les structures de données sous-jacentes.

Les composants de l’exécutif, pilotes et autres codes système ne sont pas soumis aux mêmes obligations que les processus mode utilisateur en ce qui concerne les handles, mais peuvent en l’occurence accéder directement aux objets en mémoire. Si tel est le cas, cependant, ils doivent rendre compte de l’emploi de l’objet en incrémentant le compteur de références de façon que l’objet ne puisse pas être démantelé tandis qu’il est en cours d’utilisation.

Les handles d’objet procurent aussi d’autres avantages. Premièrement, exception faite de ce à quoi ils font référence, il n’y a aucune différence entre un handle de fichier, un handle de processus, un handle d’événements, et bien d’autres. Ces similitudes offrent par là même une interface cohérente pour référencer les objets indépendamment de leur type. Un second bénéfice garanti par les handles découle directement du fait que le gestionnaire d’objets soit le seul composant habilité à donner lieu à de telles références, et peut alors contrôler toute action mode utilisateur qui affecte un objet en vérifiant que le profil de sécurité de l’appelant autorise bel et bien l’opération demandée.

En interne, un handle d’objet est un index dans une table de handles propre à un processus, mappée dans l’espace d’adressage virtuel du noyau, allouée à partir du pool paginé et vers laquelle pointe le bloc EPROCESS. La table des handles d’un processus contient des pointeurs vers tous les objets pour lesquels le processus a ouvert un handle.

Chaque entrée de la sein de la table des handles d’un processus se présente sous la forme d’une structure HANDLE_TABLE_ENTRY.

  • Pointeur d’objet (Object) Pointeur vers l’entête de l’objet pour lequel le handle a été créé.

  • Masque des accès autorisés (GrantedAccess) Détermine les diverses opérations rendues possibles par le biais du handle.

Quand un processus se termine, le système appelle la routine ExSweepHandleTable de façon à refermer tous les handles vers des objets qui ont été ouvert lors de l’exécution.

Rétention des objets

Le Gestionnaire d’Objets implémente la rétention d’objet, à savoir qu’il laisse perdurer les objets tant qu’ils sont utilisés, et cesse de les conserver sitôt qu’ils ne le sont plus. Ce genre de stratégie, qui vise essentiellement à optimiser l’occupation des ressources mémoire (centrale et auxiliaire), dérive du fait que le Gestionnaire piste les processus utilisateurs d’objets. Il sait instinctivement leur nombre, et peut rapidement connaître lesquels. Qu’un objet soit préservé ou démantelé dépend du nombre de références qui s’établissent sur lui.

Le Gestionnaire d’Objets garde trace de deux compteurs pour chaque objet. Le compteur de descripteurs est le nombre de handles ouverts sur l’objet. Chaque fois qu’un processus ouvre un handle vers un objet, le Gestionnaire d’Objets crée une entrée dans la table des handles du processus, insère le handle nouvellement crée dans cette table, et incrémente d’une unité le compteur de handles ouverts dans l’entête de l’objet. Quand un processus a fini d’utiliser l’objet et ferme son handle, cela supprime une référence du compteur de handles ouverts. Si le compteur atteint une valeur nulle (quand il tombe à zéro), c’est le moment pour le Gestionnaire de supprimer le nom éventuel de l’objet dans l’espace de noms global. Cette suppression de l’entrée de répertoire contenant le nom de l’objet empêche de nouveaux processus d’ouvrir des handles vers l’objet. À ce stade, seul le code du système d’exploitation peut accéder à l’objet. Comme les composants mode noyau accèdent plus volontiers aux objets à l’aide de pointeurs (et non de handles), le Gestionnaire doit également enregistrer le nombre des pointeurs d’objet qu’il a attribué aux processus système.

Le compteur de pointeurs est le nombre de références distinctes faites sur un objet, mis à jour chaque fois que le Gestionnaire d’Objets à fourni un pointeur vers l’objet (incrementation), et que des composants mode noyau ont fini d’utiliser le pointeur. Chaque descripteur est également comptabilisé par le compteur de références ; en effet, un handle est aussi une référence d’objet.

Au moment de la création de l’objet par la fonction ObCreateObject, le compteur de pointeurs est fixé à un pour tenir compte de la référence retournée à l’appelant. Si l’objet est nommé, le nombre est fixé à deux pour tenir compte du pointeur dans l’objet répertoire contenant le nom de l’objet.

Table 55. Eléments auxiliaires sous-jacents à la rétention des objets

Élément

Lieu

Type

Autres références

PointerCount

OBJECT_HEADER

LONG

-

HandleCount

OBJECT_HEADER

LONG

-

Sécurité des objets

Quand un processus ouvre un fichier, il doit le faire en précisant quelles options d’accès (lecture, écriture, etc.) il sollicite concernant le fichier en question. Dans la même veine, au sein de l’exécutif, quand un processus crée un objet ou ouvre un handle vers un objet existant, il doit spécifier un ensemble de droits d’accès souhaités (desired acces rights), lesquels représentent en définitive ce que le processus souhaite faire avec l’objet. Il peut demander soit un ensemble de droits d’accès d’accès standards (tels lire, écrire et exécuter) qui s’appliquent à tous les types d’objets, soit des droits d’accès spécifiques qui dépendent du type d’objet. Un processus peut par exemple demander des accès pour suppression sur un objet fichier, des accès pour suspension en ce qui concerne un objet thread, etc.

Quand un processus ouvre un handle vers un objet, le gestionnaire d’objets relaie au moniteur de références de sécurité l’ensemble des droits d’accès désirés par le processus. Le moniteur vérifie alors que le descripteur de sécurité de l’objet autorise le type d’accès demandé et, si tel est le cas, retourne un ensemble de droits d’accès accordés (granted access rights). Le gestionnaire d’objets stocke ces droits au sein du handle qu’il crée pour l’objet.

A partir du moment où un processus est dépositaire d’un handle se rapportant à un objet donné, le gestionnaire d’objets peut dès lors contrôler rapidement que l’ensemble des droits d’accès accordées qui est stocké dans le handle correspond à l’usage impliqué par le service d’objet auquel le processus tente d’accéder.

OBJECT_INFORMATION_CLASS

Table 56. OBJECT_INFORMATION_CLASS
ID Classe Type de données associé

0x0000

ObjectBasicInformation

OBJECT_BASIC_INFORMATION

0x0001

ObjectNameInformation

0x0002

ObjectTypeInformation

OBJECT_TYPE_INFORMATION

0x0003

ObjectTypesInformation

OBJECT_TYPES_INFORMATION

0x0004

ObjectHandleFlagInformation

OBJECT_HANDLE_FLAG_INFORMATION

0x0005

ObjectSessionInformation

OBJECT_BASIC_INFORMATION
typedef struct _OBJECT_BASIC_INFORMATION {
    ULONG Attributes;
    ACCESS_MASK GrantedAccess;
    ULONG HandleCount;
    ULONG PointerCount;
    ULONG PagedPoolCharge;
    ULONG NonPagedPoolCharge;
    ULONG Reserved[3];
    ULONG NameInfoSize;
    ULONG TypeInfoSize;
    ULONG SecurityDescriptorSize;
    LARGE_INTEGER CreationTime;
} OBJECT_BASIC_INFORMATION, *POBJECT_BASIC_INFORMATION;
Table 57. Valeurs initiales des champs de la structure OBJECT_BASIC_INFORMATION
Champ Valeur initiale

Attributes

OBJECT_HEADER Flags

HandleCount

OBJECT_HEADER HandleCount

PointerCount

OBJECT_HEADER PointerCount

CreationTime

OBJECT_SYMBOLIC_LINK CreationTime

OBJECT_TYPE_INFORMATION
typedef struct _OBJECT_TYPE_INFORMATION {
    UNICODE_STRING TypeName;
    ULONG TotalNumberOfObjects;
    ULONG TotalNumberOfHandles;
    ULONG TotalPagedPoolUsage;
    ULONG TotalNonPagedPoolUsage;
    ULONG TotalNamePoolUsage;
    ULONG TotalHandleTableUsage;
    ULONG HighWaterNumberOfObjects;
    ULONG HighWaterNumberOfHandles;
    ULONG HighWaterPagedPoolUsage;
    ULONG HighWaterNonPagedPoolUsage;
    ULONG HighWaterNamePoolUsage;
    ULONG HighWaterHandleTableUsage;
    ULONG InvalidAttributes;
    GENERIC_MAPPING GenericMapping;
    ULONG ValidAccessMask;
    BOOLEAN SecurityRequired;
    BOOLEAN MaintainHandleCount;
    ULONG PoolType;
    ULONG DefaultPagedPoolCharge;
    ULONG DefaultNonPagedPoolCharge;
} OBJECT_TYPE_INFORMATION, *POBJECT_TYPE_INFORMATION;
OBJECT_TYPES_INFORMATION
typedef struct _OBJECT_TYPES_INFORMATION {
    ULONG NumberOfTypes;
} OBJECT_TYPES_INFORMATION, *POBJECT_TYPES_INFORMATION;

Synchronisation

Les processus et threads fonctionnels au sein des systèmes informatiques modernes, pour la plupart multithread, multi-utilisateur à multi traitement symétrique, s’exécutent en concurrence les uns vis à vis des autres, et se font dès lors compétition pour accéder aux ressources de l’ordinateur, par exemple un processeur, un port d’imprimante, ou une région de mémoire partagée. Une problématique centrale qui découle de ces aspects est le besoin de coordonner, de synchroniser, les opérations. Dans ce chapitre, du reste comme autant de sujet qui le composeront, nous allons voir les moyens et les méthodes dont use Windows afin de concrétiser une entente intelligente entre différentes entités concurrentes. Nous expliquerons quels protocoles sont considérés en la matière, quelles primitives les représentent, ce qu’elles font, et comment chaque type de dispositif privilégiant de la synchronisation est utilisé.

Exclusion mutuelle

Procurer aux logiciels des méthodes leur permettant d’accéder en toute sécurité aux ressources partagées de l’ordinateur (qui le sont du reste à peu près toutes, matérielles comme logicielles) fait sans aucun doute partie des entreprises les plus cruciales du système d’exploitation, qui doit à cet égard gérer le problème des accès concurrents, et de la sorte permettre l’exclusion mutuelle entre les différents processus.

Le concept d’exclusion mutuelle a au sein de tout système d’exploitation une importance logistique fondamentale, en ce qu’il assure une structure cohésive entre les différentes activités d’un même sous ensemble. Exclusion mutuelle signifie qu’un thread et un seul peut accéder à une certaine ressource à un moment donné. Il faut de l’exclusion mutuelle dès lors qu’une ressource ne se prête pas aux accès partagés, ou quand le partage donnerait des résultats imprévisibles. Par exemple, si deux threads envoient un fichier vers un port d’imprimante en même temps, un mélange des impressions pourrait avoir lieu. De même, si un thread lit un emplacement mémoire tandis qu’un autre écrit dessus, il existe une probabilité très forte que le premier thread obtienne des résultats différents de ceux attendues.

De manière générale, la problématique et les enjeux dont font l’objet l’exclusion mutuelle apparaissent chaque fois que plusieurs threads (ou à plus haut niveau, plusieurs processus) interviennent dans une chaine de traitement. Toutes les ressources modifiables sont concernées, et ne peuvent en l’occurence être partagées sans restrictions, contrairement aux ressources qui ne sont pas sujettes à modifications - par exemple une variable globale système dont la valeur serait définie une fois pour toute lors de la phase d’amorçage.

Les sections de code où s’effectue l’accès à des données partagées sont dites sections critiques. Pour assurer le bon fonctionnement du code, un seul thread à la fois doit être en mesure d’exécuter une section critique. Un programme ne pouvant faire aucune hypothèse sur l’ordre dans lequel les threads sont traités par l’ordonnanceur, des mécanismes gérant les accès concurrents doivent être mis en place.

Déjà complexe dans une perspective multitâche, le problème de l’exclusion mutuelle l’est d’autant plus sur les architectures à multi traitement symétrique, où le même code système est exécuté simultanément sur plusieurs processeurs et se partage des structures de données situés dans la mémoire globale. Le noyau Windows offre en conséquence diverses primitives d’exclusion mutuelle que lui, et le reste de l’exécutif, utilise pour synchroniser ses accès aux structures de données globales.

Si l’exclusion mutuelle est incorrectement prise en compte, il peut en résulter un interblocage (deadlock), à quoi correspond une situation dans laquelle deux processus concurrents s’attendent l’un l’autre, et s’empêchent ainsi mutuellement d’aller plus loin dans leur exécution.

Synchronisation au niveau IRQL bas

Sémaphores

Parmi les quelques objets du noyau rendus visibles en tant que primitives de synchronisation, les sémaphores se révèlent particulièrement utiles dans le but de maitriser le nombre de tâches (processus ou threads) potentiellement actives simultanément. Mécanisme très commun en programmation concurrente, on trouve des sémaphores dans bon nombre de composants intégrés à Windows : applications utilisateur, bibliothèques de support système, pilotes de périphérique, etc.

À propos générique concernant les sémaphores

Conceptuellement, un sémaphore joue le rôle d’un distributeur de tickets. Un processus du sémaphore demande un ticket en invoquant une opération particulière (sur laquelle nous reviendrons par la suite). Si au moins un ticket est disponible, le processus qui le réclame le prend et poursuit son exécution. Dans le cas contraire, le demandeur est enregistré dans une file d’attente et est bloqué dans l’attente de l’obtention d’un ticket. Par l’entremise et les effets d’une opération inverse, un processus dépose son ticket dans le distributeur, avec comme conséquence de rendre celui-ci à nouveau disponible. Si des processus sont en attente dans la file du sémaphore, le premier d’entre eux est débloqué et obtient son ticket.

Un sémaphore est dans sa forme la plus simple une variable qui tient lieu de compteur et à laquelle il est possible de n’accéder qu’à travers trois opérations : l’initialisation, qui consiste à donner au sémaphore une valeur initiale, le test, qui consiste à décroître la valeur du sémaphore d’une unité à condition que le résultat ne devienne pas négatif, et l’incrément, qui consiste simplement à accroître la valeur du sémaphore d’une unité. Ces deux dernières opérations sont généralement notées P et V, en référence aux abréviations des termes tester et incrémenter en hollandais, langue maternelle de l’inventeur des sémaphores, Edsger Dijkstra.

En dehors de la phase d’initialisation, faite logiquement en une seule fois et qui n’est à ce titre pas touchée par les contraintes inhérentes aux systèmes multi programmés, les autres opérations prises en charge par les sémaphores sont atomiques, c’est-à-dire qu’elles ne peuvent être ni divisées ni interrompues. En particulier, l’activité du processus qui effectue une telle opération ne peut pas être commutée au cours de celle-ci. La conséquence directe de cet aspect est qu’un processus qui désire exécuter une opération déjà en cours d’exécution au niveau d’un autre processus doit attendre que celui-ci prenne fin. L’atomicité des opérations peut être assurée par une instruction processeur spéciale ou en ignorant les interruptions afin d’empêcher d’autres processus de devenir actifs.

Si un sémaphore ne peut posséder que les valeurs 0 et 1, il est appelé sémaphore binaire. Un tel sémaphore est couramment appelé sémaphore d’exclusion mutuelle (mutex). S’il peut prendre des valeurs positives quelconques, il s’agit d’un sémaphore général ou à compteur.

Les sémaphores sont employés aussi bien dans le cadre de l’exclusion mutuelle que dans le contexte dans la synchronisation conditionnelle. Pour réaliser une exclusion mutuelle, on associe un sémaphore à une section critique. (Notez que nous utilisons ici ce terme dans une acception très classique - à savoir un ensemble d’instructions qui ne peuvent être traitées que par une entité exécutable à la fois, sans pour autant renvoyer au mécanisme Windows du même nom.) Pour réaliser une synchronisation conditionnelle, on associe un sémaphore à chaque condition.

Structure de données

Les sémaphores sont de nature assez basique pour ne pas avoir de représentation qui leur est associée au sein de la couche exécutive de Windows. La structure KSEMAPHORE sert au niveau système à agréger les données individuelles de chaque sémaphore.

lkd> dt nt!_KSEMAPHORE
   +0x000 Header           : _DISPATCHER_HEADER
   +0x018 Limit            : Int4B

La structure KSEMAPHORE, si elle contient un nombre effectivement réduit d’attributs, se montre typique de la façon dont Windows implémente la plupart des dispositifs servant à synchroniser l’exécution de multiples flux.

  • Objet dispatcher (Header) Incorpore des capacités de synchronisation sur lesquelles reposent les processus et les threads quand ils emploient des sémaphores.

  • Compteur de sémaphore (Limit) Compteur qui contrôle l’accès à une ressource en permettant à un nombre maximal de threads d’accéder à la ressource ainsi protégée.

L’en-tête dispatcher encapsule le type d’objet, l’état de signal et la liste des threads attendant le sémaphore.

Interfaces Windows de sémaphore

Le tableau énumère les fonctions Windows les plus courantes en matière de sémaphores.

Table 58. API Windows de sémaphore

Fonction

Utilité

CreateSemaphore

Créee et initialise un objet sémaphore ou sans nom, avec une valeur de compteur.

CloseHandle

Ferme un handle de sémaphore et supprime la référence à l’objet sémaphore.

WaitForSingleObject

Attend que l’appartenance d’un seul objet sémaphore lui soit accordée.

WaitForMultipleObjects

Attend que l’appartenance d’un ou plusieurs objets sémaphore lui soit accordée.

ReleaseSemaphore

Libère un objet sémaphore.

Table 59. SEMAPHORE_INFORMATION_CLASS
ID Classe Type de données associé

0x0000

SemaphoreBasicInformation

SEMAPHORE_BASIC_INFORMATION

SEMAPHORE_BASIC_INFORMATION
typedef struct _SEMAPHORE_BASIC_INFORMATION {
    LONG CurrentCount;
    LONG MaximumCount;
} SEMAPHORE_BASIC_INFORMATION, *PSEMAPHORE_BASIC_INFORMATION;
Table 60. Valeurs initiales des champs de la structure OBJECT_BASIC_INFORMATION
Champ Valeur initiale

CurrentCount

KSEMAPHORE Header.SignalState

MaximumCount

KSEMAPHORE Limit

Compteur et état de signal de sémaphores

Comme tous les objets qui obtiennent leurs capacités de synchronisation d’objets noyau dispatcher, un sémaphore est à tout moment dans l’un des états suivants : signalé ou non-signalé. Cette dualité, si elle bien celle observable parmi toutes les fonctions et tous les services (internes ou non) relatifs aux sémaphores, reflète assez peu la façon dont les choses se passent en interne. Dans un sémaphore, plutôt qu’une sémantique de signal actif / non actif, c’est la valeur du compteur de sémaphore, lequel limite le nombre de threads pouvant accéder simultanément à l’objet de synchronisation, qui fait office d’état de signal.

Le rapport entre un sémaphore, le compteur et l’état de signal de l’objet est le suivant : le sémaphore est considéré signalé quand le compteur est positif, non signalé quand le compteur vaut 0. La libération d’un sémaphore augmente le compteur, tandis qu’une attente de l’objet le décrémente. Si le compteur décroît jusqu’à la valeur nulle, le sémaphore est mis à l’état non signalé, avec comme conséquence le blocage des appelants de fonctions d’attente d’objet dispatcher (KeWaitForSingleObject, KeWaitForMultipleObjects).

A ce moment, aucun autre thread ne peut accéder au sémaphore, donc a fortiori aux ressources protégées par ce biais, tant que le thread propriétaire n’aura pas appelé de fonction de libération de sémaphore, ce qui a pour effet d’incrémenter le compteur d’une valeur spécifiée et de remettre à nouveau l’objet sémaphore dans l’état signalé.

Un moyen efficace d’interroger l’état du signal ou le compteur associé à un sémaphore (vous venons de voir que ces notions se recouvraient) est d’abord constitué par la fonction mode noyau KeReadStateSemaphore. En interne, cette routine extrait l’état de signal de l’objet dispatcher sur lequel s’appuie le sémaphore passé en paramètre, et retourne la valeur à l’appelant. Attention toutefois, puisque KeReadStateSemaphore, au contraire de traitements comme KeReleaseSemaphore ou KeWaitForSingleObject, ne synchronise pas ses accès à l’objet. En mode utilisateur, si le sous-système Windows ne fournit pas en l’état de méthode pour interroger le compteur d’un sémaphore, on trouve dans Ntdll un appel avec lequel parvenir à cette fin : NtQuerySemaphore.

Partage d’objets sémaphore

Plusieurs processus peuvent obtenir une référence vers un même objet sémaphore en vue de se le partager. La fonction Windows CreateSemaphore, avec laquelle créer un objet sémaphore, est la première à rendre visible ce comportement, dans la mesure où elle permet la production d’un objet idoine qui soit pourvu d’un nom. (Des sémaphores construits sans nom ne sont pas disponibles pour la synchronisation entre processus.) Un processus peut créer, nommer un objet (paramètre lpName de la fonction CreateSemaphore) et un second processus ouvrir cet objet (OpenSemaphore) et obtenir un descripteur partagé avec le premier processus. Aussi, puisque un processus obtient un descripteur en recevant une copie d’un autre processus, un processus peut spécifier le descripteur d’un sémaphore lors d’un appel à la fonction DuplicateHandle, avec pour résultat la création d’un duplicata pouvant être utilisé par un autre processus. Finalement, autre approche concernant le partage d’objets de type sémaphore, un processus peut hériter d’un processus parent un descripteur du même sémaphore - ce seulement si les règles de succession dictés par le processus créateur du sémaphore l’y autorisent (paramètre lpSemaphoreAttributes de CreateSemaphore)

Limite

En plus de la valeur de compteur, chaque sémaphore se voit attribuer une limite, qui résume, en chiffre, les capacités maximales d’un objet à octroyer des accès à une ressource. La notion de limite, dans ce contexte, apparaît dès la fonction d’initialisation de