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 initialement été conçu en tant que projet Epitech, et est désormais poursuivi sous l’égide de l’école 2600.

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

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

  • Le chapitre 1, « Concepts et outils », ouvre le bal sur une introduction à la terminologie et aux concepts clé qui seront employés tout au long de l’ouvrage, et offre en plus de cela un aperçu des nombreux utilitaires avec lesquels naviguer dans les méandres du système.

  • Le chapitre 2, « Architecture du système », 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.

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

  • Le chapitre 4, « Mécanismes de gestion », 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 », montre comment Windows assure l’exclusion mutuelle entre différents acteurs du système (processeurs, processus, threads).

  • 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.

  • Le chapitre 8, « Communication inter processus », traite des différents moyens qu’implémente Windows pour donner à plusieurs processus l’occasion de s’échanger des données entre eux.

  • Le chapitre 9, « Gestion de la mémoire », montre comment Windows implémente la mémoire virtuelle et comment il gère l’espace d’adressage des processus.

  • 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).

  • Le chapitre 11, « Sécurité", montre l’étendue de la palette de fonctionnalités qu’intègre Windows dans l’optique de répondre aux exigences fondamentales en matière de protection informatique.

  • Le chapitre 12, « Réseau », passe en revue les fonctionnalités réseau que Windows encapsule afin de permettre l’échange d’informations et de services.

  • Le chapitre 13, « Système d’E/S », explique de quelle façon Windows agit en tant que médiateur entre les composants matériels et immatériels (pilotes de périphérique et applications mode utilisateur) de la machine.

  • Chapitre 14, Gestion de l’alimentation

  • Le chapitre 15, "Gestion du stockage», 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.)

  • Le chapitre 16, "Systèmes de fichiers », présente l’organisation et le fonctionnement interne de quelques systèmes de fichiers reconnus par Windows.

  • Le chapitre 17, "Démarrage et arrêt », 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.

  • Le chapitre 19, "Interceptions", 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 licences 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.

Travaux en cours

Ce sur quoi votre attention est portée (et l’auteur l’espère, retenue) est un livre en cours de construction, dont la structure et le contenu (voire la présentation), s’ils continuent d’évoluer, n’en reste pas moins parfaitement utilisable. Un tel mode de diffusion a été choisi principalement pour deux raisons :

  • Talonner le développement de Windows Si les mécanismes centraux dans toutes les versions de Windows se ressemblent en surface, ressorts et rouages du système peuvent différer, parfois de façon légère, quelquefois radicalement. Dans la même veine, toute sortie majeure de systèmes Microsoft apportant son lot de nouveautés, il n’est pas concevable de traiter d’innovations au même degré que des technologies plus anciennes, pour lesquelles on a eu le temps de l’analyse. De variations anodines en bouleversements plus profonds (rupture avec l’existant), nous tenions néanmoins à couvrir l’histoire et l’actualité de Windows.

  • S’assurer de la qualité de l’ouvrage Les portes d’un livre incomplet restant toujours ouvertes, nous espérons par ce biais améliorer l’implication des lecteurs dans la définition du manuscrit final, et favoriser sa conformité à leurs attentes pour, enfin, aboutir à un ouvrage de meilleure qualité. N’hésitez donc pas à user d’un droit de regard et contacter l’auteur.

Pour les raisons susmentionnées, un numéro de version accompagne ce livre, correspondant à un état donné de son évolution.

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

Il existe six versions client majeures de Windows 10 : Windows 10 Famille, orientée pour un usage domestique, Windows 10 Professionnel, pour les petites et moyennes entreprises, Windows 10 Entreprise, pour les grands comptes (licences en volume), Windows 10 Education, pour les grandes écoles et universités, Windows 10 Professionnel Éducation, qui intègre des paramètres par défaut spécifiquement adaptés aux structures éducatives.

Il existe principalement trois moutures de Windows Server 2019 : Centre de données, Standard et Essentiel.

Si versions client et versions serveur de Windows partagent les mêmes fondations, y compris l’image du noyau, les bibliothèques HAL, les pilotes de périphériques et les DLL, elles différent dans bon nombre de fonctionnalités, par exemple le nombre de processeurs autorisés, la quantité de mémoire physique prise en compte ou le nombre de connexions réseau concurrentes envisageables. En outre, certains composants des éditions serveur ne font pas partie de leurs homologues client, tels les services d’annuaire.

De manière générale, les systèmes serveur sont optimisés au niveau du débit en tant que serveurs d’application à hautes performances. La version client, même si elle peut présenter des fonctionnalités serveur, est conçu pour minimiser le temps de réponse du bureau interactif, lequel influe fortement sur la perception de de l’utilisateur. Ainsi, le type du produit conditionne un certain nombre de décisions d’allocation de ressources prises au démarrage du système, par exemple la taille et le nombre des tas (ou pools) du système d’exploitation, le nombre de threads système auxiliaires internes, ou encore la taille du cache des données système. En outre, certaines décisions stratégiques concernant l’ordonnancement ne sont pas les mêmes entre éditions serveur et client, par exemple la façon dont le gestionnaire de mémoire équilibre les demandes d’allocation entre le système d’exploitation et les processus, la longueur par défaut de la tranche de temps, ou quantum, allouée aux threads (avec une valeur de quantum plus élevée sur les systèmes serveur, les applications ont plus de de chances de traiter une requête dans le temps imparti). Sauf mention explicite du contraire, tout dans cet ouvrage s’applique à la fois aux versions client et aux version serveur.

Fonction Service

GetProductInfo

RtlGetProductInfo

GetVersionEx

RtlGetVersion

RtlGetNtVersionNumbers

RtlGetNtProductType

VerifyVersionInfo

RtlVerifyVersionInfo

IsWindowsServer

Element Lieu Autres references

OSBuildNumber

PEB

RtlGetNtVersionNumbers

OSMajorVersion

PEB

RtlGetNtVersionNumbers

OSMinorVersion

PEB

RtlGetNtVersionNumbers

NtBuildNumber

KUSER_SHARED_DATA

NtMajorVersion

KUSER_SHARED_DATA

NtMinorVersion

KUSER_SHARED_DATA

NtProductType

KUSER_SHARED_DATA

RtlGetNtProductType

SuiteMask

KUSER_SHARED_DATA

RtlGetSuiteMask

Clé

HKLM\System\CurrentControlSet\Control\ProductOptions\ProductType

HKLM\Software\Microsoft\Windows NT\CurrentVersion\CurrentMajorVersionNumber

HKLM\Software\Microsoft\Windows NT\CurrentVersion\CurrentMinorVersionNumber

HKLM\Software\Microsoft\Windows NT\CurrentVersion\CurrentBuild

HKLM\Software\Microsoft\Windows NT\CurrentVersion\CurrentBuildNumber

Structure

Autres références

OSVERSIONINFOEX

VerifyVersionInfo

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.

Table 3. Temps utilisateur et temps noyau
Élément Type Lieu Autres références

TotalUserTime

LARGE_INTEGER

JOBOBJECT_BASIC_ACCOUNTING_INFORMATION

TotalKernelTime

LARGE_INTEGER

JOBOBJECT_BASIC_ACCOUNTING_INFORMATION

ThisPeriodTotalUserTime

LARGE_INTEGER

JOBOBJECT_BASIC_ACCOUNTING_INFORMATION

KernelTime

LARGE_INTEGER

KERNEL_USER_TIMES

NtQueryInformationProcess (ProcessInformationClass = ProcessTimes), NtQueryInformationThread (ThreadInformationClass = ThreadTimes)

UserTime

LARGE_INTEGER

KERNEL_USER_TIMES

NtQueryInformationProcess (ProcessInformationClass = ProcessTimes), NtQueryInformationThread (ThreadInformationClass = ThreadTimes)

KernelTime

KPRCB

UserTime

KPRCB


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 forcément 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é 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 4. 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 5. Préfixes pour interfaces en mode noyau
Préfixe Composant

Alpc

Système (A)LPC

Bvga

Boot Video (VGA)

Cc

Gestionnaire de cache

Cm

Gestionnaire de configuration

Em

Gestionnaire d’errata

Etw

Event Tracing for Windows

Ex

Routines de l’exécutif

ExpWnf

Windows Notification Framework

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

Débogueur noyau

Ke

Noyau

Ldr

Chargeur de modules

Lpc

Appel de procédure locale

Mm

Gestionnaire mémoire

Nt

Services système

Ob

Gestionnaire d’objets

Pcw

Performance Counter for Windows

Pf

Prefetcher logique

Po

Gestionnaire d’alimentation

Pp

Gestionnaire PnP

Ps

Gestionnaire de processus

Rtl

Bibliothèque d’exécution

Sdb

Base de données Shim

Se

Sécurité

Tm

Gestionnaire de transaction

Vf

Driver Verifier

Wdi

Windows Diagnostic Infrastructure

Wer

Windows Error Reporting

Whea

Windows Hardware Error Architecture

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.

Valeurs NTSTATUS

Une large majorité des routines exécutés en mode noyau, de sorte à rendre compte de la réussite ou de l’échec d’une opération, emploient le type prédéfini NTSTATUS, concrètement un entier 32 bits signé. En règle générale, une valeur égale à 0 signifie que l’action souhaitée a pris fin avec succès, tandis qu’une valeur différente du chiffe susdit met en évidence une erreur.

Les valeurs NTSTATUS sont divisées en quatre grandes catégories : les valeurs de réussite (intervalle 0 - 0x3FFFFFFF), les valeurs d’information (0x40000000 − 0x7FFFFFFF), les avertissements (0x80000000 − 0xBFFFFFFF) et les valeurs d’erreur (0xC0000000 - 0xFFFFFFFF). Plusieurs macros sont définies relativement à ces aspects.

  • NT_SUCCESS S’assure qu’une valeur donnée s’apparente à un état ou revêt un caractère informationnel.

  • NT_INFORMATION S’assure qu’une valeur donnée fait référence à un résultat d’opération, qui plutôt que de dénoter une réussite ou un échec proprement dit, apporte des informations supplémentaires sur la manière dont l’action envisagée s’est accomplie jusque-là.

  • NT_WARNING S’assure qu’une valeur donnée résulte d’un incident qui, sans extrême gravité apparente, nécessite toutefois une certaine attention ou action.

  • NT_ERROR S’assure qu’une valeur donnée corresponde à une erreur sévère.

Dans l’éventualité où un code NTSTATUS doit être relayée à un composant mode utilisateur, la valeur concernée est pour l’occasion convertie en un autre format, notée ERROR_xxx au niveau de l’API Windows (voir fonction GetLastError).

Status Valeur

STATUS_SUCCESS

0x0

STATUS_WAIT_1

0x1

STATUS_WAIT_2

0x2

STATUS_WAIT_3

0x3

STATUS_WAIT_63

0x3F

STATUS_ABANDONED

0x80

STATUS_ABANDONED_WAIT_0

0x80

STATUS_ABANDONED_WAIT_63

0xBF

STATUS_USER_APC

0xC0

STATUS_KERNEL_APC

0x100

STATUS_ALERTED

0x101

STATUS_TIMEOUT

0x102

STATUS_PENDING

0x103

STATUS_REPARSE

0x104

STATUS_MORE_ENTRIES

0x105

STATUS_NOT_ALL_ASSIGNED

0x106

STATUS_SOME_NOT_MAPPED

0x107

STATUS_OPLOCK_BREAK_IN_PROGRESS

0x108

STATUS_VOLUME_MOUNTED

0x109

STATUS_RXACT_COMMITTED

0x10A

STATUS_NOTIFY_CLEANUP

0x10B

STATUS_NOTIFY_ENUM_DIR

0x10C

STATUS_NO_QUOTAS_FOR_ACCOUNT

0x10D

STATUS_PAGE_FAULT_TRANSITION

0x110

STATUS_PAGE_FAULT_DEMAND_ZERO

0x111

STATUS_PAGE_FAULT_COPY_ON_WRITE

0x112

STATUS_PAGE_FAULT_GUARD_PAGE

0x113

STATUS_PAGE_FAULT_PAGING_FILE

0x114

STATUS_CACHE_PAGE_LOCKED

0x115

STATUS_CRASH_DUMP

0x116

STATUS_BUFFER_ALL_ZEROS

0x117

STATUS_REPARSE_OBJECT

0x118

STATUS_TRANSLATION_COMPLETE

0x120

STATUS_NOTHING_TO_TERMINATE

0x122

STATUS_PROCESS_NOT_IN_JOB

0x123

STATUS_PROCESS_IN_JOB

0x124

STATUS_VOLSNAP_HIBERNATE_READY

0x125

STATUS_PROCESS_CLONED

0x129

STATUS_FILE_LOCKED_WITH_WRITERS

0x12B

STATUS_VALID_IMAGE_HASH

0x12C

STATUS_RING_PREVIOUSLY_EMPTY

0x210

STATUS_RING_PREVIOUSLY_FULL

0x211

STATUS_RING_NEWLY_EMPTY

0x213

STATUS_OPLOCK_HANDLE_CLOSED

0x216

STATUS_WAIT_FOR_OPLOCK

0x367

DBG_EXCEPTION_HANDLED

0x10001

DBG_CONTINUE

0x10002

STATUS_FLT_IO_COMPLETE

0x1C0001

STATUS_DIS_ATTRIBUTE_BUILT

0x3C0001

STATUS_OBJECT_NAME_EXISTS

0x40000000

STATUS_THREAD_WAS_SUSPENDED

0x40000001

STATUS_WORKING_SET_LIMIT_RANGE

0x40000002

STATUS_IMAGE_NOT_AT_BASE

0x40000003

STATUS_RXACT_STATE_CREATED

0x40000004

STATUS_SEGMENT_NOTIFICATION

0x40000005

STATUS_LOCAL_USER_SESSION_KEY

0x40000006

STATUS_BAD_CURRENT_DIRECTORY

0x40000007

STATUS_SERIAL_MORE_WRITES

0x40000008

STATUS_REGISTRY_RECOVERED

0x40000009

STATUS_FT_WRITE_RECOVERY

0x4000000B

STATUS_SERIAL_COUNTER_TIMEOUT

0x4000000C

STATUS_NULL_LM_PASSWORD

0x4000000D

STATUS_RECEIVE_PARTIAL

0x4000000F

STATUS_RECEIVE_EXPEDITED

0x40000010

STATUS_EVENT_DONE

0x40000012

STATUS_EVENT_PENDING

0x40000013

STATUS_CHECKING_FILE_SYSTEM

0x40000014

STATUS_FATAL_APP_EXIT

0x40000015

STATUS_PREDEFINED_HANDLE

0x40000016

STATUS_WAS_UNLOCKED

0x40000017

STATUS_SERVICE_NOTIFICATION

0x40000018

STATUS_WAS_LOCKED

0x40000019

STATUS_ALREADY_WIN32

0x4000001B

STATUS_WX86_UNSIMULATE

0x4000001C

STATUS_WX86_CONTINUE

0x4000001D

STATUS_WX86_SINGLE_STEP

0x4000001E

STATUS_WX86_BREAKPOINT

0x4000001F

STATUS_WX86_EXCEPTION_CONTINUE

0x40000020

STATUS_WX86_EXCEPTION_CHAIN

0x40000022

STATUS_NO_YIELD_PERFORMED

0x40000024

STATUS_TIMER_RESUME_IGNORED

0x40000025

STATUS_ARBITRATION_UNHANDLED

0x40000026

STATUS_CARDBUS_NOT_SUPPORTED

0x40000027

STATUS_WX86_CREATEWX86TIB

0x40000028

STATUS_MP_PROCESSOR_MISMATCH

0x40000029

STATUS_HIBERNATED

0x4000002A

STATUS_RESUME_HIBERNATION

0x4000002B

STATUS_MESSAGE_RETRIEVED

0x4000002E

STATUS_ABANDON_HIBERFILE

0x40000033

STATUS_BIZRULES_NOT_ENABLED

0x40000034

STATUS_FT_READ_FROM_COPY

0x40000035

STATUS_IMAGE_AT_DIFFERENT_BASE

0x40000036

DBG_REPLY_LATER

0x40010001

DBG_UNABLE_TO_PROVIDE_HANDLE

0x40010002

DBG_TERMINATE_THREAD

0x40010003

DBG_TERMINATE_PROCESS

0x40010004

DBG_CONTROL_C

0x40010005

DBG_PRINTEXCEPTION_C

0x40010006

DBG_RIPEXCEPTION

0x40010007

DBG_CONTROL_BREAK

0x40010008

DBG_COMMAND_EXCEPTION

0x40010009

STATUS_GUARD_PAGE_VIOLATION

0x80000001

STATUS_DATATYPE_MISALIGNMENT

0x80000002

STATUS_BREAKPOINT

0x80000003

STATUS_SINGLE_STEP

0x80000004

STATUS_BUFFER_OVERFLOW

0x80000005

STATUS_NO_MORE_FILES

0x80000006

STATUS_WAKE_SYSTEM_DEBUGGER

0x80000007

STATUS_HANDLES_CLOSED

0x8000000A

STATUS_NO_INHERITANCE

0x8000000B

STATUS_GUID_SUBSTITUTION_MADE

0x8000000C

STATUS_PARTIAL_COPY

0x8000000D

STATUS_DEVICE_PAPER_EMPTY

0x8000000E

STATUS_DEVICE_POWERED_OFF

0x8000000F

STATUS_DEVICE_OFF_LINE

0x80000010

STATUS_DEVICE_BUSY

0x80000011

STATUS_NO_MORE_EAS

0x80000012

STATUS_INVALID_EA_NAME

0x80000013

STATUS_EA_LIST_INCONSISTENT

0x80000014

STATUS_INVALID_EA_FLAG

0x80000015

STATUS_VERIFY_REQUIRED

0x80000016

STATUS_EXTRANEOUS_INFORMATION

0x80000017

STATUS_RXACT_COMMIT_NECESSARY

0x80000018

STATUS_NO_MORE_ENTRIES

0x8000001A

STATUS_FILEMARK_DETECTED

0x8000001B

STATUS_MEDIA_CHANGED

0x8000001C

STATUS_BUS_RESET

0x8000001D

STATUS_END_OF_MEDIA

0x8000001E

STATUS_BEGINNING_OF_MEDIA

0x8000001F

STATUS_MEDIA_CHECK

0x80000020

STATUS_SETMARK_DETECTED

0x80000021

STATUS_NO_DATA_DETECTED

0x80000022

STATUS_SERVER_HAS_OPEN_HANDLES

0x80000024

STATUS_ALREADY_DISCONNECTED

0x80000025

STATUS_LONGJUMP

0x80000026

STATUS_PLUGPLAY_QUERY_VETOED

0x80000028

STATUS_UNWIND_CONSOLIDATE

0x80000029

STATUS_REGISTRY_HIVE_RECOVERED

0x8000002A

STATUS_DLL_MIGHT_BE_INSECURE

0x8000002B

STATUS_STOPPED_ON_SYMLINK

0x8000002D

STATUS_NO_ACE_CONDITION

0x8000002F

DBG_EXCEPTION_NOT_HANDLED

0x80010001

STATUS_CLUSTER_NODE_ALREADY_UP

0x80130001

STATUS_FLT_BUFFER_TOO_SMALL

0x801C0001

STATUS_FVE_PARTIAL_METADATA

0x80210001

STATUS_FVE_TRANSIENT_STATE

0x80210002

STATUS_UNSUCCESSFUL

0xC0000001

STATUS_NOT_IMPLEMENTED

0xC0000002

STATUS_INVALID_INFO_CLASS

0xC0000003

STATUS_INFO_LENGTH_MISMATCH

0xC0000004

STATUS_ACCESS_VIOLATION

0xC0000005

STATUS_IN_PAGE_ERROR

0xC0000006

STATUS_PAGEFILE_QUOTA

0xC0000007

STATUS_INVALID_HANDLE

0xC0000008

STATUS_BAD_INITIAL_STACK

0xC0000009

STATUS_BAD_INITIAL_PC

0xC000000A

STATUS_INVALID_CID

0xC000000B

STATUS_TIMER_NOT_CANCELED

0xC000000C

STATUS_INVALID_PARAMETER

0xC000000D

STATUS_NO_SUCH_DEVICE

0xC000000E

STATUS_NO_SUCH_FILE

0xC000000F

STATUS_INVALID_DEVICE_REQUEST

0xC0000010

STATUS_END_OF_FILE

0xC0000011

STATUS_WRONG_VOLUME

0xC0000012

STATUS_NO_MEDIA_IN_DEVICE

0xC0000013

STATUS_UNRECOGNIZED_MEDIA

0xC0000014

STATUS_NONEXISTENT_SECTOR

0xC0000015

STATUS_MORE_PROCESSING_REQUIRED

0xC0000016

STATUS_NO_MEMORY

0xC0000017

STATUS_CONFLICTING_ADDRESSES

0xC0000018

STATUS_NOT_MAPPED_VIEW

0xC0000019

STATUS_UNABLE_TO_FREE_VM

0xC000001A

STATUS_UNABLE_TO_DELETE_SECTION

0xC000001B

STATUS_INVALID_SYSTEM_SERVICE

0xC000001C

STATUS_ILLEGAL_INSTRUCTION

0xC000001D

STATUS_INVALID_LOCK_SEQUENCE

0xC000001E

STATUS_INVALID_VIEW_SIZE

0xC000001F

STATUS_INVALID_FILE_FOR_SECTION

0xC0000020

STATUS_ALREADY_COMMITTED

0xC0000021

STATUS_ACCESS_DENIED

0xC0000022

STATUS_BUFFER_TOO_SMALL

0xC0000023

STATUS_OBJECT_TYPE_MISMATCH

0xC0000024

STATUS_NONCONTINUABLE_EXCEPTION

0xC0000025

STATUS_INVALID_DISPOSITION

0xC0000026

STATUS_UNWIND

0xC0000027

STATUS_BAD_STACK

0xC0000028

STATUS_INVALID_UNWIND_TARGET

0xC0000029

STATUS_NOT_LOCKED

0xC000002A

STATUS_PARITY_ERROR

0xC000002B

STATUS_UNABLE_TO_DECOMMIT_VM

0xC000002C

STATUS_NOT_COMMITTED

0xC000002D

STATUS_INVALID_PORT_ATTRIBUTES

0xC000002E

STATUS_PORT_MESSAGE_TOO_LONG

0xC000002F

STATUS_INVALID_PARAMETER_MIX

0xC0000030

STATUS_INVALID_QUOTA_LOWER

0xC0000031

STATUS_DISK_CORRUPT_ERROR

0xC0000032

STATUS_OBJECT_NAME_INVALID

0xC0000033

STATUS_OBJECT_NAME_NOT_FOUND

0xC0000034

STATUS_OBJECT_NAME_COLLISION

0xC0000035

STATUS_PORT_DISCONNECTED

0xC0000037

STATUS_DEVICE_ALREADY_ATTACHED

0xC0000038

STATUS_OBJECT_PATH_INVALID

0xC0000039

STATUS_OBJECT_PATH_NOT_FOUND

0xC000003A

STATUS_OBJECT_PATH_SYNTAX_BAD

0xC000003B

STATUS_DATA_OVERRUN

0xC000003C

STATUS_DATA_LATE_ERROR

0xC000003D

STATUS_DATA_ERROR

0xC000003E

STATUS_CRC_ERROR

0xC000003F

STATUS_SECTION_TOO_BIG

0xC0000040

STATUS_PORT_CONNECTION_REFUSED

0xC0000041

STATUS_INVALID_PORT_HANDLE

0xC0000042

STATUS_SHARING_VIOLATION

0xC0000043

STATUS_QUOTA_EXCEEDED

0xC0000044

STATUS_INVALID_PAGE_PROTECTION

0xC0000045

STATUS_MUTANT_NOT_OWNED

0xC0000046

STATUS_SEMAPHORE_LIMIT_EXCEEDED

0xC0000047

STATUS_PORT_ALREADY_SET

0xC0000048

STATUS_SECTION_NOT_IMAGE

0xC0000049

STATUS_SUSPEND_COUNT_EXCEEDED

0xC000004A

STATUS_THREAD_IS_TERMINATING

0xC000004B

STATUS_BAD_WORKING_SET_LIMIT

0xC000004C

STATUS_INCOMPATIBLE_FILE_MAP

0xC000004D

STATUS_SECTION_PROTECTION

0xC000004E

STATUS_EAS_NOT_SUPPORTED

0xC000004F

STATUS_EA_TOO_LARGE

0xC0000050

STATUS_NONEXISTENT_EA_ENTRY

0xC0000051

STATUS_NO_EAS_ON_FILE

0xC0000052

STATUS_EA_CORRUPT_ERROR

0xC0000053

STATUS_FILE_LOCK_CONFLICT

0xC0000054

STATUS_LOCK_NOT_GRANTED

0xC0000055

STATUS_DELETE_PENDING

0xC0000056

STATUS_CTL_FILE_NOT_SUPPORTED

0xC0000057

STATUS_UNKNOWN_REVISION

0xC0000058

STATUS_REVISION_MISMATCH

0xC0000059

STATUS_INVALID_OWNER

0xC000005A

STATUS_INVALID_PRIMARY_GROUP

0xC000005B

STATUS_NO_IMPERSONATION_TOKEN

0xC000005C

STATUS_CANT_DISABLE_MANDATORY

0xC000005D

STATUS_NO_LOGON_SERVERS

0xC000005E

STATUS_NO_SUCH_LOGON_SESSION

0xC000005F

STATUS_NO_SUCH_PRIVILEGE

0xC0000060

STATUS_PRIVILEGE_NOT_HELD

0xC0000061

STATUS_INVALID_ACCOUNT_NAME

0xC0000062

STATUS_USER_EXISTS

0xC0000063

STATUS_NO_SUCH_USER

0xC0000064

STATUS_GROUP_EXISTS

0xC0000065

STATUS_NO_SUCH_GROUP

0xC0000066

STATUS_MEMBER_IN_GROUP

0xC0000067

STATUS_MEMBER_NOT_IN_GROUP

0xC0000068

STATUS_LAST_ADMIN

0xC0000069

STATUS_WRONG_PASSWORD

0xC000006A

STATUS_ILL_FORMED_PASSWORD

0xC000006B

STATUS_PASSWORD_RESTRICTION

0xC000006C

STATUS_LOGON_FAILURE

0xC000006D

STATUS_ACCOUNT_RESTRICTION

0xC000006E

STATUS_INVALID_LOGON_HOURS

0xC000006F

STATUS_INVALID_WORKSTATION

0xC0000070

STATUS_PASSWORD_EXPIRED

0xC0000071

STATUS_ACCOUNT_DISABLED

0xC0000072

STATUS_NONE_MAPPED

0xC0000073

STATUS_TOO_MANY_LUIDS_REQUESTED

0xC0000074

STATUS_LUIDS_EXHAUSTED

0xC0000075

STATUS_INVALID_SUB_AUTHORITY

0xC0000076

STATUS_INVALID_ACL

0xC0000077

STATUS_INVALID_SID

0xC0000078

STATUS_INVALID_SECURITY_DESCR

0xC0000079

STATUS_PROCEDURE_NOT_FOUND

0xC000007A

STATUS_INVALID_IMAGE_FORMAT

0xC000007B

STATUS_NO_TOKEN

0xC000007C

STATUS_BAD_INHERITANCE_ACL

0xC000007D

STATUS_RANGE_NOT_LOCKED

0xC000007E

STATUS_DISK_FULL

0xC000007F

STATUS_SERVER_DISABLED

0xC0000080

STATUS_SERVER_NOT_DISABLED

0xC0000081

STATUS_TOO_MANY_GUIDS_REQUESTED

0xC0000082

STATUS_GUIDS_EXHAUSTED

0xC0000083

STATUS_INVALID_ID_AUTHORITY

0xC0000084

STATUS_AGENTS_EXHAUSTED

0xC0000085

STATUS_INVALID_VOLUME_LABEL

0xC0000086

STATUS_SECTION_NOT_EXTENDED

0xC0000087

STATUS_NOT_MAPPED_DATA

0xC0000088

STATUS_RESOURCE_DATA_NOT_FOUND

0xC0000089

STATUS_RESOURCE_TYPE_NOT_FOUND

0xC000008A

STATUS_RESOURCE_NAME_NOT_FOUND

0xC000008B

STATUS_ARRAY_BOUNDS_EXCEEDED

0xC000008C

STATUS_FLOAT_DENORMAL_OPERAND

0xC000008D

STATUS_FLOAT_DIVIDE_BY_ZERO

0xC000008E

STATUS_FLOAT_INEXACT_RESULT

0xC000008F

STATUS_FLOAT_INVALID_OPERATION

0xC0000090

STATUS_FLOAT_OVERFLOW

0xC0000091

STATUS_FLOAT_STACK_CHECK

0xC0000092

STATUS_FLOAT_UNDERFLOW

0xC0000093

STATUS_INTEGER_DIVIDE_BY_ZERO

0xC0000094

STATUS_INTEGER_OVERFLOW

0xC0000095

STATUS_PRIVILEGED_INSTRUCTION

0xC0000096

STATUS_TOO_MANY_PAGING_FILES

0xC0000097

STATUS_FILE_INVALID

0xC0000098

STATUS_ALLOTTED_SPACE_EXCEEDED

0xC0000099

STATUS_INSUFFICIENT_RESOURCES

0xC000009A

STATUS_DFS_EXIT_PATH_FOUND

0xC000009B

STATUS_DEVICE_DATA_ERROR

0xC000009C

STATUS_DEVICE_NOT_CONNECTED

0xC000009D

STATUS_DEVICE_POWER_FAILURE

0xC000009E

STATUS_FREE_VM_NOT_AT_BASE

0xC000009F

STATUS_MEMORY_NOT_ALLOCATED

0xC00000A0

STATUS_WORKING_SET_QUOTA

0xC00000A1

STATUS_MEDIA_WRITE_PROTECTED

0xC00000A2

STATUS_DEVICE_NOT_READY

0xC00000A3

STATUS_INVALID_GROUP_ATTRIBUTES

0xC00000A4

STATUS_BAD_IMPERSONATION_LEVEL

0xC00000A5

STATUS_CANT_OPEN_ANONYMOUS

0xC00000A6

STATUS_BAD_VALIDATION_CLASS

0xC00000A7

STATUS_BAD_TOKEN_TYPE

0xC00000A8

STATUS_BAD_MASTER_BOOT_RECORD

0xC00000A9

STATUS_INSTRUCTION_MISALIGNMENT

0xC00000AA

STATUS_INSTANCE_NOT_AVAILABLE

0xC00000AB

STATUS_PIPE_NOT_AVAILABLE

0xC00000AC

STATUS_INVALID_PIPE_STATE

0xC00000AD

STATUS_PIPE_BUSY

0xC00000AE

STATUS_ILLEGAL_FUNCTION

0xC00000AF

STATUS_PIPE_DISCONNECTED

0xC00000B0

STATUS_PIPE_CLOSING

0xC00000B1

STATUS_PIPE_CONNECTED

0xC00000B2

STATUS_PIPE_LISTENING

0xC00000B3

STATUS_INVALID_READ_MODE

0xC00000B4

STATUS_IO_TIMEOUT

0xC00000B5

STATUS_FILE_FORCED_CLOSED

0xC00000B6

STATUS_PROFILING_NOT_STARTED

0xC00000B7

STATUS_PROFILING_NOT_STOPPED

0xC00000B8

STATUS_COULD_NOT_INTERPRET

0xC00000B9

STATUS_FILE_IS_A_DIRECTORY

0xC00000BA

STATUS_NOT_SUPPORTED

0xC00000BB

STATUS_REMOTE_NOT_LISTENING

0xC00000BC

STATUS_DUPLICATE_NAME

0xC00000BD

STATUS_BAD_NETWORK_PATH

0xC00000BE

STATUS_NETWORK_BUSY

0xC00000BF

STATUS_DEVICE_DOES_NOT_EXIST

0xC00000C0

STATUS_TOO_MANY_COMMANDS

0xC00000C1

STATUS_ADAPTER_HARDWARE_ERROR

0xC00000C2

STATUS_INVALID_NETWORK_RESPONSE

0xC00000C3

STATUS_UNEXPECTED_NETWORK_ERROR

0xC00000C4

STATUS_BAD_REMOTE_ADAPTER

0xC00000C5

STATUS_PRINT_QUEUE_FULL

0xC00000C6

STATUS_NO_SPOOL_SPACE

0xC00000C7

STATUS_PRINT_CANCELLED

0xC00000C8

STATUS_NETWORK_NAME_DELETED

0xC00000C9

STATUS_NETWORK_ACCESS_DENIED

0xC00000CA

STATUS_BAD_DEVICE_TYPE

0xC00000CB

STATUS_BAD_NETWORK_NAME

0xC00000CC

STATUS_TOO_MANY_NAMES

0xC00000CD

STATUS_TOO_MANY_SESSIONS

0xC00000CE

STATUS_SHARING_PAUSED

0xC00000CF

STATUS_REQUEST_NOT_ACCEPTED

0xC00000D0

STATUS_REDIRECTOR_PAUSED

0xC00000D1

STATUS_NET_WRITE_FAULT

0xC00000D2

STATUS_PROFILING_AT_LIMIT

0xC00000D3

STATUS_NOT_SAME_DEVICE

0xC00000D4

STATUS_FILE_RENAMED

0xC00000D5

STATUS_VIRTUAL_CIRCUIT_CLOSED

0xC00000D6

STATUS_NO_SECURITY_ON_OBJECT

0xC00000D7

STATUS_CANT_WAIT

0xC00000D8

STATUS_PIPE_EMPTY

0xC00000D9

STATUS_CANT_ACCESS_DOMAIN_INFO

0xC00000DA

STATUS_CANT_TERMINATE_SELF

0xC00000DB

STATUS_INVALID_SERVER_STATE

0xC00000DC

STATUS_INVALID_DOMAIN_STATE

0xC00000DD

STATUS_INVALID_DOMAIN_ROLE

0xC00000DE

STATUS_NO_SUCH_DOMAIN

0xC00000DF

STATUS_DOMAIN_EXISTS

0xC00000E0

STATUS_DOMAIN_LIMIT_EXCEEDED

0xC00000E1

STATUS_OPLOCK_NOT_GRANTED

0xC00000E2

STATUS_INVALID_OPLOCK_PROTOCOL

0xC00000E3

STATUS_INTERNAL_DB_CORRUPTION

0xC00000E4

STATUS_INTERNAL_ERROR

0xC00000E5

STATUS_GENERIC_NOT_MAPPED

0xC00000E6

STATUS_BAD_DESCRIPTOR_FORMAT

0xC00000E7

STATUS_INVALID_USER_BUFFER

0xC00000E8

STATUS_UNEXPECTED_IO_ERROR

0xC00000E9

STATUS_UNEXPECTED_MM_CREATE_ERR

0xC00000EA

STATUS_UNEXPECTED_MM_MAP_ERROR

0xC00000EB

STATUS_UNEXPECTED_MM_EXTEND_ERR

0xC00000EC

STATUS_NOT_LOGON_PROCESS

0xC00000ED

STATUS_LOGON_SESSION_EXISTS

0xC00000EE

STATUS_INVALID_PARAMETER_1

0xC00000EF

STATUS_INVALID_PARAMETER_2

0xC00000F0

STATUS_INVALID_PARAMETER_3

0xC00000F1

STATUS_INVALID_PARAMETER_4

0xC00000F2

STATUS_INVALID_PARAMETER_5

0xC00000F3

STATUS_INVALID_PARAMETER_6

0xC00000F4

STATUS_INVALID_PARAMETER_7

0xC00000F5

STATUS_INVALID_PARAMETER_8

0xC00000F6

STATUS_INVALID_PARAMETER_9

0xC00000F7

STATUS_INVALID_PARAMETER_10

0xC00000F8

STATUS_INVALID_PARAMETER_11

0xC00000F9

STATUS_INVALID_PARAMETER_12

0xC00000FA

STATUS_REDIRECTOR_NOT_STARTED

0xC00000FB

STATUS_REDIRECTOR_STARTED

0xC00000FC

STATUS_STACK_OVERFLOW

0xC00000FD

STATUS_NO_SUCH_PACKAGE

0xC00000FE

STATUS_BAD_FUNCTION_TABLE

0xC00000FF

STATUS_VARIABLE_NOT_FOUND

0xC0000100

STATUS_DIRECTORY_NOT_EMPTY

0xC0000101

STATUS_FILE_CORRUPT_ERROR

0xC0000102

STATUS_NOT_A_DIRECTORY

0xC0000103

STATUS_BAD_LOGON_SESSION_STATE

0xC0000104

STATUS_LOGON_SESSION_COLLISION

0xC0000105

STATUS_NAME_TOO_LONG

0xC0000106

STATUS_FILES_OPEN

0xC0000107

STATUS_CONNECTION_IN_USE

0xC0000108

STATUS_MESSAGE_NOT_FOUND

0xC0000109

STATUS_PROCESS_IS_TERMINATING

0xC000010A

STATUS_INVALID_LOGON_TYPE

0xC000010B

STATUS_NO_GUID_TRANSLATION

0xC000010C

STATUS_CANNOT_IMPERSONATE

0xC000010D

STATUS_IMAGE_ALREADY_LOADED

0xC000010E

STATUS_ABIOS_NOT_PRESENT

0xC000010F

STATUS_ABIOS_LID_NOT_EXIST

0xC0000110

STATUS_ABIOS_LID_ALREADY_OWNED

0xC0000111

STATUS_ABIOS_NOT_LID_OWNER

0xC0000112

STATUS_ABIOS_INVALID_COMMAND

0xC0000113

STATUS_ABIOS_INVALID_LID

0xC0000114

STATUS_ABIOS_INVALID_SELECTOR

0xC0000116

STATUS_NO_LDT

0xC0000117

STATUS_INVALID_LDT_SIZE

0xC0000118

STATUS_INVALID_LDT_OFFSET

0xC0000119

STATUS_INVALID_LDT_DESCRIPTOR

0xC000011A

STATUS_INVALID_IMAGE_NE_FORMAT

0xC000011B

STATUS_RXACT_INVALID_STATE

0xC000011C

STATUS_RXACT_COMMIT_FAILURE

0xC000011D

STATUS_MAPPED_FILE_SIZE_ZERO

0xC000011E

STATUS_TOO_MANY_OPENED_FILES

0xC000011F

STATUS_CANCELLED

0xC0000120

STATUS_CANNOT_DELETE

0xC0000121

STATUS_INVALID_COMPUTER_NAME

0xC0000122

STATUS_FILE_DELETED

0xC0000123

STATUS_SPECIAL_ACCOUNT

0xC0000124

STATUS_SPECIAL_GROUP

0xC0000125

STATUS_SPECIAL_USER

0xC0000126

STATUS_MEMBERS_PRIMARY_GROUP

0xC0000127

STATUS_FILE_CLOSED

0xC0000128

STATUS_TOO_MANY_THREADS

0xC0000129

STATUS_THREAD_NOT_IN_PROCESS

0xC000012A

STATUS_TOKEN_ALREADY_IN_USE

0xC000012B

STATUS_PAGEFILE_QUOTA_EXCEEDED

0xC000012C

STATUS_COMMITMENT_LIMIT

0xC000012D

STATUS_INVALID_IMAGE_LE_FORMAT

0xC000012E

STATUS_INVALID_IMAGE_NOT_MZ

0xC000012F

STATUS_INVALID_IMAGE_PROTECT

0xC0000130

STATUS_INVALID_IMAGE_WIN_16

0xC0000131

STATUS_LOGON_SERVER_CONFLICT

0xC0000132

STATUS_TIME_DIFFERENCE_AT_DC

0xC0000133

STATUS_SYNCHRONIZATION_REQUIRED

0xC0000134

STATUS_DLL_NOT_FOUND

0xC0000135

STATUS_OPEN_FAILED

0xC0000136

STATUS_IO_PRIVILEGE_FAILED

0xC0000137

STATUS_ORDINAL_NOT_FOUND

0xC0000138

STATUS_ENTRYPOINT_NOT_FOUND

0xC0000139

STATUS_CONTROL_C_EXIT

0xC000013A

STATUS_LOCAL_DISCONNECT

0xC000013B

STATUS_REMOTE_DISCONNECT

0xC000013C

STATUS_REMOTE_RESOURCES

0xC000013D

STATUS_LINK_FAILED

0xC000013E

STATUS_LINK_TIMEOUT

0xC000013F

STATUS_INVALID_CONNECTION

0xC0000140

STATUS_INVALID_ADDRESS

0xC0000141

STATUS_DLL_INIT_FAILED

0xC0000142

STATUS_MISSING_SYSTEMFILE

0xC0000143

STATUS_UNHANDLED_EXCEPTION

0xC0000144

STATUS_APP_INIT_FAILURE

0xC0000145

STATUS_PAGEFILE_CREATE_FAILED

0xC0000146

STATUS_NO_PAGEFILE

0xC0000147

STATUS_INVALID_LEVEL

0xC0000148

STATUS_WRONG_PASSWORD_CORE

0xC0000149

STATUS_ILLEGAL_FLOAT_CONTEXT

0xC000014A

STATUS_PIPE_BROKEN

0xC000014B

STATUS_REGISTRY_CORRUPT

0xC000014C

STATUS_REGISTRY_IO_FAILED

0xC000014D

STATUS_NO_EVENT_PAIR

0xC000014E

STATUS_UNRECOGNIZED_VOLUME

0xC000014F

STATUS_SERIAL_NO_DEVICE_INITED

0xC0000150

STATUS_NO_SUCH_ALIAS

0xC0000151

STATUS_MEMBER_NOT_IN_ALIAS

0xC0000152

STATUS_MEMBER_IN_ALIAS

0xC0000153

STATUS_ALIAS_EXISTS

0xC0000154

STATUS_LOGON_NOT_GRANTED

0xC0000155

STATUS_TOO_MANY_SECRETS

0xC0000156

STATUS_SECRET_TOO_LONG

0xC0000157

STATUS_INTERNAL_DB_ERROR

0xC0000158

STATUS_FULLSCREEN_MODE

0xC0000159

STATUS_TOO_MANY_CONTEXT_IDS

0xC000015A

STATUS_LOGON_TYPE_NOT_GRANTED

0xC000015B

STATUS_NOT_REGISTRY_FILE

0xC000015C

STATUS_FT_MISSING_MEMBER

0xC000015F

STATUS_ILL_FORMED_SERVICE_ENTRY

0xC0000160

STATUS_ILLEGAL_CHARACTER

0xC0000161

STATUS_UNMAPPABLE_CHARACTER

0xC0000162

STATUS_UNDEFINED_CHARACTER

0xC0000163

STATUS_FLOPPY_VOLUME

0xC0000164

STATUS_FLOPPY_ID_MARK_NOT_FOUND

0xC0000165

STATUS_FLOPPY_WRONG_CYLINDER

0xC0000166

STATUS_FLOPPY_UNKNOWN_ERROR

0xC0000167

STATUS_FLOPPY_BAD_REGISTERS

0xC0000168

STATUS_DISK_RECALIBRATE_FAILED

0xC0000169

STATUS_DISK_OPERATION_FAILED

0xC000016A

STATUS_DISK_RESET_FAILED

0xC000016B

STATUS_SHARED_IRQ_BUSY

0xC000016C

STATUS_FT_ORPHANING

0xC000016D

STATUS_PARTITION_FAILURE

0xC0000172

STATUS_INVALID_BLOCK_LENGTH

0xC0000173

STATUS_DEVICE_NOT_PARTITIONED

0xC0000174

STATUS_UNABLE_TO_LOCK_MEDIA

0xC0000175

STATUS_UNABLE_TO_UNLOAD_MEDIA

0xC0000176

STATUS_EOM_OVERFLOW

0xC0000177

STATUS_NO_MEDIA

0xC0000178

STATUS_NO_SUCH_MEMBER

0xC000017A

STATUS_INVALID_MEMBER

0xC000017B

STATUS_KEY_DELETED

0xC000017C

STATUS_NO_LOG_SPACE

0xC000017D

STATUS_TOO_MANY_SIDS

0xC000017E

STATUS_KEY_HAS_CHILDREN

0xC0000180

STATUS_CHILD_MUST_BE_VOLATILE

0xC0000181

STATUS_DRIVER_INTERNAL_ERROR

0xC0000183

STATUS_INVALID_DEVICE_STATE

0xC0000184

STATUS_IO_DEVICE_ERROR

0xC0000185

STATUS_DEVICE_PROTOCOL_ERROR

0xC0000186

STATUS_BACKUP_CONTROLLER

0xC0000187

STATUS_LOG_FILE_FULL

0xC0000188

STATUS_TOO_LATE

0xC0000189

STATUS_NO_TRUST_LSA_SECRET

0xC000018A

STATUS_NO_TRUST_SAM_ACCOUNT

0xC000018B

STATUS_TRUSTED_DOMAIN_FAILURE

0xC000018C

STATUS_EVENTLOG_FILE_CORRUPT

0xC000018E

STATUS_EVENTLOG_CANT_START

0xC000018F

STATUS_TRUST_FAILURE

0xC0000190

STATUS_MUTANT_LIMIT_EXCEEDED

0xC0000191

STATUS_NETLOGON_NOT_STARTED

0xC0000192

STATUS_ACCOUNT_EXPIRED

0xC0000193

STATUS_POSSIBLE_DEADLOCK

0xC0000194

STATUS_REMOTE_SESSION_LIMIT

0xC0000196

STATUS_EVENTLOG_FILE_CHANGED

0xC0000197

STATUS_FS_DRIVER_REQUIRED

0xC000019C

STATUS_INVALID_LOCK_RANGE

0xC00001A1

STATUS_INVALID_ACE_CONDITION

0xC00001A2

STATUS_DUPLICATE_PRIVILEGES

0xC00001A6

STATUS_REPAIR_NEEDED

0xC00001A8

STATUS_QUOTA_NOT_ENABLED

0xC00001A9

STATUS_NO_APPLICATION_PACKAGE

0xC00001AA

STATUS_NETWORK_OPEN_RESTRICTION

0xC0000201

STATUS_NO_USER_SESSION_KEY

0xC0000202

STATUS_USER_SESSION_DELETED

0xC0000203

STATUS_RESOURCE_LANG_NOT_FOUND

0xC0000204

STATUS_INSUFF_SERVER_RESOURCES

0xC0000205

STATUS_INVALID_BUFFER_SIZE

0xC0000206

STATUS_INVALID_ADDRESS_WILDCARD

0xC0000208

STATUS_TOO_MANY_ADDRESSES

0xC0000209

STATUS_ADDRESS_ALREADY_EXISTS

0xC000020A

STATUS_ADDRESS_CLOSED

0xC000020B

STATUS_CONNECTION_DISCONNECTED

0xC000020C

STATUS_CONNECTION_RESET

0xC000020D

STATUS_TOO_MANY_NODES

0xC000020E

STATUS_TRANSACTION_ABORTED

0xC000020F

STATUS_TRANSACTION_TIMED_OUT

0xC0000210

STATUS_TRANSACTION_NO_RELEASE

0xC0000211

STATUS_TRANSACTION_NO_MATCH

0xC0000212

STATUS_TRANSACTION_RESPONDED

0xC0000213

STATUS_TRANSACTION_INVALID_ID

0xC0000214

STATUS_TRANSACTION_INVALID_TYPE

0xC0000215

STATUS_NOT_SERVER_SESSION

0xC0000216

STATUS_NOT_CLIENT_SESSION

0xC0000217

STATUS_DEBUG_ATTACH_FAILED

0xC0000219

STATUS_DATA_NOT_ACCEPTED

0xC000021B

STATUS_NO_BROWSER_SERVERS_FOUND

0xC000021C

STATUS_VDM_HARD_ERROR

0xC000021D

STATUS_DRIVER_CANCEL_TIMEOUT

0xC000021E

STATUS_REPLY_MESSAGE_MISMATCH

0xC000021F

STATUS_MAPPED_ALIGNMENT

0xC0000220

STATUS_IMAGE_CHECKSUM_MISMATCH

0xC0000221

STATUS_LOST_WRITEBEHIND_DATA

0xC0000222

STATUS_PASSWORD_MUST_CHANGE

0xC0000224

STATUS_NOT_FOUND

0xC0000225

STATUS_NOT_TINY_STREAM

0xC0000226

STATUS_RECOVERY_FAILURE

0xC0000227

STATUS_STACK_OVERFLOW_READ

0xC0000228

STATUS_FAIL_CHECK

0xC0000229

STATUS_DUPLICATE_OBJECTID

0xC000022A

STATUS_OBJECTID_EXISTS

0xC000022B

STATUS_CONVERT_TO_LARGE

0xC000022C

STATUS_RETRY

0xC000022D

STATUS_FOUND_OUT_OF_SCOPE

0xC000022E

STATUS_ALLOCATE_BUCKET

0xC000022F

STATUS_PROPSET_NOT_FOUND

0xC0000230

STATUS_MARSHALL_OVERFLOW

0xC0000231

STATUS_INVALID_VARIANT

0xC0000232

STATUS_ACCOUNT_LOCKED_OUT

0xC0000234

STATUS_HANDLE_NOT_CLOSABLE

0xC0000235

STATUS_CONNECTION_REFUSED

0xC0000236

STATUS_GRACEFUL_DISCONNECT

0xC0000237

STATUS_ADDRESS_NOT_ASSOCIATED

0xC0000239

STATUS_CONNECTION_INVALID

0xC000023A

STATUS_CONNECTION_ACTIVE

0xC000023B

STATUS_NETWORK_UNREACHABLE

0xC000023C

STATUS_HOST_UNREACHABLE

0xC000023D

STATUS_PROTOCOL_UNREACHABLE

0xC000023E

STATUS_PORT_UNREACHABLE

0xC000023F

STATUS_REQUEST_ABORTED

0xC0000240

STATUS_CONNECTION_ABORTED

0xC0000241

STATUS_BAD_COMPRESSION_BUFFER

0xC0000242

STATUS_USER_MAPPED_FILE

0xC0000243

STATUS_AUDIT_FAILED

0xC0000244

STATUS_TIMER_RESOLUTION_NOT_SET

0xC0000245

STATUS_CONNECTION_COUNT_LIMIT

0xC0000246

STATUS_LOGIN_TIME_RESTRICTION

0xC0000247

STATUS_LOGIN_WKSTA_RESTRICTION

0xC0000248

STATUS_IMAGE_MP_UP_MISMATCH

0xC0000249

STATUS_INSUFFICIENT_LOGON_INFO

0xC0000250

STATUS_BAD_DLL_ENTRYPOINT

0xC0000251

STATUS_BAD_SERVICE_ENTRYPOINT

0xC0000252

STATUS_LPC_REPLY_LOST

0xC0000253

STATUS_IP_ADDRESS_CONFLICT1

0xC0000254

STATUS_IP_ADDRESS_CONFLICT2

0xC0000255

STATUS_REGISTRY_QUOTA_LIMIT

0xC0000256

STATUS_PATH_NOT_COVERED

0xC0000257

STATUS_NO_CALLBACK_ACTIVE

0xC0000258

STATUS_LICENSE_QUOTA_EXCEEDED

0xC0000259

STATUS_PWD_TOO_SHORT

0xC000025A

STATUS_PWD_TOO_RECENT

0xC000025B

STATUS_PWD_HISTORY_CONFLICT

0xC000025C

STATUS_PLUGPLAY_NO_DEVICE

0xC000025E

STATUS_UNSUPPORTED_COMPRESSION

0xC000025F

STATUS_INVALID_HW_PROFILE

0xC0000260

STATUS_DRIVER_ORDINAL_NOT_FOUND

0xC0000262

STATUS_RESOURCE_NOT_OWNED

0xC0000264

STATUS_TOO_MANY_LINKS

0xC0000265

STATUS_QUOTA_LIST_INCONSISTENT

0xC0000266

STATUS_FILE_IS_OFFLINE

0xC0000267

STATUS_EVALUATION_EXPIRATION

0xC0000268

STATUS_ILLEGAL_DLL_RELOCATION

0xC0000269

STATUS_LICENSE_VIOLATION

0xC000026A

STATUS_DLL_INIT_FAILED_LOGOFF

0xC000026B

STATUS_DRIVER_UNABLE_TO_LOAD

0xC000026C

STATUS_DFS_UNAVAILABLE

0xC000026D

STATUS_VOLUME_DISMOUNTED

0xC000026E

STATUS_WX86_INTERNAL_ERROR

0xC000026F

STATUS_WX86_FLOAT_STACK_CHECK

0xC0000270

STATUS_VALIDATE_CONTINUE

0xC0000271

STATUS_NO_MATCH

0xC0000272

STATUS_NO_MORE_MATCHES

0xC0000273

STATUS_NOT_A_REPARSE_POINT

0xC0000275

STATUS_IO_REPARSE_TAG_INVALID

0xC0000276

STATUS_IO_REPARSE_TAG_MISMATCH

0xC0000277

STATUS_IO_REPARSE_DATA_INVALID

0xC0000278

STATUS_PWD_TOO_LONG

0xC000027A

STATUS_STOWED_EXCEPTION

0xC000027B

STATUS_RANGE_LIST_CONFLICT

0xC0000282

STATUS_SOURCE_ELEMENT_EMPTY

0xC0000283

STATUS_DESTINATION_ELEMENT_FULL

0xC0000284

STATUS_ILLEGAL_ELEMENT_ADDRESS

0xC0000285

STATUS_MAGAZINE_NOT_PRESENT

0xC0000286

STATUS_REINITIALIZATION_NEEDED

0xC0000287

STATUS_DEVICE_REQUIRES_CLEANING

0x80000288

STATUS_DEVICE_DOOR_OPEN

0x80000289

STATUS_ENCRYPTION_FAILED

0xC000028A

STATUS_DECRYPTION_FAILED

0xC000028B

STATUS_RANGE_NOT_FOUND

0xC000028C

STATUS_NO_RECOVERY_POLICY

0xC000028D

STATUS_NO_EFS

0xC000028E

STATUS_WRONG_EFS

0xC000028F

STATUS_NO_USER_KEYS

0xC0000290

STATUS_FILE_NOT_ENCRYPTED

0xC0000291

STATUS_NOT_EXPORT_FORMAT

0xC0000292

STATUS_FILE_ENCRYPTED

0xC0000293

STATUS_WAKE_SYSTEM

0x40000294

STATUS_WMI_GUID_NOT_FOUND

0xC0000295

STATUS_WMI_INSTANCE_NOT_FOUND

0xC0000296

STATUS_WMI_ITEMID_NOT_FOUND

0xC0000297

STATUS_WMI_TRY_AGAIN

0xC0000298

STATUS_SHARED_POLICY

0xC0000299

STATUS_POLICY_OBJECT_NOT_FOUND

0xC000029A

STATUS_POLICY_ONLY_IN_DS

0xC000029B

STATUS_VOLUME_NOT_UPGRADED

0xC000029C

STATUS_NO_TRACKING_SERVICE

0xC000029F

STATUS_SERVER_SID_MISMATCH

0xC00002A0

STATUS_DS_NO_ATTRIBUTE_OR_VALUE

0xC00002A1

STATUS_DS_BUSY

0xC00002A5

STATUS_DS_UNAVAILABLE

0xC00002A6

STATUS_DS_NO_RIDS_ALLOCATED

0xC00002A7

STATUS_DS_NO_MORE_RIDS

0xC00002A8

STATUS_DS_INCORRECT_ROLE_OWNER

0xC00002A9

STATUS_DS_RIDMGR_INIT_ERROR

0xC00002AA

STATUS_DS_OBJ_CLASS_VIOLATION

0xC00002AB

STATUS_DS_CANT_ON_NON_LEAF

0xC00002AC

STATUS_DS_CANT_ON_RDN

0xC00002AD

STATUS_DS_CANT_MOD_OBJ_CLASS

0xC00002AE

STATUS_DS_CROSS_DOM_MOVE_FAILED

0xC00002AF

STATUS_DS_GC_NOT_AVAILABLE

0xC00002B0

STATUS_CANT_ENABLE_DENY_ONLY

0xC00002B3

STATUS_FLOAT_MULTIPLE_FAULTS

0xC00002B4

STATUS_FLOAT_MULTIPLE_TRAPS

0xC00002B5

STATUS_DEVICE_REMOVED

0xC00002B6

STATUS_JOURNAL_NOT_ACTIVE

0xC00002B8

STATUS_NOINTERFACE

0xC00002B9

STATUS_DS_RIDMGR_DISABLED

0xC00002BA

STATUS_DS_ADMIN_LIMIT_EXCEEDED

0xC00002C1

STATUS_DRIVER_FAILED_SLEEP

0xC00002C2

STATUS_WMI_READ_ONLY

0xC00002C6

STATUS_WMI_SET_FAILURE

0xC00002C7

STATUS_COMMITMENT_MINIMUM

0xC00002C8

STATUS_REG_NAT_CONSUMPTION

0xC00002C9

STATUS_TRANSPORT_FULL

0xC00002CA

STATUS_DS_SAM_INIT_FAILURE

0xC00002CB

STATUS_ONLY_IF_CONNECTED

0xC00002CC

STATUS_PNP_RESTART_ENUMERATION

0xC00002CE

STATUS_JOURNAL_ENTRY_DELETED

0xC00002CF

STATUS_PNP_REBOOT_REQUIRED

0xC00002D2

STATUS_POWER_STATE_INVALID

0xC00002D3

STATUS_DS_INVALID_GROUP_TYPE

0xC00002D4

STATUS_DS_HAVE_PRIMARY_MEMBERS

0xC00002DC

STATUS_WMI_NOT_SUPPORTED

0xC00002DD

STATUS_INSUFFICIENT_POWER

0xC00002DE

STATUS_SAM_NEED_BOOTKEY_FLOPPY

0xC00002E0

STATUS_DS_CANT_START

0xC00002E1

STATUS_DS_INIT_FAILURE

0xC00002E2

STATUS_SAM_INIT_FAILURE

0xC00002E3

STATUS_DS_GC_REQUIRED

0xC00002E4

STATUS_MULTIPLE_FAULT_VIOLATION

0xC00002E8

STATUS_CANNOT_MAKE

0xC00002EA

STATUS_SYSTEM_SHUTDOWN

0xC00002EB

STATUS_DS_INIT_FAILURE_CONSOLE

0xC00002EC

STATUS_NO_TGT_REPLY

0xC00002EF

STATUS_OBJECTID_NOT_FOUND

0xC00002F0

STATUS_NO_IP_ADDRESSES

0xC00002F1

STATUS_WRONG_CREDENTIAL_HANDLE

0xC00002F2

STATUS_CRYPTO_SYSTEM_INVALID

0xC00002F3

STATUS_MAX_REFERRALS_EXCEEDED

0xC00002F4

STATUS_MUST_BE_KDC

0xC00002F5

STATUS_TOO_MANY_PRINCIPALS

0xC00002F7

STATUS_NO_PA_DATA

0xC00002F8

STATUS_PKINIT_NAME_MISMATCH

0xC00002F9

STATUS_SMARTCARD_LOGON_REQUIRED

0xC00002FA

STATUS_KDC_INVALID_REQUEST

0xC00002FB

STATUS_KDC_UNABLE_TO_REFER

0xC00002FC

STATUS_KDC_UNKNOWN_ETYPE

0xC00002FD

STATUS_SHUTDOWN_IN_PROGRESS

0xC00002FE

STATUS_NOT_SUPPORTED_ON_SBS

0xC0000300

STATUS_WMI_GUID_DISCONNECTED

0xC0000301

STATUS_WMI_ALREADY_DISABLED

0xC0000302

STATUS_WMI_ALREADY_ENABLED

0xC0000303

STATUS_MFT_TOO_FRAGMENTED

0xC0000304

STATUS_COPY_PROTECTION_FAILURE

0xC0000305

STATUS_CSS_KEY_NOT_PRESENT

0xC0000307

STATUS_CSS_KEY_NOT_ESTABLISHED

0xC0000308

STATUS_CSS_SCRAMBLED_SECTOR

0xC0000309

STATUS_CSS_REGION_MISMATCH

0xC000030A

STATUS_CSS_RESETS_EXHAUSTED

0xC000030B

STATUS_PASSWORD_CHANGE_REQUIRED

0xC000030C

STATUS_PKINIT_FAILURE

0xC0000320

STATUS_NO_KERB_KEY

0xC0000322

STATUS_HOST_DOWN

0xC0000350

STATUS_UNSUPPORTED_PREAUTH

0xC0000351

STATUS_EFS_ALG_BLOB_TOO_BIG

0xC0000352

STATUS_PORT_NOT_SET

0xC0000353

STATUS_DEBUGGER_INACTIVE

0xC0000354

STATUS_DS_VERSION_CHECK_FAILURE

0xC0000355

STATUS_AUDITING_DISABLED

0xC0000356

STATUS_PRENT4_MACHINE_ACCOUNT

0xC0000357

STATUS_INVALID_IMAGE_WIN_32

0xC0000359

STATUS_INVALID_IMAGE_WIN_64

0xC000035A

STATUS_BAD_BINDINGS

0xC000035B

STATUS_NETWORK_SESSION_EXPIRED

0xC000035C

STATUS_APPHELP_BLOCK

0xC000035D

STATUS_ALL_SIDS_FILTERED

0xC000035E

STATUS_NOT_SAFE_MODE_DRIVER

0xC000035F

STATUS_FAILED_DRIVER_ENTRY

0xC0000365

STATUS_DEVICE_ENUMERATION_ERROR

0xC0000366

STATUS_MOUNT_POINT_NOT_RESOLVED

0xC0000368

STATUS_MCA_OCCURED

0xC000036A

STATUS_SYSTEM_HIVE_TOO_LARGE

0xC000036E

STATUS_DS_SHUTTING_DOWN

0x40000370

STATUS_NO_SECRETS

0xC0000371

STATUS_FAILED_STACK_SWITCH

0xC0000373

STATUS_HEAP_CORRUPTION

0xC0000374

STATUS_SMARTCARD_WRONG_PIN

0xC0000380

STATUS_SMARTCARD_CARD_BLOCKED

0xC0000381

STATUS_SMARTCARD_NO_CARD

0xC0000383

STATUS_SMARTCARD_NO_CERTIFICATE

0xC0000385

STATUS_SMARTCARD_NO_KEYSET

0xC0000386

STATUS_SMARTCARD_IO_ERROR

0xC0000387

STATUS_DOWNGRADE_DETECTED

0xC0000388

STATUS_SMARTCARD_CERT_REVOKED

0xC0000389

STATUS_ISSUING_CA_UNTRUSTED

0xC000038A

STATUS_REVOCATION_OFFLINE_C

0xC000038B

STATUS_PKINIT_CLIENT_FAILURE

0xC000038C

STATUS_SMARTCARD_CERT_EXPIRED

0xC000038D

STATUS_SMARTCARD_SILENT_CONTEXT

0xC000038F

STATUS_DS_NAME_NOT_UNIQUE

0xC0000404

STATUS_DS_DUPLICATE_ID_FOUND

0xC0000405

STATUS_USER2USER_REQUIRED

0xC0000408

STATUS_STACK_BUFFER_OVERRUN

0xC0000409

STATUS_NO_S4U_PROT_SUPPORT

0xC000040A

STATUS_REVOCATION_OFFLINE_KDC

0xC000040C

STATUS_ISSUING_CA_UNTRUSTED_KDC

0xC000040D

STATUS_KDC_CERT_EXPIRED

0xC000040E

STATUS_KDC_CERT_REVOKED

0xC000040F

STATUS_PARAMETER_QUOTA_EXCEEDED

0xC0000410

STATUS_HIBERNATION_FAILURE

0xC0000411

STATUS_DELAY_LOAD_FAILED

0xC0000412

STATUS_VDM_DISALLOWED

0xC0000414

STATUS_NTLM_BLOCKED

0xC0000418

STATUS_ASSERTION_FAILURE

0xC0000420

STATUS_VERIFIER_STOP

0xC0000421

STATUS_CALLBACK_POP_STACK

0xC0000423

STATUS_HIVE_UNLOADED

0xC0000425

STATUS_COMPRESSION_DISABLED

0xC0000426

STATUS_FILE_SYSTEM_LIMITATION

0xC0000427

STATUS_INVALID_IMAGE_HASH

0xC0000428

STATUS_NOT_CAPABLE

0xC0000429

STATUS_REQUEST_OUT_OF_SEQUENCE

0xC000042A

STATUS_IMPLEMENTATION_LIMIT

0xC000042B

STATUS_ELEVATION_REQUIRED

0xC000042C

STATUS_NO_SECURITY_CONTEXT

0xC000042D

STATUS_PKU2U_CERT_FAILURE

0xC000042F

STATUS_BEYOND_VDL

0xC0000432

STATUS_PTE_CHANGED

0xC0000434

STATUS_PURGE_FAILED

0xC0000435

STATUS_INVALID_LABEL

0xC0000446

STATUS_AMBIGUOUS_SYSTEM_DEVICE

0xC0000451

STATUS_SYSTEM_DEVICE_NOT_FOUND

0xC0000452

STATUS_RESTART_BOOT_APPLICATION

0xC0000453

STATUS_INVALID_SESSION

0xC0000455

STATUS_THREAD_NOT_IN_SESSION

0xC0000457

STATUS_INVALID_WEIGHT

0xC0000458

STATUS_REQUEST_PAUSED

0xC0000459

STATUS_NO_RANGES_PROCESSED

0xC0000460

STATUS_DISK_RESOURCES_EXHAUSTED

0xC0000461

STATUS_NEEDS_REMEDIATION

0xC0000462

STATUS_DEVICE_UNREACHABLE

0xC0000464

STATUS_INVALID_TOKEN

0xC0000465

STATUS_SERVER_UNAVAILABLE

0xC0000466

STATUS_FILE_NOT_AVAILABLE

0xC0000467

STATUS_PACKAGE_UPDATING

0xC0000469

STATUS_NOT_READ_FROM_COPY

0xC000046A

STATUS_FT_WRITE_FAILURE

0xC000046B

STATUS_FT_DI_SCAN_REQUIRED

0xC000046C

STATUS_DATA_CHECKSUM_ERROR

0xC0000470

STATUS_INVALID_OFFSET_ALIGNMENT

0xC0000474

STATUS_OPERATION_IN_PROGRESS

0xC0000476

STATUS_SCRUB_DATA_DISABLED

0xC0000478

STATUS_NOT_REDUNDANT_STORAGE

0xC0000479

STATUS_DIRECTORY_NOT_SUPPORTED

0xC000047C

STATUS_IO_OPERATION_TIMEOUT

0xC000047D

STATUS_SYSTEM_NEEDS_REMEDIATION

0xC000047E

STATUS_SHARE_UNAVAILABLE

0xC0000480

STATUS_INVALID_TASK_NAME

0xC0000500

STATUS_INVALID_TASK_INDEX

0xC0000501

STATUS_THREAD_ALREADY_IN_TASK

0xC0000502

STATUS_CALLBACK_BYPASS

0xC0000503

STATUS_UNDEFINED_SCOPE

0xC0000504

STATUS_INVALID_CAP

0xC0000505

STATUS_NOT_GUI_PROCESS

0xC0000506

STATUS_FAIL_FAST_EXCEPTION

0xC0000602

STATUS_IMAGE_CERT_REVOKED

0xC0000603

STATUS_PORT_CLOSED

0xC0000700

STATUS_MESSAGE_LOST

0xC0000701

STATUS_INVALID_MESSAGE

0xC0000702

STATUS_REQUEST_CANCELED

0xC0000703

STATUS_RECURSIVE_DISPATCH

0xC0000704

STATUS_LPC_REQUESTS_NOT_ALLOWED

0xC0000707

STATUS_RESOURCE_IN_USE

0xC0000708

STATUS_HARDWARE_MEMORY_ERROR

0xC0000709

STATUS_PROCESS_IS_PROTECTED

0xC0000712

STATUS_MCA_EXCEPTION

0xC0000713

STATUS_SYMLINK_CLASS_DISABLED

0xC0000715

STATUS_NO_UNICODE_TRANSLATION

0xC0000717

STATUS_ALREADY_REGISTERED

0xC0000718

STATUS_CONTEXT_MISMATCH

0xC0000719

STATUS_INVALID_THREAD

0xC000071C

STATUS_CALLBACK_RETURNED_LANG

0xC000071F

STATUS_DISK_REPAIR_DISABLED

0xC0000800

STATUS_DISK_QUOTA_EXCEEDED

0xC0000802

STATUS_DATA_LOST_REPAIR

0x80000803

STATUS_CONTENT_BLOCKED

0xC0000804

STATUS_BAD_CLUSTERS

0xC0000805

STATUS_VOLUME_DIRTY

0xC0000806

STATUS_DISK_REPAIR_REDIRECTED

0x40000807

STATUS_DISK_REPAIR_UNSUCCESSFUL

0xC0000808

STATUS_CORRUPT_LOG_OVERFULL

0xC0000809

STATUS_CORRUPT_LOG_CORRUPTED

0xC000080A

STATUS_CORRUPT_LOG_UNAVAILABLE

0xC000080B

STATUS_CORRUPT_LOG_DELETED_FULL

0xC000080C

STATUS_CORRUPT_LOG_CLEARED

0xC000080D

STATUS_ORPHAN_NAME_EXHAUSTED

0xC000080E

STATUS_FILE_CHECKED_OUT

0xC0000901

STATUS_CHECKOUT_REQUIRED

0xC0000902

STATUS_BAD_FILE_TYPE

0xC0000903

STATUS_FILE_TOO_LARGE

0xC0000904

STATUS_FORMS_AUTH_REQUIRED

0xC0000905

STATUS_VIRUS_INFECTED

0xC0000906

STATUS_VIRUS_DELETED

0xC0000907

STATUS_BAD_MCFG_TABLE

0xC0000908

STATUS_CANNOT_BREAK_OPLOCK

0xC0000909

STATUS_BAD_KEY

0xC000090A

STATUS_BAD_DATA

0xC000090B

STATUS_NO_KEY

0xC000090C

STATUS_FILE_HANDLE_REVOKED

0xC0000910

STATUS_WOW_ASSERTION

0xC0009898

STATUS_INVALID_SIGNATURE

0xC000A000

STATUS_HMAC_NOT_SUPPORTED

0xC000A001

STATUS_AUTH_TAG_MISMATCH

0xC000A002

STATUS_INVALID_STATE_TRANSITION

0xC000A003

STATUS_INVALID_PEP_INFO_VERSION

0xC000A005

STATUS_IPSEC_QUEUE_OVERFLOW

0xC000A010

STATUS_ND_QUEUE_OVERFLOW

0xC000A011

STATUS_HOPLIMIT_EXCEEDED

0xC000A012

STATUS_PROTOCOL_NOT_SUPPORTED

0xC000A013

STATUS_FASTPATH_REJECTED

0xC000A014

STATUS_XML_PARSE_ERROR

0xC000A083

STATUS_XMLDSIG_ERROR

0xC000A084

STATUS_WRONG_COMPARTMENT

0xC000A085

STATUS_AUTHIP_FAILURE

0xC000A086

STATUS_DS_OID_NOT_FOUND

0xC000A088

STATUS_INCORRECT_ACCOUNT_TYPE

0xC000A089

STATUS_HASH_NOT_SUPPORTED

0xC000A100

STATUS_HASH_NOT_PRESENT

0xC000A101

STATUS_GPIO_OPERATION_DENIED

0xC000A125

STATUS_CANNOT_SWITCH_RUNLEVEL

0xC000A141

STATUS_INVALID_RUNLEVEL_SETTING

0xC000A142

STATUS_RUNLEVEL_SWITCH_TIMEOUT

0xC000A143

STATUS_NOT_APPCONTAINER

0xC000A200

STATUS_APP_DATA_NOT_FOUND

0xC000A281

STATUS_APP_DATA_EXPIRED

0xC000A282

STATUS_APP_DATA_CORRUPT

0xC000A283

STATUS_APP_DATA_LIMIT_EXCEEDED

0xC000A284

STATUS_APP_DATA_REBOOT_REQUIRED

0xC000A285

DBG_NO_STATE_CHANGE

0xC0010001

DBG_APP_NOT_IDLE

0xC0010002

RPC_NT_INVALID_STRING_BINDING

0xC0020001

RPC_NT_WRONG_KIND_OF_BINDING

0xC0020002

RPC_NT_INVALID_BINDING

0xC0020003

RPC_NT_PROTSEQ_NOT_SUPPORTED

0xC0020004

RPC_NT_INVALID_RPC_PROTSEQ

0xC0020005

RPC_NT_INVALID_STRING_UUID

0xC0020006

RPC_NT_INVALID_ENDPOINT_FORMAT

0xC0020007

RPC_NT_INVALID_NET_ADDR

0xC0020008

RPC_NT_NO_ENDPOINT_FOUND

0xC0020009

RPC_NT_INVALID_TIMEOUT

0xC002000A

RPC_NT_OBJECT_NOT_FOUND

0xC002000B

RPC_NT_ALREADY_REGISTERED

0xC002000C

RPC_NT_TYPE_ALREADY_REGISTERED

0xC002000D

RPC_NT_ALREADY_LISTENING

0xC002000E

RPC_NT_NO_PROTSEQS_REGISTERED

0xC002000F

RPC_NT_NOT_LISTENING

0xC0020010

RPC_NT_UNKNOWN_MGR_TYPE

0xC0020011

RPC_NT_UNKNOWN_IF

0xC0020012

RPC_NT_NO_BINDINGS

0xC0020013

RPC_NT_NO_PROTSEQS

0xC0020014

RPC_NT_CANT_CREATE_ENDPOINT

0xC0020015

RPC_NT_OUT_OF_RESOURCES

0xC0020016

RPC_NT_SERVER_UNAVAILABLE

0xC0020017

RPC_NT_SERVER_TOO_BUSY

0xC0020018

RPC_NT_INVALID_NETWORK_OPTIONS

0xC0020019

RPC_NT_NO_CALL_ACTIVE

0xC002001A

RPC_NT_CALL_FAILED

0xC002001B

RPC_NT_CALL_FAILED_DNE

0xC002001C

RPC_NT_PROTOCOL_ERROR

0xC002001D

RPC_NT_UNSUPPORTED_TRANS_SYN

0xC002001F

RPC_NT_UNSUPPORTED_TYPE

0xC0020021

RPC_NT_INVALID_TAG

0xC0020022

RPC_NT_INVALID_BOUND

0xC0020023

RPC_NT_NO_ENTRY_NAME

0xC0020024

RPC_NT_INVALID_NAME_SYNTAX

0xC0020025

RPC_NT_UNSUPPORTED_NAME_SYNTAX

0xC0020026

RPC_NT_UUID_NO_ADDRESS

0xC0020028

RPC_NT_DUPLICATE_ENDPOINT

0xC0020029

RPC_NT_UNKNOWN_AUTHN_TYPE

0xC002002A

RPC_NT_MAX_CALLS_TOO_SMALL

0xC002002B

RPC_NT_STRING_TOO_LONG

0xC002002C

RPC_NT_PROTSEQ_NOT_FOUND

0xC002002D

RPC_NT_PROCNUM_OUT_OF_RANGE

0xC002002E

RPC_NT_BINDING_HAS_NO_AUTH

0xC002002F

RPC_NT_UNKNOWN_AUTHN_SERVICE

0xC0020030

RPC_NT_UNKNOWN_AUTHN_LEVEL

0xC0020031

RPC_NT_INVALID_AUTH_IDENTITY

0xC0020032

RPC_NT_UNKNOWN_AUTHZ_SERVICE

0xC0020033

EPT_NT_INVALID_ENTRY

0xC0020034

EPT_NT_CANT_PERFORM_OP

0xC0020035

EPT_NT_NOT_REGISTERED

0xC0020036

RPC_NT_NOTHING_TO_EXPORT

0xC0020037

RPC_NT_INCOMPLETE_NAME

0xC0020038

RPC_NT_INVALID_VERS_OPTION

0xC0020039

RPC_NT_NO_MORE_MEMBERS

0xC002003A

RPC_NT_NOT_ALL_OBJS_UNEXPORTED

0xC002003B

RPC_NT_INTERFACE_NOT_FOUND

0xC002003C

RPC_NT_ENTRY_ALREADY_EXISTS

0xC002003D

RPC_NT_ENTRY_NOT_FOUND

0xC002003E

RPC_NT_NAME_SERVICE_UNAVAILABLE

0xC002003F

RPC_NT_INVALID_NAF_ID

0xC0020040

RPC_NT_CANNOT_SUPPORT

0xC0020041

RPC_NT_NO_CONTEXT_AVAILABLE

0xC0020042

RPC_NT_INTERNAL_ERROR

0xC0020043

RPC_NT_ZERO_DIVIDE

0xC0020044

RPC_NT_ADDRESS_ERROR

0xC0020045

RPC_NT_FP_DIV_ZERO

0xC0020046

RPC_NT_FP_UNDERFLOW

0xC0020047

RPC_NT_FP_OVERFLOW

0xC0020048

RPC_NT_NO_MORE_ENTRIES

0xC0030001

RPC_NT_SS_CHAR_TRANS_OPEN_FAIL

0xC0030002

RPC_NT_SS_CHAR_TRANS_SHORT_FILE

0xC0030003

RPC_NT_SS_IN_NULL_CONTEXT

0xC0030004

RPC_NT_SS_CONTEXT_MISMATCH

0xC0030005

RPC_NT_SS_CONTEXT_DAMAGED

0xC0030006

RPC_NT_SS_HANDLES_MISMATCH

0xC0030007

RPC_NT_NULL_REF_POINTER

0xC0030009

RPC_NT_ENUM_VALUE_OUT_OF_RANGE

0xC003000A

RPC_NT_BYTE_COUNT_TOO_SMALL

0xC003000B

RPC_NT_BAD_STUB_DATA

0xC003000C

RPC_NT_CALL_IN_PROGRESS

0xC0020049

RPC_NT_NO_MORE_BINDINGS

0xC002004A

RPC_NT_GROUP_MEMBER_NOT_FOUND

0xC002004B

EPT_NT_CANT_CREATE

0xC002004C

RPC_NT_INVALID_OBJECT

0xC002004D

RPC_NT_NO_INTERFACES

0xC002004F

RPC_NT_CALL_CANCELLED

0xC0020050

RPC_NT_BINDING_INCOMPLETE

0xC0020051

RPC_NT_COMM_FAILURE

0xC0020052

RPC_NT_UNSUPPORTED_AUTHN_LEVEL

0xC0020053

RPC_NT_NO_PRINC_NAME

0xC0020054

RPC_NT_NOT_RPC_ERROR

0xC0020055

RPC_NT_UUID_LOCAL_ONLY

0x40020056

RPC_NT_SEC_PKG_ERROR

0xC0020057

RPC_NT_NOT_CANCELLED

0xC0020058

RPC_NT_INVALID_ES_ACTION

0xC0030059

RPC_NT_WRONG_ES_VERSION

0xC003005A

RPC_NT_WRONG_STUB_VERSION

0xC003005B

RPC_NT_INVALID_PIPE_OBJECT

0xC003005C

RPC_NT_INVALID_PIPE_OPERATION

0xC003005D

RPC_NT_WRONG_PIPE_VERSION

0xC003005E

RPC_NT_PIPE_CLOSED

0xC003005F

RPC_NT_PIPE_DISCIPLINE_ERROR

0xC0030060

RPC_NT_PIPE_EMPTY

0xC0030061

RPC_NT_INVALID_ASYNC_HANDLE

0xC0020062

RPC_NT_INVALID_ASYNC_CALL

0xC0020063

RPC_NT_PROXY_ACCESS_DENIED

0xC0020064

RPC_NT_COOKIE_AUTH_FAILED

0xC0020065

RPC_NT_SEND_INCOMPLETE

0x400200AF

STATUS_ACPI_INVALID_OPCODE

0xC0140001

STATUS_ACPI_STACK_OVERFLOW

0xC0140002

STATUS_ACPI_ASSERT_FAILED

0xC0140003

STATUS_ACPI_INVALID_INDEX

0xC0140004

STATUS_ACPI_INVALID_ARGUMENT

0xC0140005

STATUS_ACPI_FATAL

0xC0140006

STATUS_ACPI_INVALID_SUPERNAME

0xC0140007

STATUS_ACPI_INVALID_ARGTYPE

0xC0140008

STATUS_ACPI_INVALID_OBJTYPE

0xC0140009

STATUS_ACPI_INVALID_TARGETTYPE

0xC014000A

STATUS_ACPI_ADDRESS_NOT_MAPPED

0xC014000C

STATUS_ACPI_INVALID_EVENTTYPE

0xC014000D

STATUS_ACPI_HANDLER_COLLISION

0xC014000E

STATUS_ACPI_INVALID_DATA

0xC014000F

STATUS_ACPI_INVALID_REGION

0xC0140010

STATUS_ACPI_INVALID_ACCESS_SIZE

0xC0140011

STATUS_ACPI_ACQUIRE_GLOBAL_LOCK

0xC0140012

STATUS_ACPI_ALREADY_INITIALIZED

0xC0140013

STATUS_ACPI_NOT_INITIALIZED

0xC0140014

STATUS_ACPI_INVALID_MUTEX_LEVEL

0xC0140015

STATUS_ACPI_MUTEX_NOT_OWNED

0xC0140016

STATUS_ACPI_MUTEX_NOT_OWNER

0xC0140017

STATUS_ACPI_RS_ACCESS

0xC0140018

STATUS_ACPI_INVALID_TABLE

0xC0140019

STATUS_ACPI_REG_HANDLER_FAILED

0xC0140020

STATUS_CTX_CDM_CONNECT

0x400A0004

STATUS_CTX_CDM_DISCONNECT

0x400A0005

STATUS_CTX_CLOSE_PENDING

0xC00A0006

STATUS_CTX_NO_OUTBUF

0xC00A0007

STATUS_CTX_MODEM_INF_NOT_FOUND

0xC00A0008

STATUS_CTX_RESPONSE_ERROR

0xC00A000A

STATUS_CTX_MODEM_RESPONSE_BUSY

0xC00A000E

STATUS_CTX_MODEM_RESPONSE_VOICE

0xC00A000F

STATUS_CTX_TD_ERROR

0xC00A0010

STATUS_CTX_LICENSE_EXPIRED

0xC00A0014

STATUS_CTX_WINSTATION_NOT_FOUND

0xC00A0015

STATUS_CTX_WINSTATION_BUSY

0xC00A0017

STATUS_CTX_BAD_VIDEO_MODE

0xC00A0018

STATUS_CTX_GRAPHICS_INVALID

0xC00A0022

STATUS_CTX_NOT_CONSOLE

0xC00A0024

STATUS_CTX_CLIENT_QUERY_TIMEOUT

0xC00A0026

STATUS_CTX_CONSOLE_DISCONNECT

0xC00A0027

STATUS_CTX_CONSOLE_CONNECT

0xC00A0028

STATUS_CTX_SHADOW_DENIED

0xC00A002A

STATUS_CTX_SHADOW_INVALID

0xC00A0030

STATUS_CTX_SHADOW_DISABLED

0xC00A0031

STATUS_CTX_SHADOW_NOT_RUNNING

0xC00A0036

STATUS_CTX_LOGON_DISABLED

0xC00A0037

STATUS_TS_INCOMPATIBLE_SESSIONS

0xC00A0039

STATUS_TS_VIDEO_SUBSYSTEM_ERROR

0xC00A003A

STATUS_PNP_BAD_MPS_TABLE

0xC0040035

STATUS_PNP_TRANSLATION_FAILED

0xC0040036

STATUS_IO_REISSUE_AS_CACHED

0xC0040039

STATUS_MUI_FILE_NOT_FOUND

0xC00B0001

STATUS_MUI_INVALID_FILE

0xC00B0002

STATUS_MUI_INVALID_RC_CONFIG

0xC00B0003

STATUS_MUI_INVALID_LOCALE_NAME

0xC00B0004

STATUS_MUI_FILE_NOT_LOADED

0xC00B0006

STATUS_RESOURCE_ENUM_USER_STOP

0xC00B0007

STATUS_FLT_NO_HANDLER_DEFINED

0xC01C0001

STATUS_FLT_DISALLOW_FAST_IO

0xC01C0004

STATUS_FLT_INVALID_NAME_REQUEST

0xC01C0005

STATUS_FLT_NOT_INITIALIZED

0xC01C0007

STATUS_FLT_FILTER_NOT_READY

0xC01C0008

STATUS_FLT_INTERNAL_ERROR

0xC01C000A

STATUS_FLT_DELETING_OBJECT

0xC01C000B

STATUS_FLT_DUPLICATE_ENTRY

0xC01C000D

STATUS_FLT_CBDQ_DISABLED

0xC01C000E

STATUS_FLT_DO_NOT_ATTACH

0xC01C000F

STATUS_FLT_DO_NOT_DETACH

0xC01C0010

STATUS_FLT_FILTER_NOT_FOUND

0xC01C0013

STATUS_FLT_VOLUME_NOT_FOUND

0xC01C0014

STATUS_FLT_INSTANCE_NOT_FOUND

0xC01C0015

STATUS_FLT_NAME_CACHE_MISS

0xC01C0018

STATUS_FLT_NO_DEVICE_OBJECT

0xC01C0019

STATUS_FLT_ALREADY_ENLISTED

0xC01C001B

STATUS_FLT_NO_WAITER_FOR_REPLY

0xC01C0020

STATUS_FLT_REGISTRATION_BUSY

0xC01C0023

STATUS_SXS_SECTION_NOT_FOUND

0xC0150001

STATUS_SXS_CANT_GEN_ACTCTX

0xC0150002

STATUS_SXS_ASSEMBLY_NOT_FOUND

0xC0150004

STATUS_SXS_MANIFEST_PARSE_ERROR

0xC0150006

STATUS_SXS_KEY_NOT_FOUND

0xC0150008

STATUS_SXS_VERSION_CONFLICT

0xC0150009

STATUS_SXS_WRONG_SECTION_TYPE

0xC015000A

STATUS_SXS_ASSEMBLY_MISSING

0xC015000C

STATUS_SXS_EARLY_DEACTIVATION

0xC015000F

STATUS_SXS_INVALID_DEACTIVATION

0xC0150010

STATUS_SXS_CORRUPTION

0xC0150015

STATUS_SXS_IDENTITY_PARSE_ERROR

0xC0150019

STATUS_SXS_FILE_HASH_MISMATCH

0xC015001B

STATUS_SXS_IDENTITIES_DIFFERENT

0xC015001D

STATUS_XML_ENCODING_MISMATCH

0xC0150021

STATUS_SXS_MANIFEST_TOO_BIG

0xC0150022

STATUS_GENERIC_COMMAND_FAILED

0xC0150026

STATUS_SXS_FILE_HASH_MISSING

0xC0150027

STATUS_CLUSTER_INVALID_NODE

0xC0130001

STATUS_CLUSTER_NODE_EXISTS

0xC0130002

STATUS_CLUSTER_JOIN_IN_PROGRESS

0xC0130003

STATUS_CLUSTER_NODE_NOT_FOUND

0xC0130004

STATUS_CLUSTER_NETWORK_EXISTS

0xC0130006

STATUS_CLUSTER_INVALID_REQUEST

0xC013000A

STATUS_CLUSTER_NODE_DOWN

0xC013000C

STATUS_CLUSTER_NODE_UNREACHABLE

0xC013000D

STATUS_CLUSTER_NODE_NOT_MEMBER

0xC013000E

STATUS_CLUSTER_INVALID_NETWORK

0xC0130010

STATUS_CLUSTER_NO_NET_ADAPTERS

0xC0130011

STATUS_CLUSTER_NODE_UP

0xC0130012

STATUS_CLUSTER_NODE_PAUSED

0xC0130013

STATUS_CLUSTER_NODE_NOT_PAUSED

0xC0130014

STATUS_CLUSTER_POISONED

0xC0130017

STATUS_CLUSTER_NON_CSV_PATH

0xC0130018

STATUS_CLUSTER_CSV_REDIRECTED

0xC0130022

STATUS_TRANSACTIONAL_CONFLICT

0xC0190001

STATUS_INVALID_TRANSACTION

0xC0190002

STATUS_TRANSACTION_NOT_ACTIVE

0xC0190003

STATUS_TM_INITIALIZATION_FAILED

0xC0190004

STATUS_RM_NOT_ACTIVE

0xC0190005

STATUS_RM_METADATA_CORRUPT

0xC0190006

STATUS_TRANSACTION_NOT_JOINED

0xC0190007

STATUS_DIRECTORY_NOT_RM

0xC0190008

STATUS_COULD_NOT_RESIZE_LOG

0x80190009

STATUS_LOG_RESIZE_INVALID_SIZE

0xC019000B

STATUS_CRM_PROTOCOL_NOT_FOUND

0xC0190011

STATUS_LOG_GROWTH_FAILED

0xC0190019

STATUS_OBJECT_NO_LONGER_EXISTS

0xC0190021

STATUS_HANDLE_NO_LONGER_VALID

0xC0190028

STATUS_NO_TXF_METADATA

0x80190029

STATUS_LOG_CORRUPTION_DETECTED

0xC0190030

STATUS_RM_DISCONNECTED

0xC0190032

STATUS_ENLISTMENT_NOT_SUPERIOR

0xC0190033

STATUS_RECOVERY_NOT_NEEDED

0x40190034

STATUS_RM_ALREADY_STARTED

0x40190035

STATUS_CANT_CROSS_RM_BOUNDARY

0xC0190038

STATUS_TXF_DIR_NOT_EMPTY

0xC0190039

STATUS_TM_VOLATILE

0xC019003B

STATUS_ROLLBACK_TIMER_EXPIRED

0xC019003C

STATUS_TXF_ATTRIBUTE_CORRUPT

0xC019003D

STATUS_TRANSACTIONS_NOT_FROZEN

0xC0190045

STATUS_NOT_SNAPSHOT_VOLUME

0xC0190047

STATUS_TM_IDENTITY_MISMATCH

0xC019004A

STATUS_FLOATED_SECTION

0xC019004B

STATUS_TRANSACTION_NOT_FOUND

0xC019004E

STATUS_ENLISTMENT_NOT_FOUND

0xC0190050

STATUS_TRANSACTION_NOT_ROOT

0xC0190054

STATUS_TRANSACTION_NO_SUPERIOR

0xC019005F

STATUS_EXPIRED_HANDLE

0xC0190060

STATUS_TRANSACTION_NOT_ENLISTED

0xC0190061

STATUS_LOG_SECTOR_INVALID

0xC01A0001

STATUS_LOG_SECTOR_REMAPPED

0xC01A0003

STATUS_LOG_BLOCK_INCOMPLETE

0xC01A0004

STATUS_LOG_INVALID_RANGE

0xC01A0005

STATUS_LOG_BLOCKS_EXHAUSTED

0xC01A0006

STATUS_LOG_READ_CONTEXT_INVALID

0xC01A0007

STATUS_LOG_RESTART_INVALID

0xC01A0008

STATUS_LOG_BLOCK_VERSION

0xC01A0009

STATUS_LOG_BLOCK_INVALID

0xC01A000A

STATUS_LOG_READ_MODE_INVALID

0xC01A000B

STATUS_LOG_NO_RESTART

0x401A000C

STATUS_LOG_METADATA_CORRUPT

0xC01A000D

STATUS_LOG_METADATA_INVALID

0xC01A000E

STATUS_LOG_RESERVATION_INVALID

0xC01A0010

STATUS_LOG_CANT_DELETE

0xC01A0011

STATUS_LOG_START_OF_LOG

0xC01A0013

STATUS_LOG_POLICY_NOT_INSTALLED

0xC01A0015

STATUS_LOG_POLICY_INVALID

0xC01A0016

STATUS_LOG_POLICY_CONFLICT

0xC01A0017

STATUS_LOG_PINNED_ARCHIVE_TAIL

0xC01A0018

STATUS_LOG_RECORD_NONEXISTENT

0xC01A0019

STATUS_LOG_TAIL_INVALID

0xC01A001C

STATUS_LOG_FULL

0xC01A001D

STATUS_LOG_MULTIPLEXED

0xC01A001E

STATUS_LOG_DEDICATED

0xC01A001F

STATUS_LOG_ARCHIVE_IN_PROGRESS

0xC01A0021

STATUS_LOG_EPHEMERAL

0xC01A0022

STATUS_LOG_STATE_INVALID

0xC01A002B

STATUS_LOG_PINNED

0xC01A002C

STATUS_LOG_PINNED_RESERVATION

0xC01A0030

STATUS_MONITOR_NO_DESCRIPTOR

0xC01D0001

STATUS_GRAPHICS_PRESENT_DENIED

0xC01E0007

STATUS_GRAPHICS_DRIVER_MISMATCH

0xC01E0009

STATUS_GRAPHICS_NO_VIDEO_MEMORY

0xC01E0100

STATUS_GRAPHICS_ALLOCATION_BUSY

0xC01E0102

STATUS_GRAPHICS_TRY_AGAIN_LATER

0xC01E0104

STATUS_GRAPHICS_TRY_AGAIN_NOW

0xC01E0105

STATUS_GRAPHICS_INVALID_VIDPN

0xC01E0303

STATUS_GRAPHICS_MODE_NOT_PINNED

0x401E0307

STATUS_GRAPHICS_STALE_MODESET

0xC01E0320

STATUS_GRAPHICS_NO_VIDPNMGR

0xC01E0335

STATUS_GRAPHICS_NO_ACTIVE_VIDPN

0xC01E0336

STATUS_GRAPHICS_INVALID_STRIDE

0xC01E033C

STATUS_GRAPHICS_START_DEFERRED

0x401E043A

STATUS_GRAPHICS_PVP_HFS_FAILED

0xC01E0511

STATUS_GRAPHICS_OPM_INVALID_SRM

0xC01E0512

STATUS_GRAPHICS_INVALID_POINTER

0xC01E05E4

STATUS_GRAPHICS_INTERNAL_ERROR

0xC01E05E7

STATUS_FVE_LOCKED_VOLUME

0xC0210000

STATUS_FVE_NOT_ENCRYPTED

0xC0210001

STATUS_FVE_BAD_INFORMATION

0xC0210002

STATUS_FVE_TOO_SMALL

0xC0210003

STATUS_FVE_FAILED_WRONG_FS

0xC0210004

STATUS_FVE_BAD_PARTITION_SIZE

0xC0210005

STATUS_FVE_FS_NOT_EXTENDED

0xC0210006

STATUS_FVE_FS_MOUNTED

0xC0210007

STATUS_FVE_NO_LICENSE

0xC0210008

STATUS_FVE_ACTION_NOT_ALLOWED

0xC0210009

STATUS_FVE_BAD_DATA

0xC021000A

STATUS_FVE_VOLUME_NOT_BOUND

0xC021000B

STATUS_FVE_NOT_DATA_VOLUME

0xC021000C

STATUS_FVE_CONV_READ_ERROR

0xC021000D

STATUS_FVE_CONV_WRITE_ERROR

0xC021000E

STATUS_FVE_OVERLAPPED_UPDATE

0xC021000F

STATUS_FVE_FAILED_SECTOR_SIZE

0xC0210010

STATUS_FVE_NOT_OS_VOLUME

0xC0210012

STATUS_FVE_KEYFILE_NOT_FOUND

0xC0210013

STATUS_FVE_KEYFILE_INVALID

0xC0210014

STATUS_FVE_KEYFILE_NO_VMK

0xC0210015

STATUS_FVE_TPM_DISABLED

0xC0210016

STATUS_FVE_TPM_INVALID_PCR

0xC0210018

STATUS_FVE_TPM_NO_VMK

0xC0210019

STATUS_FVE_PIN_INVALID

0xC021001A

STATUS_FVE_AUTH_INVALID_CONFIG

0xC021001C

STATUS_FVE_DEBUGGER_ENABLED

0xC021001D

STATUS_FVE_DRY_RUN_FAILED

0xC021001E

STATUS_FVE_BAD_METADATA_POINTER

0xC021001F

STATUS_FVE_OLD_METADATA_COPY

0xC0210020

STATUS_FVE_REBOOT_REQUIRED

0xC0210021

STATUS_FVE_RAW_ACCESS

0xC0210022

STATUS_FVE_RAW_BLOCKED

0xC0210023

STATUS_FVE_MOR_FAILED

0xC0210025

STATUS_FVE_NO_FEATURE_LICENSE

0xC0210026

STATUS_FVE_CONV_RECOVERY_FAILED

0xC0210028

STATUS_FVE_INVALID_DATUM_TYPE

0xC021002A

STATUS_FVE_VOLUME_TOO_SMALL

0xC0210030

STATUS_FVE_ENH_PIN_INVALID

0xC0210031

STATUS_FVE_SECUREBOOT_DISABLED

0xC0210039

STATUS_FVE_DEVICE_LOCKEDOUT

0xC021003B

STATUS_FWP_CALLOUT_NOT_FOUND

0xC0220001

STATUS_FWP_CONDITION_NOT_FOUND

0xC0220002

STATUS_FWP_FILTER_NOT_FOUND

0xC0220003

STATUS_FWP_LAYER_NOT_FOUND

0xC0220004

STATUS_FWP_PROVIDER_NOT_FOUND

0xC0220005

STATUS_FWP_SUBLAYER_NOT_FOUND

0xC0220007

STATUS_FWP_NOT_FOUND

0xC0220008

STATUS_FWP_ALREADY_EXISTS

0xC0220009

STATUS_FWP_IN_USE

0xC022000A

STATUS_FWP_WRONG_SESSION

0xC022000C

STATUS_FWP_NO_TXN_IN_PROGRESS

0xC022000D

STATUS_FWP_TXN_IN_PROGRESS

0xC022000E

STATUS_FWP_TXN_ABORTED

0xC022000F

STATUS_FWP_SESSION_ABORTED

0xC0220010

STATUS_FWP_INCOMPATIBLE_TXN

0xC0220011

STATUS_FWP_TIMEOUT

0xC0220012

STATUS_FWP_NET_EVENTS_DISABLED

0xC0220013

STATUS_FWP_INCOMPATIBLE_LAYER

0xC0220014

STATUS_FWP_KM_CLIENTS_ONLY

0xC0220015

STATUS_FWP_LIFETIME_MISMATCH

0xC0220016

STATUS_FWP_BUILTIN_OBJECT

0xC0220017

STATUS_FWP_TOO_MANY_CALLOUTS

0xC0220018

STATUS_FWP_NOTIFICATION_DROPPED

0xC0220019

STATUS_FWP_TRAFFIC_MISMATCH

0xC022001A

STATUS_FWP_NULL_POINTER

0xC022001C

STATUS_FWP_INVALID_ENUMERATOR

0xC022001D

STATUS_FWP_INVALID_FLAGS

0xC022001E

STATUS_FWP_INVALID_NET_MASK

0xC022001F

STATUS_FWP_INVALID_RANGE

0xC0220020

STATUS_FWP_INVALID_INTERVAL

0xC0220021

STATUS_FWP_ZERO_LENGTH_ARRAY

0xC0220022

STATUS_FWP_NULL_DISPLAY_NAME

0xC0220023

STATUS_FWP_INVALID_ACTION_TYPE

0xC0220024

STATUS_FWP_INVALID_WEIGHT

0xC0220025

STATUS_FWP_MATCH_TYPE_MISMATCH

0xC0220026

STATUS_FWP_TYPE_MISMATCH

0xC0220027

STATUS_FWP_OUT_OF_BOUNDS

0xC0220028

STATUS_FWP_RESERVED

0xC0220029

STATUS_FWP_DUPLICATE_CONDITION

0xC022002A

STATUS_FWP_DUPLICATE_KEYMOD

0xC022002B

STATUS_FWP_EM_NOT_SUPPORTED

0xC0220032

STATUS_FWP_NEVER_MATCH

0xC0220033

STATUS_FWP_INVALID_PARAMETER

0xC0220035

STATUS_FWP_TOO_MANY_SUBLAYERS

0xC0220036

STATUS_FWP_L2_DRIVER_NOT_READY

0xC022003E

STATUS_FWP_CONNECTIONS_DISABLED

0xC0220041

STATUS_FWP_INVALID_DNS_NAME

0xC0220042

STATUS_FWP_STILL_ON

0xC0220043

STATUS_FWP_IKEEXT_NOT_RUNNING

0xC0220044

STATUS_FWP_TCPIP_NOT_READY

0xC0220100

STATUS_FWP_INJECT_HANDLE_STALE

0xC0220102

STATUS_FWP_CANNOT_PEND

0xC0220103

STATUS_FWP_DROP_NOICMP

0xC0220104

STATUS_NDIS_CLOSING

0xC0230002

STATUS_NDIS_BAD_VERSION

0xC0230004

STATUS_NDIS_BAD_CHARACTERISTICS

0xC0230005

STATUS_NDIS_ADAPTER_NOT_FOUND

0xC0230006

STATUS_NDIS_OPEN_FAILED

0xC0230007

STATUS_NDIS_DEVICE_FAILED

0xC0230008

STATUS_NDIS_MULTICAST_FULL

0xC0230009

STATUS_NDIS_MULTICAST_EXISTS

0xC023000A

STATUS_NDIS_MULTICAST_NOT_FOUND

0xC023000B

STATUS_NDIS_REQUEST_ABORTED

0xC023000C

STATUS_NDIS_RESET_IN_PROGRESS

0xC023000D

STATUS_NDIS_NOT_SUPPORTED

0xC02300BB

STATUS_NDIS_INVALID_PACKET

0xC023000F

STATUS_NDIS_ADAPTER_NOT_READY

0xC0230011

STATUS_NDIS_INVALID_LENGTH

0xC0230014

STATUS_NDIS_INVALID_DATA

0xC0230015

STATUS_NDIS_BUFFER_TOO_SHORT

0xC0230016

STATUS_NDIS_INVALID_OID

0xC0230017

STATUS_NDIS_ADAPTER_REMOVED

0xC0230018

STATUS_NDIS_UNSUPPORTED_MEDIA

0xC0230019

STATUS_NDIS_FILE_NOT_FOUND

0xC023001B

STATUS_NDIS_ERROR_READING_FILE

0xC023001C

STATUS_NDIS_ALREADY_MAPPED

0xC023001D

STATUS_NDIS_RESOURCE_CONFLICT

0xC023001E

STATUS_NDIS_MEDIA_DISCONNECTED

0xC023001F

STATUS_NDIS_INVALID_ADDRESS

0xC0230022

STATUS_NDIS_PAUSED

0xC023002A

STATUS_NDIS_INTERFACE_NOT_FOUND

0xC023002B

STATUS_NDIS_INVALID_PORT

0xC023002D

STATUS_NDIS_INVALID_PORT_STATE

0xC023002E

STATUS_NDIS_LOW_POWER_STATE

0xC023002F

STATUS_NDIS_REINIT_REQUIRED

0xC0230030

STATUS_NDIS_DOT11_MEDIA_IN_USE

0xC0232001

STATUS_NDIS_INDICATION_REQUIRED

0x40230001

STATUS_NDIS_OFFLOAD_POLICY

0xC023100F

STATUS_TPM_ERROR_MASK

0xC0290000

STATUS_TPM_AUTHFAIL

0xC0290001

STATUS_TPM_BADINDEX

0xC0290002

STATUS_TPM_BAD_PARAMETER

0xC0290003

STATUS_TPM_AUDITFAILURE

0xC0290004

STATUS_TPM_CLEAR_DISABLED

0xC0290005

STATUS_TPM_DEACTIVATED

0xC0290006

STATUS_TPM_DISABLED

0xC0290007

STATUS_TPM_DISABLED_CMD

0xC0290008

STATUS_TPM_FAIL

0xC0290009

STATUS_TPM_BAD_ORDINAL

0xC029000A

STATUS_TPM_INSTALL_DISABLED

0xC029000B

STATUS_TPM_INVALID_KEYHANDLE

0xC029000C

STATUS_TPM_KEYNOTFOUND

0xC029000D

STATUS_TPM_INAPPROPRIATE_ENC

0xC029000E

STATUS_TPM_MIGRATEFAIL

0xC029000F

STATUS_TPM_INVALID_PCR_INFO

0xC0290010

STATUS_TPM_NOSPACE

0xC0290011

STATUS_TPM_NOSRK

0xC0290012

STATUS_TPM_NOTSEALED_BLOB

0xC0290013

STATUS_TPM_OWNER_SET

0xC0290014

STATUS_TPM_RESOURCES

0xC0290015

STATUS_TPM_SHORTRANDOM

0xC0290016

STATUS_TPM_SIZE

0xC0290017

STATUS_TPM_WRONGPCRVAL

0xC0290018

STATUS_TPM_BAD_PARAM_SIZE

0xC0290019

STATUS_TPM_SHA_THREAD

0xC029001A

STATUS_TPM_SHA_ERROR

0xC029001B

STATUS_TPM_FAILEDSELFTEST

0xC029001C

STATUS_TPM_AUTH2FAIL

0xC029001D

STATUS_TPM_BADTAG

0xC029001E

STATUS_TPM_IOERROR

0xC029001F

STATUS_TPM_ENCRYPT_ERROR

0xC0290020

STATUS_TPM_DECRYPT_ERROR

0xC0290021

STATUS_TPM_INVALID_AUTHHANDLE

0xC0290022

STATUS_TPM_NO_ENDORSEMENT

0xC0290023

STATUS_TPM_INVALID_KEYUSAGE

0xC0290024

STATUS_TPM_WRONG_ENTITYTYPE

0xC0290025

STATUS_TPM_INVALID_POSTINIT

0xC0290026

STATUS_TPM_INAPPROPRIATE_SIG

0xC0290027

STATUS_TPM_BAD_KEY_PROPERTY

0xC0290028

STATUS_TPM_BAD_MIGRATION

0xC0290029

STATUS_TPM_BAD_SCHEME

0xC029002A

STATUS_TPM_BAD_DATASIZE

0xC029002B

STATUS_TPM_BAD_MODE

0xC029002C

STATUS_TPM_BAD_PRESENCE

0xC029002D

STATUS_TPM_BAD_VERSION

0xC029002E

STATUS_TPM_NO_WRAP_TRANSPORT

0xC029002F

STATUS_TPM_AUDITFAIL_SUCCESSFUL

0xC0290031

STATUS_TPM_NOTRESETABLE

0xC0290032

STATUS_TPM_NOTLOCAL

0xC0290033

STATUS_TPM_BAD_TYPE

0xC0290034

STATUS_TPM_INVALID_RESOURCE

0xC0290035

STATUS_TPM_NOTFIPS

0xC0290036

STATUS_TPM_INVALID_FAMILY

0xC0290037

STATUS_TPM_NO_NV_PERMISSION

0xC0290038

STATUS_TPM_REQUIRES_SIGN

0xC0290039

STATUS_TPM_KEY_NOTSUPPORTED

0xC029003A

STATUS_TPM_AUTH_CONFLICT

0xC029003B

STATUS_TPM_AREA_LOCKED

0xC029003C

STATUS_TPM_BAD_LOCALITY

0xC029003D

STATUS_TPM_READ_ONLY

0xC029003E

STATUS_TPM_PER_NOWRITE

0xC029003F

STATUS_TPM_FAMILYCOUNT

0xC0290040

STATUS_TPM_WRITE_LOCKED

0xC0290041

STATUS_TPM_BAD_ATTRIBUTES

0xC0290042

STATUS_TPM_INVALID_STRUCTURE

0xC0290043

STATUS_TPM_KEY_OWNER_CONTROL

0xC0290044

STATUS_TPM_BAD_COUNTER

0xC0290045

STATUS_TPM_NOT_FULLWRITE

0xC0290046

STATUS_TPM_CONTEXT_GAP

0xC0290047

STATUS_TPM_MAXNVWRITES

0xC0290048

STATUS_TPM_NOOPERATOR

0xC0290049

STATUS_TPM_RESOURCEMISSING

0xC029004A

STATUS_TPM_DELEGATE_LOCK

0xC029004B

STATUS_TPM_DELEGATE_FAMILY

0xC029004C

STATUS_TPM_DELEGATE_ADMIN

0xC029004D

STATUS_TPM_OWNER_CONTROL

0xC029004F

STATUS_TPM_DAA_RESOURCES

0xC0290050

STATUS_TPM_DAA_INPUT_DATA0

0xC0290051

STATUS_TPM_DAA_INPUT_DATA1

0xC0290052

STATUS_TPM_DAA_ISSUER_SETTINGS

0xC0290053

STATUS_TPM_DAA_TPM_SETTINGS

0xC0290054

STATUS_TPM_DAA_STAGE

0xC0290055

STATUS_TPM_DAA_ISSUER_VALIDITY

0xC0290056

STATUS_TPM_DAA_WRONG_W

0xC0290057

STATUS_TPM_BAD_HANDLE

0xC0290058

STATUS_TPM_BAD_DELEGATE

0xC0290059

STATUS_TPM_BADCONTEXT

0xC029005A

STATUS_TPM_TOOMANYCONTEXTS

0xC029005B

STATUS_TPM_MA_TICKET_SIGNATURE

0xC029005C

STATUS_TPM_MA_DESTINATION

0xC029005D

STATUS_TPM_MA_SOURCE

0xC029005E

STATUS_TPM_MA_AUTHORITY

0xC029005F

STATUS_TPM_PERMANENTEK

0xC0290061

STATUS_TPM_BAD_SIGNATURE

0xC0290062

STATUS_TPM_NOCONTEXTSPACE

0xC0290063

STATUS_TPM_COMMAND_BLOCKED

0xC0290400

STATUS_TPM_INVALID_HANDLE

0xC0290401

STATUS_TPM_DUPLICATE_VHANDLE

0xC0290402

STATUS_TPM_RETRY

0xC0290800

STATUS_TPM_NEEDS_SELFTEST

0xC0290801

STATUS_TPM_DOING_SELFTEST

0xC0290802

STATUS_TPM_DEFEND_LOCK_RUNNING

0xC0290803

STATUS_TPM_COMMAND_CANCELED

0xC0291001

STATUS_TPM_TOO_MANY_CONTEXTS

0xC0291002

STATUS_TPM_NOT_FOUND

0xC0291003

STATUS_TPM_ACCESS_DENIED

0xC0291004

STATUS_TPM_INSUFFICIENT_BUFFER

0xC0291005

STATUS_PCP_ERROR_MASK

0xC0292000

STATUS_PCP_DEVICE_NOT_READY

0xC0292001

STATUS_PCP_INVALID_HANDLE

0xC0292002

STATUS_PCP_INVALID_PARAMETER

0xC0292003

STATUS_PCP_FLAG_NOT_SUPPORTED

0xC0292004

STATUS_PCP_NOT_SUPPORTED

0xC0292005

STATUS_PCP_BUFFER_TOO_SMALL

0xC0292006

STATUS_PCP_INTERNAL_ERROR

0xC0292007

STATUS_PCP_POLICY_NOT_FOUND

0xC029200A

STATUS_PCP_PROFILE_NOT_FOUND

0xC029200B

STATUS_PCP_VALIDATION_FAILED

0xC029200C

STATUS_HV_INVALID_ALIGNMENT

0xC0350004

STATUS_HV_INVALID_PARAMETER

0xC0350005

STATUS_HV_ACCESS_DENIED

0xC0350006

STATUS_HV_OPERATION_DENIED

0xC0350008

STATUS_HV_UNKNOWN_PROPERTY

0xC0350009

STATUS_HV_INSUFFICIENT_MEMORY

0xC035000B

STATUS_HV_PARTITION_TOO_DEEP

0xC035000C

STATUS_HV_INVALID_PARTITION_ID

0xC035000D

STATUS_HV_INVALID_VP_INDEX

0xC035000E

STATUS_HV_INVALID_PORT_ID

0xC0350011

STATUS_HV_INVALID_CONNECTION_ID

0xC0350012

STATUS_HV_INSUFFICIENT_BUFFERS

0xC0350013

STATUS_HV_NOT_ACKNOWLEDGED

0xC0350014

STATUS_HV_ACKNOWLEDGED

0xC0350016

STATUS_HV_INVALID_SYNIC_STATE

0xC0350018

STATUS_HV_OBJECT_IN_USE

0xC0350019

STATUS_HV_NO_DATA

0xC035001B

STATUS_HV_INACTIVE

0xC035001C

STATUS_HV_NO_RESOURCES

0xC035001D

STATUS_HV_FEATURE_UNAVAILABLE

0xC035001E

STATUS_HV_INVALID_LP_INDEX

0xC0350041

STATUS_HV_NOT_PRESENT

0xC0351000

STATUS_VID_DUPLICATE_HANDLER

0xC0370001

STATUS_VID_TOO_MANY_HANDLERS

0xC0370002

STATUS_VID_QUEUE_FULL

0xC0370003

STATUS_VID_HANDLER_NOT_PRESENT

0xC0370004

STATUS_VID_INVALID_OBJECT_NAME

0xC0370005

STATUS_VID_MB_STILL_REFERENCED

0xC037000D

STATUS_VID_PAGE_RANGE_OVERFLOW

0xC0370013

STATUS_VID_INVALID_PPM_HANDLE

0xC0370018

STATUS_VID_MBPS_ARE_LOCKED

0xC0370019

STATUS_VID_MESSAGE_QUEUE_CLOSED

0xC037001A

STATUS_VID_STOP_PENDING

0xC037001C

STATUS_VID_MMIO_RANGE_DESTROYED

0xC0370021

STATUS_VID_SAVED_STATE_CORRUPT

0xC0370027

STATUS_IPSEC_BAD_SPI

0xC0360001

STATUS_IPSEC_WRONG_SA

0xC0360003

STATUS_IPSEC_INVALID_PACKET

0xC0360005

STATUS_IPSEC_CLEAR_TEXT_DROP

0xC0360007

STATUS_IPSEC_AUTH_FIREWALL_DROP

0xC0360008

STATUS_IPSEC_THROTTLE_DROP

0xC0360009

STATUS_IPSEC_DOSP_BLOCK

0xC0368000

STATUS_IPSEC_DOSP_MAX_ENTRIES

0xC0368004

STATUS_VOLMGR_DATABASE_FULL

0xC0380001

STATUS_VOLMGR_DISK_DUPLICATE

0xC0380006

STATUS_VOLMGR_DISK_DYNAMIC

0xC0380007

STATUS_VOLMGR_DISK_ID_INVALID

0xC0380008

STATUS_VOLMGR_DISK_INVALID

0xC0380009

STATUS_VOLMGR_DISK_LAST_VOTER

0xC038000A

STATUS_VOLMGR_DISK_MISSING

0xC0380011

STATUS_VOLMGR_DISK_NOT_EMPTY

0xC0380012

STATUS_VOLMGR_MEMBER_IN_SYNC

0xC0380023

STATUS_VOLMGR_MEMBER_MISSING

0xC0380026

STATUS_VOLMGR_ALL_DISKS_FAILED

0xC0380029

STATUS_VOLMGR_NO_SUCH_USER

0xC038002B

STATUS_VOLMGR_PACK_DUPLICATE

0xC038002F

STATUS_VOLMGR_PACK_ID_INVALID

0xC0380030

STATUS_VOLMGR_PACK_INVALID

0xC0380031

STATUS_VOLMGR_PACK_NAME_INVALID

0xC0380032

STATUS_VOLMGR_PACK_OFFLINE

0xC0380033

STATUS_VOLMGR_PACK_HAS_QUORUM

0xC0380034

STATUS_VOLMGR_PLEX_IN_SYNC

0xC0380038

STATUS_VOLMGR_PLEX_LAST_ACTIVE

0xC038003B

STATUS_VOLMGR_PLEX_MISSING

0xC038003C

STATUS_VOLMGR_PLEX_REGENERATING

0xC038003D

STATUS_VOLMGR_PLEX_TYPE_INVALID

0xC038003E

STATUS_VOLMGR_PLEX_NOT_RAID5

0xC038003F

STATUS_VOLMGR_PLEX_NOT_SIMPLE

0xC0380040

STATUS_VOLMGR_VOLUME_ID_INVALID

0xC0380046

STATUS_VOLMGR_VOLUME_OFFLINE

0xC038004B

STATUS_VOLMGR_VOLUME_RETAINED

0xC038004C

STATUS_VOLMGR_BAD_BOOT_DISK

0xC038004F

STATUS_VOLMGR_NOT_PRIMARY_PACK

0xC0380052

STATUS_VOLMGR_VOLUME_MIRRORED

0xC0380056

STATUS_BCD_TOO_MANY_ELEMENTS

0xC0390002

STATUS_VHD_DRIVE_FOOTER_MISSING

0xC03A0001

STATUS_VHD_DRIVE_FOOTER_CORRUPT

0xC03A0003

STATUS_VHD_FORMAT_UNKNOWN

0xC03A0004

STATUS_VHD_INVALID_BLOCK_SIZE

0xC03A000B

STATUS_VHD_BITMAP_MISMATCH

0xC03A000C

STATUS_VHD_PARENT_VHD_NOT_FOUND

0xC03A000D

STATUS_VHD_INVALID_SIZE

0xC03A0012

STATUS_VHD_INVALID_FILE_SIZE

0xC03A0013

STATUS_VIRTUAL_DISK_LIMITATION

0xC03A001A

STATUS_VHD_INVALID_TYPE

0xC03A001B

STATUS_VHD_INVALID_STATE

0xC03A001C

STATUS_VHD_METADATA_FULL

0xC03A0028

STATUS_QUERY_STORAGE_ERROR

0x803A0001

STATUS_DIS_NOT_PRESENT

0xC03C0001

STATUS_DIS_ATTRIBUTE_NOT_FOUND

0xC03C0002

STATUS_DIS_PARTIAL_DATA

0xC03C0004

STATUS_RKF_KEY_NOT_FOUND

0xC0400001

STATUS_RKF_DUPLICATE_KEY

0xC0400002

STATUS_RKF_BLOB_FULL

0xC0400003

STATUS_RKF_STORE_FULL

0xC0400004

STATUS_RKF_FILE_BLOCKED

0xC0400005

STATUS_RKF_ACTIVE_KEY

0xC0400006

STATUS_RDBSS_RESTART_OPERATION

0xC0410001

STATUS_RDBSS_CONTINUE_OPERATION

0xC0410002

STATUS_RDBSS_POST_OPERATION

0xC0410003

STATUS_BTH_ATT_INVALID_HANDLE

0xC0420001

STATUS_BTH_ATT_INVALID_PDU

0xC0420004

STATUS_BTH_ATT_INVALID_OFFSET

0xC0420007

STATUS_BTH_ATT_UNLIKELY

0xC042000E

STATUS_BTH_ATT_UNKNOWN_ERROR

0xC0421000

STATUS_SECUREBOOT_NOT_ENABLED

0x80430006

STATUS_SECUREBOOT_FILE_REPLACED

0xC0430007

STATUS_SPACES_NOT_ENOUGH_DRIVES

0xC0E7000B

Chaînes Unicode

De nombreuses fonctions Windows oeuvrant de concert avec des chaînes attendent une structure de type UNICODE_STRING.

typedef struct _UNICODE_STRING { 
  USHORT Length;
  USHORT MaximumLength;
  PWCH Buffer;
} UNICODE_STRING;
typedef UNICODE_STRING *PUNICODE_STRING; 
typedef const UNICODE_STRING *PCUNICODE_STRING;

L’attribut Length indique le nombre d’octets que totalise la chaîne. Cette valeur ne tient pas compte du caractère nul de terminaison - lequel n’est dans la perspective Unicode pas obligatoire. L’attribut MaximumLength enregistre le nombre jusqu’auquel peut croitre la chaine sans nécessiter un relogement mémoire. Cela inclut la taille de la chaîne plus un octet pour le caractère nul de terminaison, s’il existe. Enfin, l’attribut Buffer mémorise l’adresse de départ du tampon concerné.

Le tableau suivant répertorie certaines des fonctions courantes utilisables avec des chaînes Unicode.

Opération Fonction Unicode Équivalent ANSI

Mesure

wcslen

strlen

Concaténation

RtlAppendUnicodeToString, RtlAppendUnicodeStringToString, wcscat

strcat

Copie

RtlCopyUnicodeString, wcscpy

RtlCopyString, strcpy

Comparaison

RtlCompareUnicodeString

RtlCompareString

Inversion

_wcsrev

_strrev

Initialisation

RtlInitUnicodeString

RtlInitAnsiString, RtlInitString

Conversion

RtlUnicodeStringToAnsiString

RtlAnsiStringToUnicodeString

Libération

RtlFreeUnicodeString

RtlFreeAnsiString

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 6. 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. Exécuter une console pour un ordinateur distant

De nombreuses consoles MMC prédéfinies sont configurées pour fonctionner sur la station de travail locale par défaut, mais peuvent aussi - moyennant les autorisations appropriées - être employées pour gérer des ordinateurs distants. Dans un tel cas de figure, utilisez la syntaxe de ligne de commande suivante : console.msc /computer=nomordinateur.

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ées 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

Pour que Windows puisse fonctionner avec un matériel donné, il lui faut un pilote de périphérique adéquat. Au plus haut degré d’abstraction, les pilotes sont des programmes de contrôle qui s’intègrent nativement au système d’exploitation et orchestrent les tâches essentielles de communication relatives aux 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. Après installation d’un périphérique matériel, son pilote se charge automatiquement et s’exécute comme partie intégrante du système d’exploitation.

Les pilotes 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 7. 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

Pour repérer facilement différentes ressources au sein de l’écosystème, Windows emploie un ensemble de valeurs spéciales dite GUID (Globally Unique Identifier), lesquelles servent à la reconnaissance d’informations qui appellent à une identification sans ambiguïté, y compris documents, comptes d’utilisateurs et de groupes, comptes d’ordinateur, partitions disque, schémas d’alimentation, etc.

Concrètement, chaque GUID se présente sous la forme d’une séquence de 128 bits (16 octets), décomposée en cinq groupes (un groupe de 4 octets, trois groupes de 2 octets et enfin, 6 octets pour le dernier groupe) séparés par des traits d’union. Par exemple : 69bd62dd-3284-4e0e-b4ac-64af471cbc45.

Une propriété essentielle de tout GUID est d’être en principe unique à travers le monde. En réalité, l’algorithme à partir duquel sont issues des GUID n’offre en la matière aucune garantie. Les probabilités que deux GUID identiques puissent être générés demeurent toutefois statistiquement infinitésimales. De fait, bien que la probabilité de collisions entre GUID existe (un même GUID désignant plusieurs objets différents), elle est suffisamment faible pour être négligeable/négligée.

Au-delà de leur unicité, les GUID ont aussi une finalité pratique clairement affirmée, puisqu’ils ils ne relèvent (et ne dépendent donc) pas d’une autorité centrale, pas plus qu’ils n’exigent de coordination entre les différents acteurs susceptibles d’émettre ce genre de valeurs.

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.

Services de terminal

Services de terminal fait dans la perspective Windows référence à la prise en charge de multiples sessions interactives sur une même machine. Grâce à une telle infrastructure, un utilisateur peut créer une session sur une machine distante et exécuter des applications sur le serveur. Le serveur transmet l’interface graphique au client, laquelle relaie les saisies de l’utilisateur.

La première session créée sur la station de travail locale est considérée comme étant la session console, ou session zéro, et renferme les processus qui hébergent des services. La première session de connexion correspond à la session numéro un, la seconde à la numéro deux, et ainsi de suite.

SDK et WDK

Sans doute l’avez-vous déjà entendu dire, ou lu à maintes reprises, mais un système d’exploitation n’est rien sans des logiciels capables d’exploiter au mieux ses capacités, raison pour laquelle Microsoft offre aux concepteurs de logiciels pléthore de méthodes et de moyens utiles pour créer (comprendre programmer) tout type d’application s’exécutant sur les systèmes d’exploitation Windows.

  • Software Development Kit (SDK) Contient les fichiers d’en-tête et les bibliothèques de base nécessaires en vue créer des applications Windows, orientées bureau ou mobile. Les concepteurs de logiciels peuvent de la sorte utiliser le SDK Windows pour créer des applications utilisant le modèle de programmation natif (Win32/COM) ou managé.

  • Windows Driver Kit (WDK) Réunit des outils pour créer, déployer, tester et déboguer des pilotes conformes à un modèle donné (WDF, KDMF, UMDF, et d’autres modèles hérités).

Convention d’appel

Les méthodes par lesquelles le système d’exploitation harmonise les relations entre différentes sous-routines, codifiant la manière dont elles reçoivent des paramètres et retournent un résultat, sont dites conventions d’appel. Déterminant les séquences que le compilateur génère pour les appels de fonctions, ces conventions sont susceptibles de différer sur un ou plusieurs des éléments suivants :

  • où les paramètres et valeurs de retour sont placés (dans les registres, sur la pile, ou un mélange des deux)

  • l’ordre dans lequel s’effectue le passage des paramètres

  • comment est attribuée la responsabilité du nettoyage de la pile d’appel (soit par la fonction appelante, soit par la fonction appelée)

  • quels registres peuvent être préservés et lesquels sont librement utilisables

Ci-après un tableau récapitulatif offrant une vue rapide des différentes conventions d’appel les plus communément employées.

Architecture Convention Transmission des arguments Responsabilité maintenance pile Retour

x86

cdecl

Poussés sur la pile

Fonction appelante

EAX, EDX / pile

fastcall

ECX, EDX / pile

Fonction appelée

EAX,EDX / pile

stdcall

Poussés sur la pile

Fonction appelée

EAX,EDX / pile

x86_64

fastcall

RCX, RDX, R8, R9 / pile

Fonction appelée

RAX

Pile d’appels

D’un point de vue exclusivement structurel, chaque processus sous Windows est normalement organisé comme un ensemble de fonctions discrètes, qui s’appellent les unes les autres et, par là même, composent un tout indivisible. Lorsqu’une fonction prend fin, elle redonne le contrôle à la fonction l’ayant sollicitée (appelée dans ce contexte fonction appelante). Afin de mieux comprendre comment se concrétise ce flux, considérez l’exemple, du reste tout à fait fictif, d’une application Cipher.exe, intégrant une bibliothèque de fonctions (DLL), CipherFuncs.dll. Dans cette DLL réside une fonction nommée CipherText, chargée de chiffrer le texte transmis parmi ses paramètres d’entrées. Passées un certain nombre d’étapes préparatoires, CipherText appelle l’API Windows CryptEncryptMessage, située elle dans Crypt32.dll. Une fois que ladite API a accompli la tâche lui ayant été confiée, l’exécution revient au point où CipherText avait passé la main à CryptEncryptMessage, juste après l’appel.

La construction logicielle par laquelle le système enregistre les sollicitations auxquelles se livrent les diverses sous-parties d’un programme est dite pile d’appel (call stack). Lorsqu’une fonction est sur le point d’en appeler une autre (exigeant de ce fait un déroutement du flux d’exécution), elle place l’adresse mémoire de l’instruction suivante à exécuter au retour de la sous-fonction (autrement dit son adresse de retour) au sommet de la pile. Lorsque cette sous-fonction appelle encore une autre fonction, elle ajoute sa propre adresse de retour à la pile. Au retour d’une fonction, le système récupère l’adresse qui se trouve en haut de la pile et commence à exécuter le code à partir de ce point.

Une large majorité des utilitaires offrant la possibilité de visualiser la pile d’appel d’un programme adoptent la même convention, correspondant au schéma module!function+offset, où module est le nom du fichier exécutable hébergeant la fonction et offset le nombre d’octets (en hexadécimal) après le début de la fonction. Dans l’éventualité où le nom de la fontion n’est pas disponible, l’adresse est alors présentée sous la forme module+offset.

Au delà de fournir de précieux renseignements sur le comportement global d’un logiciel, la pile d’appels permet de retracer la séquence d’événements qui ont conduits à une situation donnée, et peut de la sorte s’avérer particulièrement utile pour mettre en lumière les causes d’un problème.

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 8. 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.

Interface principale de DebugView

image::debugview.png[effe, 400, scaledwidth="60%"]()

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.

Options de filtrage

Une autre méthodologie d’accès à l’information offerte par DebugView consiste à utiliser ses capacités en matière de filtre, lesquelles donnent à l’utilisateur les moyens de se repérer parmi une collection de données en choisissant un ou plusieurs critères.

Naviguez dans le menu Edit jusque l’élément Filter/Highlight, ou passez par le bouton appropriée de la barre d’outils, ou encore activez le raccourci clavier Ctrl+L, pour afficher la boite de dialogue consacrée aux règles de filtre et de mises en évidence.

Les règles de filtre permettent de vous concentrer sur un sous-ensemble de données spécifique en fonction de certains critères. A cela correspond dans DebugView les contrôles d’édition Include et Exclude, servant à spécifier les termes sur la base desquels afficher, ou au contraire ne pas montrer, les enregistrements remplissant les conditions spécifiées. Si plusieurs termes méritent une attention particulière, vous pouvez faire la liste de ces derniers en les séparant par un point-virgule. N’utilisez de caractères d’espacement que si vous souhaitez les voir faire partie du filtre. Notez que le caractère étoile est interprété comme représentant n’importe quelle suite, ou absence, de caractère, et que les règles de filtre sont insensibles à la casse. Les règles par défaut, puisqu’elles n’en exclue aucun, assurent à tout flux de données une visibilité au sein de l’application.

Remarquez que les filtres s’appliquent seulement aux données nouvelles (c’est à dire, les enregistrements effectuées après qu’un filtre ai été mis en place) et aux commentaires, ajoutées à l’aide de la fonction Append Comment. Les nouveaux enregistrements qui correspondent aux règles en vigueur sont affichés; ceux qui n’y correspondent pas sont supprimées et ne peuvent pas être affichés a posteriori, par exemple via un changement des règles. En outre, la modification des règles de filtre n’a pas d’incidence sur les informations déjà affichés par DebugView.

Les règles de mises en évidence, plutôt que de jouer comme les filtres sur la visibilité de l’information, mettent en place un protocole qui, avec la technique de présentation associé, marque l’importance d’une ou plusieurs données. Comme pour le filtrage, la mise en valeur suppose la spécification de critères. Les enregistrements qui correspondent aux conditions sont mis en surbrillance , contrairement aux enregistrements qui ne les remplissent pas, bien que ceux-ci restent visibles.

DebugView conserve les options de filtre et de tri appliquées au moment de la sortie de programme. La prochaine fois que vous démarrez DebugView, une boite de dialogue apparait comme première fenêtre ouverte à l’écran, vous demandant quoi faire de ces réglages. Vous pouvez choisir soit de les modifier, soit d’utiliser ceux en vigueur, ici en cliquant sur le bouton OK. Utilisez sur le bouton Load pour charger une configuration précédemment enregistrée, ou sur le bouton Reset pour enlever le filtre. Pour contourner cette boite de dialogue, ajoutez le commutateur /f à la ligne de commande.

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

L’utilitaire intégré tasklist affiche une liste des processus en cours d’exécution sur une machine locale ou distante. 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.

WinDbg

Directives de WinDbg

En plus des commandes d’extension, qui se rapportent à l’application en cours d’examen, WinDbg admet un certain nombre de directives, exerçant quant à elles leur influence sur la session de débogage dans son ensemble. La liste qui suit passe en revue une partie des directives disponibles. (Notez que toutes sont préfixées par un point, tandis que les commandes d’extension le sont par un point d’exclamation.)

  • La commande .load charge une DLL d’extension du débogueur.

  • La commande .unload décharge une DLL d’extension du débogueur.

  • La commande .reload force l’actualisation des symboles déjà rencontrés lors de la session.

  • La commande .logopen ouvre un fichier journal et enregistre dans ce dernier toutes les activités ayant lieu par la suite.

  • La commande .logclose ferme le fichier journal.

  • La commande .kill met fin à la session de débogage actuelle.

  • La commande .chain répertorie les extensions de débogueur en cours de disponibilité.

    0:000> .chain
    Extension DLL search Path:
        ...
    Extension DLL chain:
        DbgEngCoreDMExt: image 10.0.25921.1001, API 0.0.0, 
            [path: C:\Program Files\WindowsApps\Microsoft.WinDbg_1.2308.2002.0_x64__8wekyb3d8bbwe\amd64\winext\DbgEngCoreDMExt.dll]
        dbghelp: image 10.0.25921.1001, API 10.0.6, 
            [path: C:\Program Files\WindowsApps\Microsoft.WinDbg_1.2308.2002.0_x64__8wekyb3d8bbwe\amd64\dbghelp.dll]
        exts: image 10.0.25921.1001, API 1.0.0, 
            [path: C:\Program Files\WindowsApps\Microsoft.WinDbg_1.2308.2002.0_x64__8wekyb3d8bbwe\amd64\WINXP\exts.dll]
        uext: image 10.0.25921.1001, API 1.0.0, 
            [path: C:\Program Files\WindowsApps\Microsoft.WinDbg_1.2308.2002.0_x64__8wekyb3d8bbwe\amd64\winext\uext.dll]
        ntsdexts: image 10.0.25921.1001, API 1.0.0, 
            [path: C:\Program Files\WindowsApps\Microsoft.WinDbg_1.2308.2002.0_x64__8wekyb3d8bbwe\amd64\WINXP\ntsdexts.dll]
  • La commande .formats affiche une valeur donnée dans plusieurs formats numériques différents, tels que hexadécimal, décimal, octal, binaire, et même temporel.

    0:007> .formats 0xc0ffee
    Evaluate expression:
      Hex:     00000000`00c0ffee
      Decimal: 12648430
      Decimal (unsigned) : 12648430
      Octal:   0000000000000060177756
      Binary:  00000000 00000000 00000000 00000000 00000000 11000000 11111111 11101110
      Chars:   ........
      Time:    Wed May 27 05:27:10 1970
      Float:   low 1.77242e-038 high 0
      Double:  6.24915e-317
Débogage noyau local

Au-delà des fonctionnalités attendues de ce genre de logiciel, WinDbg offre la possibilité d’ausculter l’état du système sur le même ordinateur que celui où le débogueur est exécuté. On parle en la circonstance de débogage noyau local.

Pour initier le débogage noyau local, assurez-vous d’abord que système soit en mesure de satisfaire une telle opération - à l’aide, par exemple, du commutateur debug dans bcdedit. Démarrez WinDbg (des privilèges d’administration sont requis), ouvrez le menu Fichier, choisissez Attach to Kernel, cliquez sur l’onglet Local puis sur OK. Vous devriez à ce moment voir quelque chose ressemblant à ce qui suit.

Microsoft (R) Windows Debugger Version 10.0.25921.1001 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.

Connected to Windows 10 22000 x64 target at (Mon Feb 26 11:34:44.777 2024 (UTC - 8:00)), ptr64 TRUE

************* Path validation summary **************
Response                         Time (ms)     Location
Deferred                                       srv*
Symbol search path is: srv*
Executable search path is: 
Windows 10 Kernel Version 22000 MP (2 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Edition build lab: 22000.1.amd64fre.co_release.210604-1628
Kernel base = 0xfffff800`54400000 PsLoadedModuleList = 0xfffff800`55029710
Debug session time: Mon Feb 26 11:34:45.495 2024 (UTC - 8:00)
System Uptime: 6 days 0:52:11.354    

Compte tenu des circonstances, certaines commandes du débogueur noyau ne fonctionnent pas en mode local, par exemple la définition de points d’arrêt (ce qui de toute manière n’aurait pas grand sens vu le contexte), la visualisation des registres processeur, ou encore la création de fichier de vidange sur incident. Un autre inconvénient à considérer en la matière se rapporte aux perpétuelles évolutions que traverse le système en cours d’examen (les registres, par exemple, changent constamment), ce qui en pratique est susceptible quelquefois de complexifier (voire totalement entraver) la procédure.

Commandes de manipulation des threads
  • La commande ~ sans paramètres affiche la liste des threads. L’identifiant du thread, son état, et l’adresse du bloc d’environnement (TEB) qui s’y rapporte font partie des informations proposées.

    0:000> ~
    .  0  Id: 5b6c.5a58 Suspend: 1 Teb: 0000004d`7be4b000 Unfrozen
       1  Id: 5b6c.15f0 Suspend: 1 Teb: 0000004d`7be4d000 Unfrozen
       2  Id: 5b6c.1258 Suspend: 1 Teb: 0000004d`7be4f000 Unfrozen
       3  Id: 5b6c.55a4 Suspend: 1 Teb: 0000004d`7be51000 Unfrozen
  • La commande ~n affiche les informations concernant le thread spécifié, n étant dans ce contexte le numéro du thread. La priorité du thread, sa classe de priorité, ainsi que l’adresse de la fonction qu’il exécute, sont présentées.

    0:000> ~0
    .  0  Id: 5b6c.5a58 Suspend: 1 Teb: 0000004d`7be4b000 Unfrozen
          Start: notepad!wWinMainCRTStartup (00007ff6`1a5419a0)
          Priority: 0  Priority class: 32  Affinity: 3f
  • La commande ~ns modifie le contexte actuel pour le remplacer par celui du thread spécifié. L’invite de WinDbg est mise à jour de sorte à refléter la prise en compte de l’opération.

    0:000> ~2s
    ntdll!NtWaitForWorkViaWorkerFactory+0x14:
    00007ffd`cee32fc4 c3              ret
    0:002>
Commandes de registres

La commande r sans paramètres affiche les registres du thread en cours d’examen chargés de stocker des valeurs entières.

0:000> r
rax=0000000000000000 rbx=00007ffe27baa860 rcx=00007ffe27b0f814
rdx=0000000000000000 rsi=000000068798b000 rdi=00007ffe27ba6c08
rip=00007ffe27b4b784 rsp=000000068779f0c0 rbp=0000000000000000
 r8=000000068779f0b8  r9=0000000000000000 r10=0000000000000000
r11=0000000000000246 r12=0000000000000040 r13=0000000000000001
r14=0000014c038b0000 r15=0000000000000000
iopl=0         nv up ei pl zr na po nc
cs=0033  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000246 
Commandes d’affichage de la mémoire
  • La commande dw (display word) affiche les données par groupes de 2 octets.

    0:000> dw 0x7ffe0000
    00000000`7ffe0000  0000 0000 0000 0fa0 e574 722c 075e 0000
    00000000`7ffe0010  075e 0000 6b24 d72e 7400 01da 7400 01da
    00000000`7ffe0020  a000 8711 0021 0000 0021 0000 8664 8664
    00000000`7ffe0030  0043 003a 005c 0057 0049 004e 0044 004f
    00000000`7ffe0040  0057 0053 0000 0000 0000 0000 0000 0000
    00000000`7ffe0050  0000 0000 0000 0000 0000 0000 0000 0000
    00000000`7ffe0060  0000 0000 0000 0000 0000 0000 0000 0000
    00000000`7ffe0070  0000 0000 0000 0000 0000 0000 0000 0000
  • La commande dd (display double-word) affiche les données par groupes de 4 octets.

    0:000> dd 0x7ffe0000
    00000000`7ffe0000  00000000 0fa00000 a486b84b 0000075f
    00000000`7ffe0010  0000075f 0988f4af 01da7402 01da7402
    00000000`7ffe0020  8711a000 00000021 00000021 86648664
    00000000`7ffe0030  003a0043 0057005c 004e0049 004f0044
    00000000`7ffe0040  00530057 00000000 00000000 00000000
    00000000`7ffe0050  00000000 00000000 00000000 00000000
    00000000`7ffe0060  00000000 00000000 00000000 00000000
    00000000`7ffe0070  00000000 00000000 00000000 00000000
  • La commande dq (display quad-word) affiche les données par groupes de 8 octets.

    0:000> dq 0x7ffe0000
    00000000`7ffe0000  0fa00000`00000000 0000075e`7e58e56c
    00000000`7ffe0010  e35a725f`0000075e 01da7400`01da7400
    00000000`7ffe0020  00000021`8711a000 86648664`00000021
    00000000`7ffe0030  0057005c`003a0043 004f0044`004e0049
    00000000`7ffe0040  00000000`00530057 00000000`00000000
    00000000`7ffe0050  00000000`00000000 00000000`00000000
    00000000`7ffe0060  00000000`00000000 00000000`00000000
    00000000`7ffe0070  00000000`00000000 00000000`00000000
  • La commande da affiche l’interprétation Ascii de la mémoire.

    0:000> da 0x7ff7d4cf0000
    00007ff7`d4cf0000  "MZ."
  • La commande du affiche l’interprétation Unicode de la mémoire.

    0:000> du 0x7ffe0030
    00000000`7ffe0030  "C:\WINDOWS"
Commandes de niveau image
  • La commande !dlls affiche une liste des modules chargés (essentiellement les DLL), y compris des informations telles que leur nom, adresse de départ, taille, etc.

    0:000> !dlls
    
    0x214c8112c40: C:\Windows\System32\notepad.exe
          Base   0x7ff67dfd0000  EntryPoint  0x7ff67dfd19a0  Size        0x0005a000    DdagNode     0x214c8112d80
          Flags  0x0000a2cc  TlsIndex    0x00000000  LoadCount   0xffffffff    NodeRefCount 0x00000000
                 <unknown>
                 LDRP_LOAD_NOTIFICATIONS_SENT
                 LDRP_IMAGE_DLL
    
    0x214c8112aa0: C:\WINDOWS\SYSTEM32\ntdll.dll
          Base   0x7ffe27a70000  EntryPoint  0x00000000  Size        0x00216000    DdagNode     0x214c8112be0
          Flags  0x0000a2c4  TlsIndex    0x00000000  LoadCount   0xffffffff    NodeRefCount 0x00000000
                 <unknown>
                 LDRP_IMAGE_DLL
    
    0x214c8117940: C:\WINDOWS\System32\KERNEL32.DLL
          Base   0x7ffe25f70000  EntryPoint  0x7ffe25f825e0  Size        0x000c4000    DdagNode     0x214c8117a80
          Flags  0x000ca2cc  TlsIndex    0x00000000  LoadCount   0xffffffff    NodeRefCount 0x00000000
                 <unknown>
                 LDRP_LOAD_NOTIFICATIONS_SENT
                 LDRP_IMAGE_DLL
                 LDRP_DONT_CALL_FOR_THREADS
                 LDRP_PROCESS_ATTACH_CALLED
    
    0x214c8117f30: C:\WINDOWS\System32\KERNELBASE.dll
          Base   0x7ffe252f0000  EntryPoint  0x7ffe2532cb10  Size        0x003a6000    DdagNode     0x214c8118070
          Flags  0x0008a2cc  TlsIndex    0x00000000  LoadCount   0xffffffff    NodeRefCount 0x00000000
                 <unknown>
                 LDRP_LOAD_NOTIFICATIONS_SENT
                 LDRP_IMAGE_DLL
                 LDRP_PROCESS_ATTACH_CALLED
    
    ...

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.

Généralités concernant les 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
Chargement différé des symboles

Les débogueurs Windows standards s’appuient à des fins d’optimisation sur un traitement différé des symboles, ne les chargeant en l’occurence qu’en cas de stricte nécessité, chaque fois qu’il se présente un symbole non reconnu. Certains symboles peuvent en conséquence n’être pas synchronisés avec la session en cours. La commande de base via laquelle tenir compte de cette situation est la commande .reload, qui contrairement à ce que son nom le laisse penser, ne recharge pas les informations de symboles, mais force en réalité le débogueur à supprimer tout ou partie de celles qu’il connait. La commande fait en fait savoir au débogueur que les fichiers de symboles concernés pourraient avoir changé, ou encore qu’un nouveau module doit être ajouté à la liste des modules. Les formes les plus usuelles de la commande .reload sont les suivantes :

  • .reload Supprime les informations de symbole concernant l’ensemble des modules chargés. Toute tentative de résoudre un symbole entraine le rechargement du fichier de symboles à partir du disque.

  • .reload <module> Supprime les informations de symbole du module spécifié. Toute tentative de résoudre un symbole recharge le fichier de symboles à partir du disque.

  • .reload /f <module> Force le débogueur à charger le fichier de symboles associé à un module.

  • .reload nt Recharge le fichier de symboles correspondant à la version du noyau exécuté par le système cible. Cette option ne concerne que le débogage en mode noyau.

  • .reload /user Recharge les fichiers de symboles en mode utilisateur pour le processus actif. Cette option ne concerne que le débogage en mode noyau.

  • .reload <module>=address,size Les commandes passées en revue jusqu’ici sur des informations stockées à la fois dans l’image du module concernée par la session de débogage et dans le bloc de contrôle du processeur. Si pour une raison quelconque, ces données viendraient à être manquantes ou incorrectes, il est possible de forcer le chargement des symboles en spécifiant l’adresse et l’occupation mémoire du module.

Le chargement différé des symboles (actif par défaut) peut être activé ou désactivé à l’aide de la commande de la commande .symopt, accompagnée dans ce contexte de l’option SYMOPT_DEFERRED_LOADS (0x4).

Commande symopt

Un certain nombre d’options, modifiables à l’aide de la commande symopt, sont disponibles pour contrôler la façon dont les symboles sont chargés et utilisés.

Flag Option Actif par défaut

0x1

SYMOPT_CASE_INSENSITIVE

Oui

0x2

SYMOPT_UNDNAME

Oui

0x4

SYMOPT_DEFERRED_LOADS

Oui

0x8

SYMOPT_NO_CPP

Non

0x10

SYMOPT_LOAD_LINES

Non (KD/CDB), Oui (WinDbg)

0x20

SYMOPT_OMAP_FIND_NEAREST

Oui

0x40

SYMOPT_LOAD_ANYTHING

Non

0x80

SYMOPT_IGNORE_CVREC

Non

0x100

SYMOPT_NO_UNQUALIFIED_LOADS

Non

0x200

SYMOPT_FAIL_CRITICAL_ERRORS

Oui

0x400

SYMOPT_EXACT_SYMBOLS

Non

0x800

SYMOPT_ALLOW_ABSOLUTE_SYMBOLS

Non

0x1000

SYMOPT_IGNORE_NT_SYMPATH

Non

0x2000

SYMOPT_INCLUDE_32BIT_MODULES

Non

0x4000

SYMOPT_PUBLICS_ONLY

Non

0x8000

SYMOPT_NO_PUBLICS

Non

0x10000

SYMOPT_AUTO_PUBLICS

Oui

0x20000

SYMOPT_NO_IMAGE_SEARCH

Oui

0x40000

SYMOPT_SECURE

Non

0x80000

SYMOPT_NO_PROMPTS

Oui (KD/CDB), Non (WinDbg)

0x80000000

SYMOPT_DEBUG

Non

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.

Opérations sur un magasin :

  • /createstore Crée un magasin des données de configuration de démarrage vide. Le magasin créé n’est pas un magasin système. Pour plus d’informations, consultez le volet \<\<_agir_sur_le_magasin\>\>.

  • /export Exporte le contenu du magasin système dans un fichier. Ce fichier peut être utilisé ultérieurement pour restaurer l’état du magasin système.

  • /import Restaure l’état du magasin système à l’aide d’un fichier de données de sauvegarde généré précédemment en utilisant l’option /export.

  • /store Spécifie un magasin autre que le magasin système actuel par défaut.

  • /sysstore Définit le dispositif de stockage du système.

Opérations sur les entrées d’un magasin :

  • /copy Crée des copies d’entrées du magasin.

  • /create Crée des entrées dans le magasin.

  • /delete Supprime des entrées du magasin.

  • /mirror Crée un miroir des entrées du magasin.

Contrôle de la sortie :

  • /enum Répertorie les entrées d’un magasin.

  • /v Mode détaillé.

Identificateurs bien connus

Pour faciliter la navigation parmi les entrées d’un magasin, l’éditeur BCD reconnait pour quelques-uns un nom convivial, plus simple à manipuler qu’un GUID. Les identificateurs bien connus suivants sont établis.

  • {badmemory} Contient la liste globale de RAM défectueuse qui peut être héritée par toute entrée d’application de démarrage.

  • {bootloadersettings} Contient la collection des paramètres globaux dont doivent hériter toutes les entrées d’application chargeur de démarrage Windows.

  • {bootmgr} Indique l’entrée du Gestionnaire de démarrage Windows.

  • {current} Représente un identifiant virtuel qui correspond à l’entrée de démarrage du système d’exploitation pour système d’exploitation en cours d’exécution.

  • {dbgsettings} Contient les paramètres de débogage global pouvant être hérités par toute entrée d’application de démarrage.

  • {default} Représente un identifiant virtuel qui correspond à l’entrée d’application du gestionnaire de démarrage par défaut.

  • {emssettings} Contient les paramètres globaux EMS qui peuvent être hérités par toute entrée d’application de démarrage.

  • {fwbootmgr} Sur les systèmes EFI, indique l’entrée de gestionnaire de démarrage micrologiciel,

  • {globalsettings} Contient la collection des paramètres globaux dont doit hériter toute entrée d’application de démarrage.

  • {hypervisorsettings} Contient les paramètres hyperviseur dont peuvent hériter toute entrée d’application de démarrage.

  • {legacy} Indique le chargeur d’OS hérité Windows (Ntldr), utilisable pour démarrer un système d’exploitation Windows antérieur à Windows Vista.

  • {memdiag} Indique l’entrée de l’application de diagnostic de la mémoire.

  • {ntldr} Indique le chargeur d’OS hérité Windows (Ntldr), utilisable pour démarrer un système d’exploitation Windows antérieur à Windows Vista.

  • {ramdiskoptions} Contient les options supplémentaires nécessaires au gestionnaire pour des périphériques de RAM disque.

  • {resumeloadersettings} Contient la collection des paramètres globaux dont doit hériter toute entrée d’application de sortie de veille prolongée.

Dès lors qu’une entrée possède un identificateur bien connu, l’éditeur BCD le fait apparaitre dans la sortie de commande, excepté si le mode volubile (commutateur /v) a été choisi, auquel cas les identificateurs sont montrés sous leur forme complète.

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 9. 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éés 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 10. 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.

Pour commencer à utiliser le Gestionnaire du vérificateur de pilotes, ouvrez une fenêtre d’invite de commandes ou le contrôle Exécuter, saisissez verifier.exe puis validez. Dans la boîte de dialogue nouvellement affichée, sélectionnez Créer des paramètres standard. Cliquez sur Suivant ; après quoi vous devriez être en mesure de sélectionner les pilotes à vérifier. Les options suivantes sont accessibles :

  • Sélectionner automatiquement les pilotes non signés

  • Sélectionner automatiquement les pilotes conçus pour une ancienne version de Windows

  • Sélectionner automatiquement tous les pilotes installés sur cet ordinateur

  • Choisir des noms de pilotes dans une liste

Après un clic sur le bouton Suivant, le logiciel génère une liste des pilotes qui correspondent aux conditions spécifiées. Deux cas de figure peuvent alors être considérées : (1) Consulter la liste pour découvrir quels sont les pilotes identifiées selon la méthode choisie, puis cliquer sur Annuler ; (2) Cliquer sur Terminer pour quitter l’assistant et redémarrer l’ordinateur.

Pour désactiver le Vérificateur de pilotes, et ce faisant l’enjoindre à cesser toute vérification au démarrage de l’ordinateur, exécutez-le et sélectionnez Supprimer les paramètres existants dans la boite de dialogue initiale. Vous pouvez également saisir verifier /reset depuis une invite de commandes.

Table 11. Options de vérification
Hexadécimal Option

0x00000001

Special Pool

0x00000002

Force IRQL Checking

0x00000004

Low Resources Simulation

0x00000008

Pool Tracking

0x00000010

I/O Verification

0x00000020

Deadlock Detection

0x00000040

Enhanced I/O Verification

0x00000080

DMA Verification

0x00000100

Security Checks

0x00000200

Force Pending I/O Requests

0x00000400

IRP Logging

0x00000800

Miscellaneous Checks

0x00040000

Systematic low resources simulation

0x00200000

NDIS/WIFI verification

0x00800000

Kernel synchronization delay fuzzing

Vérificateur de pilotes prend en compte de nombreuses options :

  • Détection de blocage Surveille l’utilisation de différents objets exposés en tant que primitives de synchronisation (spinlocks, mutex, etc.) en recherchant des modèles de comportement susceptibles d’indiquer un verrou mortel.

  • Contrôle DMA Contrôle l’utilisation adéquate des interfaces (tampons et registres) qui autorisent un accès direct à la mémoire (DMA, Direct Memory Access).

  • Pool spécial Force les routines d’allocation (ExAllocatePool, IoAllocateIrp, etc.) à s’alimenter auprès d’un pool spécial (par opposition aux pools de mémoire noyau ordinaires) spécifiquement conçu pour la détection des débordements de tampons et des erreurs d’accès.

  • Suivi de pool Veille à ce qu’un pilote, à l’issue de son exécution, ait restitué la mémoire allouée pour son compte.

  • Vérification d’E/S Surveille l’accomplissement interne et l’impact externe des fonctions d’E/S définies par les pilotes, visant ici à relever de leur part toute éventuelle gestion non avisée.

  • Vérification IRQL forcée Incrimine les pilotes qui accèdent à de la mémoire paginable à un IRQL trop élevé pour cette opération.

  • Simulation de ressources faibles Évalue comment se comportent les pilotes face à une saturation des ressources système - et, partant, à un manque de mémoire noyau.

  • Vérifications de sécurité Identifie les situations courantes susceptibles d’impacter négativement la sécurité du système.

  • Journalisation IRP Enregistre ce que font les pilotes des IRP qui leur sont adressés.

  • Forcer les demande d’E/S en attente Met à l’épreuve la capacité des pilotes à gérer correctement des E/S asynchrones.

  • Analyse du temps d’exécution Chronomètre l’exécution des routines d’achèvement d’E/S et d’annulation des pilotes vérifiés et signale lesquelles excèdent les temps prescrits.

  • Retards de synchronisation de noyau Propage à différents stades de l’exécution des pilotes vérifiés des délais aléatoires.

  • Vérification d’intégrité de disque Surveille les accès au média de stockage en vue de déterminer s’il enregistre les informations conformément aux attentes.

  • Vérification SCSI Supervise les interactions qui émanent de l’utilisation du bus SCSI.

  • Vérification NDIS/WIFI Détermine si un pilote NDIS ou WIFI interagit correctement avec les autres composants du système d’exploitation, dont le noyau.

  • Conformité WDF Examine la conformité des pilotes aux exigences essentielles imposées par le modèle de pilote KMDF.

S’il montre son utilité notamment dans le cadre de la conception de code mode noyau, Vérificateur de pilotes, étant donné l’étendue des fonctionnalités qu’il offre, est de surcroit un outil puissant entre les mains des administrateurs, qui l’emploiront selon le contexte pour remonter la piste d’un effondrement du système, débusquer des erreurs matérielles, etc.

La plupart des paramètres établis concernant la vérification des pilotes sont enregistrés dans le Registre sous HKLM\System\CurrentControlSet\Control\Session Manager\Memory Management. Parmi toutes les valeurs hébergées à cet emplacement, deux méritent une attention particulière : VerifyDriverLevel, qui contient un masque binaire représentant les types de vérification activés, et VerifyDrivers, qui renferme les noms des pilotes soumis à examen. Si vous avez choisi de procéder à un audit complet complet (tous les pilotes), VerifyDrivers fait alors mention d’un astérisque (caractère \*). Notez que selon les paramètres pour lesquels vous avez opté, vous serez peut-être amené à réamorcer le système.

Durant la phase d’amorçage, le gestionnaire de mémoire consulte les valeurs de registre associées à la vérification des pilotes et détermine, partant de ces informations, quels pilotes sont concernés et quelles options sont en vigueur. (Notez que, si l’ordinateur a démarré en mode sans échec, tous les paramètres de Vérificateur de pilotes sont ignorés.). Par la suite, pour peu que la configuration appelle à l’examen d’au moins un pilote, le noyau vérifie le nom de chaque pilote qu’il s’apprête à charger par rapport à la liste des pilotes devant faire l’objet d’une procédure de contrôle. Pour chaque pilote dont le nom est répertorié, le noyau initie son chargement non plus à l’aide de la routine commune en la matière (NtLoadDriver), mais par le biais de la fonction spécialisée VfLoadDriver, laquelle se charge de remplacer les références que le pilote effectue à un certain nombre de fonctions du noyau ou de l’exécutif par des références à des versions équivalentes, mais mieux adaptées à la détection de bogues, du Vérificateur de pilotes.

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ées 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 des ordinateurs

Multiprocesseurs et multicoeurs

Une large majorité des ordinateurs actuels incorpore des fonctions plus ou moins avancées de parallélisation physique. À cet égard, Windows reconnait deux types de systèmes : les machines uniprocesseur, où une seule séquence d’exécution (thread) est envisageable à un moment donné, et les machines multiprocesseurs, lesquelles rendent possible l’exécution parallèle et simultanée de plusieurs tâches. Cette seconde configuration englobe en réalité différents modèles d’architectures, à savoir :

  • Multiprocesseur La machine héberge des processeurs physiques distincts.

  • Multicoeur Plusieurs processeurs (coeurs) sont installées sur une même puce, reliées par un réseau d’interconnexion.

  • Hyperthreading Un seul processeur physique peut gérer deux threads par cycle d’horloge.

Des combinaisons de ces différents schémas sont aussi possibles. Ainsi, une machine dotée de deux processeurs physiques, chacun muni de deux coeurs et chaque coeur étant hyperthreadé, assure au système d’exploitation huit processeurs virtuels.

Simultaneous Multithreading

Un processeur conventionnel n’est réellement capable d’accomplir qu’une seule tâche à la fois, et doit donc basculer alternativement d’un thread à un autre - donnant ainsi l’illusion du multitâche. Pour éviter une perte de temps liée à l’attente de nouvelles instructions, et réduire les délais qu’engendrent les commutations de contexte, les fondeurs de processeurs se sont impliqués dans l’amélioration du parallélisme (au niveau matériel, s’entend), et ont mis en avant des des procédés d’optimisation pour que les threads puissent partager les pipelines, les caches et les registres : on parle alors d’exécution SMT (Simultaneous Multithreading).

L’objectif général de toute conception SMT est de de limiter la sous-utilisation des structures internes du processeur. Dans une telle configuration, certaines structures sont dupliquées, comme les valeurs des registres ou la table de renommage, tandis que d’autres sont partagées, comme les caches ou les unités fonctionnelles (UAL, unités d’accès mémoire, etc.).

Pipeline

L’un des mécanismes de base qui régit les processeurs modernes est le pipeline.

Dans une microarchitecture standard (comprendre dépourvue de toute forme d’optimisation) l’exécution des instructions est accomplie de manière purement séquentielle, ce qui implique qu’une nouvelle instruction ne peut être prise en compte sans attendre que l’actuelle soit terminée. Par contraste, dans un processeur doté d’un pipeline, l’exécution des instructions est décomposée en plusieurs étapes fonctionnellement indépendantes (qui concernent des circuits séparés), et plusieurs instructions peuvent se trouvent simultanément en cours d’exécution.

Au plus fort degré d’abstraction, le principe du pipeline est comparable à celui d’une ligne (ou chaîne) de montage, où chaque unité s’emploie à une tâche spécifique, et participe de la sorte à un meilleur rendement. Chacune des étapes qui s’inscrit dans un processus pipeliné est appelé étage. Le nombre d’étages d’un pipeline est appelé sa profondeur. Afin de mieux cerner concrètement le sujet, voyons un exemple des plus notoires, le pipeline RISC originel, lequel assure l’exécution principale en 5 étapes :

  • Lecture de l’instruction (IF, Instruction Fetch) Chargement du premier mot d’instruction de la mémoire principale vers le registre d’instruction.

  • Décodage (ID, Instruction Decode) décode l’instruction et adresse les registres.

  • Exécution (EX, Execute) Exécute l’instruction.

  • Mémoire (MEM, Memory)

  • Écriture du résultat (WB, Write Back) Modification de l’opérande destination pour les instructions arithmétiques ou logiques, ou pour ce qui est des instructions de contrôle, modification du registre d’instruction.

Notez que l’organisation en pipeline ne diminue en aucun cas le temps nécessaire pour achever une instruction (autrement dit, aucune n’est exécutée plus rapidement), mais augmente par contre le nombre d’instructions exécutées par cycle.

Le fonctionnement idéal d’un pipeline suppose un certain nombre de paramètres : (1) chacune des sous-opérations s’appuie sur des points différents du chemin de données ; (2) les instructions exécutées sont indépendantes les unes vis-à-vis des autres ; et (3) l’instruction devant être traitée après celle en cours est est la suivante en mémoire (ou, à tout le moins, peut être facilement déterminée). Dans les faits, il peut arriver qu’une de ces conditions, voire toutes, ne soit pas remplie, introduisant ce que l’on appelle alors un aléa. Partant des critères susmentionnés, trois sortes d’aléa se distinguent nettement :

  • Aléa structurel

  • Aléa de données

  • Aléa de contrôle

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 actuel, 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>\>.

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 12. 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 Accélère le démarrage du système et l’accès aux programmes les plus utilisés.

  • Système LPC Assure la communication entre processus serveur et processus client sur une même machine.

  • Gestionnaire d’errata Fournit des solutions de contournement pour les périphériques matériels présentant une configuration non standard ou non conforme à leur bon fonctionnement.

  • Windows Hypervisor Interface Library (WinHv) Établit un pont entre les pilotes d’un système d’exploitation virtualisé et l’hyperviseur lui-même, ce qui permet aux pilotes de solliciter l’hyperviseur à l’aide des conventions d’appel standard de Windows.

  • Gestionnaire de transaction noyau Prend en charge les aspects transactionnels de NTFS et du registre.

  • Event Tracing for Windows Fournit des routines d’assistance pour le suivi des événements.

  • Windows Diagnostic Infrastructure (WDI) Intègre des scénarios de diagnostic destinées à résoudre les problèmes externes qui affectent le comportement de Windows.

  • Event Tracing for Windows Fournit des routines d’assistance pour le suivi des événements.

  • Windows Diagnostic Infrastructure (WDI) Intègre des scénarios de diagnostic destinées à résoudre les problèmes externes qui affectent le comportement de Windows.

  • Driver Verifier Soumet les pilotes à un ensemble de contraintes et de tests, en vue notamment de valider leur qualité.

  • Windows Hardware Error Architecture Définit un cadre commun de gestion des erreurs matérielles.

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.

Couche d’abstraction matérielle (HAL)

Comme mentionné en début de chapitre (section Objectifs de conception), Windows a dès le départ été conçu pour fonctionner sur différents types de machines. En creux de cette capacité d’adaptation, HAL (Hardware Abstraction Layer), qui agit tel un intermédiaire entre le système d’exploitation et les équipements de l’ordinateur.

Sur le papier un ensemble de prescriptions d’ordre structurel et technique, HAL se présente concrètement sous la forme d’un module noyau chargeable (Hal.dll) qui fournit l’interface bas niveau vers la plateforme matérielles, masquant ainsi les détails d’implémentation dépendants du matériel tels que les interfaces d’E/S, les contrôleurs d’interruption et les mécanismes de communication multi processeur.

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.

Pour voir quel HAL est en cours d’exécution sur la station de travail, démarrez une session de débogage puis entrez la commande lm vm hal.

lkd> lm vm hal
Browse full module list
start             end                 module name
fffff801`b7b54000 fffff801`b7be0000   hal        (deferred)             
    Image path: hal.dll
    Image name: hal.dll
    Browse all global symbols  functions  data
    Image was built with /Brepro flag.
    Timestamp:        4252FF42 (This is a reproducible build file hash, not a timestamp)
    CheckSum:         000892FF
    ImageSize:        0008C000
    Translations:     0000.04b0 0000.04e4 0409.04b0 0409.04e4
    Information from resource tables:

Au lieu d’accéder directement au matériel, les composants internes de Windows assurent la portabilité en sollicitant les routines HAL dès lors qu’ils manipulent des informations liées à la plateforme. De ce fait, un pilote qui utilise correctement HAL pour accéder aux périphériques ne nécessite aucune modifiction (autre que la recompilation) pour lui permettre de s’exécuter sur les les différentes plateformes matérielles reconnues par Windows.

Les ressources pour lesquelles HAL fournit une abstraction sont les suivantes :

  • Adressage des périphériques

  • Architecture d’E / S

  • Gestion des interruptions

  • Opérations DMA

  • Horloges et minuteries système

  • Gestion de la configuration

Noyau

Au plus large degré d’abstraction, le noyau Windows consiste en un base de primitives grâce auxquelles d’autres composants du système (services de l’exécutif, sous-systèmes d’environnement, etc.) assurent leur fonction. Ses rôles centraux incluent la gestion du matériel, l’ordonnancement et la synchronisation de threads, la prise en charge des interceptions (interruptions et exceptions), et la synchronisation multi processeur.

L’une des responsabilités les plus importantes du noyau est d’offrir l’interface de haut niveau vers la plateforme matérielle. Il rend à cet égard visible un vaste ensemble de données et d’interfaces sémantiquement identiques sur toutes les architectures. Comme c’est le cas des diverses fonctions de support de l’exécutif mentionnées dans la section qui précède, un certain nombre de fonctions du noyau sont documentés.

Autre rôle crucial attribué au noyau : offrir des accès mutuellement exclusifs sur l’ensemble des processeurs. Il emploie pour ce faire diverses méthodes, notamment spin locks et opérations inter verrouillées.

Un aspect intéressant à relever en ce qui concerne le noyau Windows est qu’il évite au plus possible les décisions stratégiques, les conférant en réalité à l’exécutif.

Le noyau est écrit essentiellement en C, l’assembleur étant dans ce contexte cantonné aux tâches qui exigent l’accès à des registres et instructions spécialisés du processeur.

Pour obtenir des informations concrètes en ce qui concerne le noyau, saisissez dans une fenêtre de débogueur noyau la commande lm vm nt.

lkd> lm vm nt
Browse full module list
start             end                 module name
fffff801`b7201000 fffff801`b7b54000   nt         (pdb symbols)          c:\symbols\ntkrnlmp.pdb\DD0D1D2022E0401BB9551D9DD9ECDF581\ntkrnlmp.pdb
    Loaded symbol image file: ntkrnlmp.exe
    Image path: ntkrnlmp.exe
    Image name: ntkrnlmp.exe
    Browse all global symbols  functions  data
    Timestamp:        Thu Sep 20 05:40:30 2018 (5BA316AE)
    CheckSum:         008B3C39
    ImageSize:        00953000
    Translations:     0000.04b0 0000.04e4 0409.04b0 0409.04e4
    Information from resource tables:

Sur le plan des dépendances externes, Ntoskrnl est en premier lieu lié à Hal.dll, correspondant à la couche d’abstraction matérielle. Il l’est également à Bootvid.dll, pilote vidéo d’amorçage servant à afficher l’écran de démarrage, à Ci.dll, module d’intégrité du code, à Clfs.sys, pilote de système de fichier journal commun (CLFS, Common Log File System), à Kdcom.dll, qui contient du code d’infrastructure de débogueur noyau, et enfin à Pshed.dll, pilote d’erreurs matérielles spécifiques à une plateforme.

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 toutes 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 13. 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

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

SYSTEM_MEMORY_INFORMATION

0x001A

SystemLoadGdiDriverInformation

SYSTEM_GDI_DRIVER_INFORMATION

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

SYSTEM_VERIFIER_INFORMATION

0x0034

SystemVerifierThunkExtend

0x0035

SystemSessionProcessInformation

0x0036

SystemLoadGdiDriverInSystemSpace

0x0037

SystemNumaProcessorMap

SYSTEM_NUMA_INFORMATION

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

SYSTEM_PROCESS_ID_INFORMATION

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 14. 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 15. 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;
  • Architecture du processeur (ProcessorArchitecture) Voir fonction GetSystemInfo ; attribut wProcessorArchitecture de structure SYSTEM_INFO ; variable noyau KeProcessorArchitecture.

  • ProcessorLevel Voir fonction GetSystemInfo ; attribut CpuType de structure KPRCB, attribut wProcessorLevel de structure SYSTEM_INFO ; variable noyau KeProcessorLevel.

  • ProcessorRevision Voir fonction GetSystemInfo ; attribut wProcessorRevision de structure SYSTEM_INFO ; variable noyau KeProcessorRevision.

  • Fonctionnalités (ProcessorFeatureBits) Voir attribut FeatureBits de structure KPRCB, variable noyau 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 16. 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

KPRCB MmTransitionCount

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 17. Valeurs initiales des champs de la structure SYSTEM_TIMEOFDAY_INFORMATION
Champ Valeur initiale

CurrentTime

KeQuerySystemTime

BootTime

KeBootTime

TimeZoneBias

ExpTimeZoneBias

TimeZoneId

ExpCurrentTimeZoneId

BootTimeBias

KeBootTimeBias

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 18. 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 19. 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;
typedef struct _SYSTEM_NUMA_INFORMATION
{
    ULONG HighestNodeNumber;
    ULONG Reserved;
    union
    {
        ULONGLONG ActiveProcessorsAffinityMask[MAXIMUM_NUMA_NODES];
        ULONGLONG AvailableMemory[MAXIMUM_NUMA_NODES];
    };
} SYSTEM_NUMA_INFORMATION, *PSYSTEM_NUMA_INFORMATION;
typedef struct _SYSTEM_OBJECTTYPE_INFORMATION
{
  ULONG NextEntryOffset;
  ULONG NumberOfObjects;
  ULONG NumberOfHandles;
  ULONG TypeIndex;
  ULONG InvalidAttributes;
  GENERIC_MAPPING GenericMapping;
  ULONG ValidAccessMask;
  ULONG PoolType;
  BOOLEAN SecurityRequired;
  BOOLEAN WaitableObject;
  UNICODE_STRING TypeName;
} SYSTEM_OBJECTTYPE_INFORMATION, *PSYSTEM_OBJECTTYPE_INFORMATION;

typedef struct _SYSTEM_OBJECT_INFORMATION
{
  ULONG NextEntryOffset;
  PVOID Object;
  HANDLE CreatorUniqueProcess;
  USHORT CreatorBackTraceIndex;
  USHORT Flags;
  LONG PointerCount;
  LONG HandleCount;
  ULONG PagedPoolCharge;
  ULONG NonPagedPoolCharge;
  HANDLE ExclusiveProcessId;
  PVOID SecurityDescriptor;
  OBJECT_NAME_INFORMATION NameInfo;
} SYSTEM_OBJECT_INFORMATION, *PSYSTEM_OBJECT_INFORMATION;
typedef struct _SYSTEM_MEMORY_INFO
{
  PUCHAR StringOffset;
  USHORT ValidCount;
  USHORT TransitionCount;
  USHORT ModifiedCount;
  USHORT PageTableCount;
} SYSTEM_MEMORY_INFO, *PSYSTEM_MEMORY_INFO;

typedef struct _SYSTEM_MEMORY_INFORMATION
{
  ULONG InfoSize;
  ULONG StringStart;
  SYSTEM_MEMORY_INFO Memory[1];
} SYSTEM_MEMORY_INFORMATION, *PSYSTEM_MEMORY_INFORMATION;
typedef struct _SYSTEM_GDI_DRIVER_INFORMATION
{
  UNICODE_STRING DriverName;
  PVOID ImageAddress;
  PVOID SectionPointer;
  PVOID EntryPoint;
  PIMAGE_EXPORT_DIRECTORY ExportSectionPointer;
  ULONG ImageLength;
} SYSTEM_GDI_DRIVER_INFORMATION, *PSYSTEM_GDI_DRIVER_INFORMATION;
typedef struct _SYSTEM_VERIFIER_INFORMATION
{
  ULONG NextEntryOffset;
  ULONG Level;
  UNICODE_STRING DriverName;
  ULONG RaiseIrqls;
  ULONG AcquireSpinLocks;
  ULONG SynchronizeExecutions;
  ULONG AllocationsAttempted;
  ULONG AllocationsSucceeded;
  ULONG AllocationsSucceededSpecialPool;
  ULONG AllocationsWithNoTag;
  ULONG TrimRequests;
  ULONG Trims;
  ULONG AllocationsFailed;
  ULONG AllocationsFailedDeliberately;
  ULONG Loads;
  ULONG Unloads;
  ULONG UnTrackedPool;
  ULONG CurrentPagedPoolAllocations;
  ULONG CurrentNonPagedPoolAllocations;
  ULONG PeakPagedPoolAllocations;
  ULONG PeakNonPagedPoolAllocations;
  SIZE_T PagedPoolUsageInBytes;
  SIZE_T NonPagedPoolUsageInBytes;
  SIZE_T PeakPagedPoolUsageInBytes;
  SIZE_T PeakNonPagedPoolUsageInBytes;
} SYSTEM_VERIFIER_INFORMATION, *PSYSTEM_VERIFIER_INFORMATION;
typedef struct _RTL_TIME_ZONE_INFORMATION
{
  LONG Bias;
  WCHAR StandardName[32];
  TIME_FIELDS StandardDate;
  LONG StandardBias;
  WCHAR DaylightName[32];
  TIME_FIELDS DaylightDate;
  LONG DaylightBias;
} RTL_TIME_ZONE_INFORMATION, *PRTL_TIME_ZONE_INFORMATION;
typedef struct _RTL_PROCESS_LOCK_INFORMATION
{
  PVOID Address;
  USHORT Type;
  USHORT CreatorBackTraceIndex;
  ULONG OwnerThreadId;
  ULONG ActiveCount;
  ULONG ContentionCount;
  ULONG EntryCount;
  ULONG RecursionCount;
  ULONG NumberOfSharedWaiters;
  ULONG NumberOfExclusiveWaiters;
} RTL_PROCESS_LOCK_INFORMATION, *PRTL_PROCESS_LOCK_INFORMATION;

typedef struct _RTL_PROCESS_LOCKS
{
  ULONG NumberOfLocks;
  RTL_PROCESS_LOCK_INFORMATION Locks[1];
} RTL_PROCESS_LOCKS, *PRTL_PROCESS_LOCKS;
typedef struct _SYSTEM_PROCESS_ID_INFORMATION {
    HANDLE ProcessId;
    UNICODE_STRING ImageName;
} SYSTEM_PROCESS_ID_INFORMATION, *PSYSTEM_PROCESS_ID_INFORMATION;

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 20. 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 21. 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ée 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\catroot

  • %windir%\system32\catroot2

  • %windir%\system32\driverstore

  • %windir%\system32\drivers\etc

  • %windir%\system32\logfiles

  • %windir%\system32\spool

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. Neutraliser la redirection du système de fichiers affecte l’ensemble des E/S de niveau fichier qui émanent du thread appelant. Une telle solution ne devrait par conséquent être envisagée que dans le cadre le cadre d’occasions spécifiques, et dont il résulte des temps d’exécution réduits. Bloquer les E/S orientées fichier pendant des périodes plus longues peut empêcher les application 32 bits de charger des DLL système, entraînant de ce fait leur échec.

Les applications 32 bits souhaitant accéder au répertoire système natif ont la possibilité de le faire à l’aide du chemin d’accès %windir%\Sysnative, que Wow64 reconnaît comme un alias spécial utilisé pour indiquer que le système de fichiers ne doit pas rediriger l’accès. Notez que les applications 64 bits ne peuvent pas utiliser l’alias Sysnative, dans la mesure où il s’agit d’un répertoire virtuel, qui n’existe donc pas physiquement en tant que tel sur le système. Notez que si vous naviguez avec l’explorateur de fichiers à l’emplacement susmentionné, vous ne trouverez nulle part mention d’un répertoire Sysnative, y compris si l’option Afficher les dossiers cachés et système est exercée. Cela est simplement dû au fait que le dossier Sysnative est visible et accessible uniquement à partir de programmes 32 bits.

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 22. 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