Vous êtes sur la page 1sur 538

Dans les coulisses de Microsoft Windows

Arnaud Maillard
Dans les coulisses de Microsoft Windows
Arnaud Maillard
La dernière date à laquelle ce document a été approuvé est octobre 1, 2018. Il a à cette occasion été distribué sous le numéro de
version 0.2.1.0. Les lecteurs sont invités à vérifier qu'ils sont en possession de la dernière évolution via le site web ntoskrnl.org.

Cet ouvrage est publié sous licence Creative Commons (CC BY-NC-ND 4.0). Vous êtes autorisé à copier, distribuer et communiquer
cette œuvre par tous moyens et sous tous formats, mais sans la modifier. Vous n’êtes pas autorisé à faire un usage commercial de cette
œuvre, ni de tout ou partie du matériel la composant. Vous n’êtes pas autorisé à appliquer des conditions légales ou des mesures
techniques qui restreindraient légalement autrui à utiliser l’œuvre dans les condi-tions décrites par la licence
Introduction ..................................................................................................................................... xvi
À qui s’adresse ce livre ? .......................................................................................................... xvi
Structure de ce livre .................................................................................................................. xvi
À propos de la licence ............................................................................................................. xvii
Outils et licenses d’utilisation ................................................................................................... xvii
Assistance ............................................................................................................................... xviii
Précisions sur le glossaire ........................................................................................................ xviii
En ce qui concerne la lecture .................................................................................................. xviii
1. Concepts et outils ......................................................................................................................... 1
Systèmes d’exploitation ............................................................................................................... 1
Ce qu’est un noyau ............................................................................................................. 1
Différents types de noyaux .......................................................................................... 1
Ce que propose un système d’exploitation .......................................................................... 2
Fonctions d’un système d’exploitation ......................................................................... 2
Exemples de systèmes d’exploitation ........................................................................... 3
Mémoire virtuelle ................................................................................................................ 3
Ordonnancement ................................................................................................................ 4
Objectifs d’un ordonnanceur ............................................................................................... 4
Critères d’ordonnancement ................................................................................................. 5
Concepts et terminologie ............................................................................................................ 6
Versions de Windows .......................................................................................................... 6
Examen de la version courante du système d’exploitation ............................................ 6
Fonctions, services et routines ............................................................................................. 8
Documentation ........................................................................................................... 9
Processus, threads et autres unités fonctionnelles ............................................................... 10
Gestionnaire des tâches ............................................................................................ 11
Registre ............................................................................................................................. 12
Notation hongroise ........................................................................................................... 13
Généralités ................................................................................................................ 13
Nommage des identifiants ......................................................................................... 14
Histoire ..................................................................................................................... 14
Notation hongroise Apps .......................................................................................... 15
Notation hongroise Systems ...................................................................................... 15
Raison d’être et avantages ........................................................................................ 16
Inconvénients ............................................................................................................ 16
MSDN (Microsoft Developer Network) ............................................................................... 17
Sites web .................................................................................................................. 18
Bibliothèque MSDN .......................................................................................... 18
Forums .............................................................................................................. 18
Blogs ................................................................................................................ 18
Base de connaissances ...................................................................................... 19
Magazine .................................................................................................................. 19
Traduction automatique ............................................................................................. 19
Mode utilisateur et mode noyau ........................................................................................ 19
Anneaux de protection .............................................................................................. 20
Visualisation des temps utilisateur et noyau ................................................................ 21
Windows-1252 et Unicode ................................................................................................ 22
Déterminer si un texte est ANSI ou UNICODE ........................................................... 23
UNC (Uniform Naming Convention) ................................................................................... 24
Système de fichiers ........................................................................................................... 24
Services ............................................................................................................................. 25
Espace de noms ............................................................................................................... 25
API Windows .................................................................................................................... 26
Historique ................................................................................................................. 26
Composants de l’API Windows .................................................................................. 27

iii
Dans les coulisses de
Microsoft Windows

Autres implémentations ............................................................................................. 27


API Native ......................................................................................................................... 28
API noyau ......................................................................................................................... 28
Objets et handles .............................................................................................................. 29
Interface binaire-programme .............................................................................................. 30
Mot machine et types fondamentaux ......................................................................... 30
Microsoft Management Console (MMC) ............................................................................. 31
Composants logiciels enfichables ............................................................................... 32
Modes d’accès d’une console MMC .......................................................................... 32
Exécuter une console en mode Auteur .............................................................. 33
Invite de commandes (Cmd) .............................................................................................. 33
Démarrer des programmes ........................................................................................ 33
Syntaxe de la ligne de commande Cmd .................................................................... 33
Commandes de base ................................................................................................ 34
Interprètes de commandes ................................................................................................ 36
Fonctionnalités de Windows .............................................................................................. 37
Ajouter ou supprimer des fonctionnalités Windows .................................................... 37
Windows Update ............................................................................................................... 38
Pilotes de périphérique ..................................................................................................... 38
Panneau de configuration .................................................................................................. 39
GUID ................................................................................................................................ 40
Polices et fontes ............................................................................................................... 40
Au coeur de Windows ............................................................................................................... 40
Build libre et build controlé ............................................................................................... 41
Vérification de la version (build) exécutée .................................................................. 42
DebugView ....................................................................................................................... 42
Flux de sortie de déboggage .................................................................................... 42
Coup d’oeil sur l’interface DebugView ....................................................................... 43
Enregistrement du flux de sortie mode utilisateur ....................................................... 44
Capture du flux de sortie mode noyau ....................................................................... 45
Contrôle à distance ................................................................................................... 45
Enregistrement et journaux ........................................................................................ 46
Handle .............................................................................................................................. 46
Tasklist .............................................................................................................................. 47
Utilitaires Sysinternals ........................................................................................................ 47
Configuration et utilisation des symboles ........................................................................... 48
Que sont les fichiers de symboles ? ........................................................................... 48
Chemin des symboles ............................................................................................... 48
Validation des symboles ............................................................................................ 49
BCDEdit ............................................................................................................................ 50
Gestion de l’ordinateur ...................................................................................................... 50
Utilitaire Configuration du système (Msconfig) .................................................................... 51
Utilitaires d’administration .................................................................................................. 51
Variables d’environnement ................................................................................................. 52
Console Windows ............................................................................................................. 53
Observateur d’événements ................................................................................................ 53
LiveKd ............................................................................................................................... 54
Driver Verifier .................................................................................................................... 54
2. Architecture du système ............................................................................................................. 55
Architecture générale de Microsoft Windows ............................................................................. 55
Fichiers système fondamentaux ......................................................................................... 55
Aperçu de l’architecture .................................................................................................... 56
Approche en couches ....................................................................................................... 57
Objectifs de conception ............................................................................................................ 58
Fiabilité et robustesse ....................................................................................................... 58

iv
Dans les coulisses de
Microsoft Windows

Haute performance ........................................................................................................... 60


Internationalisation ............................................................................................................ 61
Extensibilité ....................................................................................................................... 62
Compatibilité .................................................................................................................... 63
Portabilité ......................................................................................................................... 64
Sécurité ............................................................................................................................. 65
Modèle de système d’exploitation ............................................................................................. 67
Systèmes multi-utilisateur .................................................................................................. 67
Sous-systèmes d’environnement ................................................................................................ 68
Bibliothèques de sous-système .......................................................................................... 69
Informations de démarrage de sous-système ..................................................................... 69
Environnement MS-DOS (NTVDM) ..................................................................................... 70
Sous-systèmes et création de processus ............................................................................. 70
Composants fondamentaux du système ..................................................................................... 71
Ntdll.dll ............................................................................................................................. 71
Exécutif ............................................................................................................................. 72
Gestionnaire de processus ......................................................................................... 72
Gestionnaire de mémoire virtuelle ............................................................................. 73
Couche d’abstraction matérielle (HAL) ............................................................................... 73
Processus système fondamentaux ...................................................................................... 74
Processus inactif du système ...................................................................................... 75
Winlogon .................................................................................................................. 75
Userinit ..................................................................................................................... 76
Wininit ...................................................................................................................... 76
SMSS (Session Manager Subsystem) .......................................................................... 77
Processus système initial ............................................................................................ 78
Sous-système Windows ..................................................................................................... 78
Graphics Device Interface (GDI) ................................................................................. 79
SYSTEM_INFORMATION_CLASS ................................................................................................ 80
NUMA ...................................................................................................................................... 90
Hyperthread .............................................................................................................................. 91
Multitraitement .......................................................................................................................... 92
Multitâche ................................................................................................................................. 92
3. Mécanismes système ................................................................................................................... 94
Windows on Windows ............................................................................................................... 94
Wow32 ............................................................................................................................. 94
Considérations sur la compatibilité 16 bits ................................................................. 95
Limitations et restrictions concernant Wow32 ............................................................. 95
Wow64 ............................................................................................................................. 95
Composants Wow64 ................................................................................................. 96
Espace d’adressage des processus Wow64 ................................................................ 96
Appels système ......................................................................................................... 96
Impression ................................................................................................................. 97
Performances de Wow64 ........................................................................................... 97
Communication entre processus Wow64 et processus natifs ........................................ 98
Pilotes en mode noyau .............................................................................................. 98
Limitations et restrictions inhérentes à Wow64 ........................................................... 98
Redirection du système de fichiers ............................................................................. 99
Variables d’environnement ....................................................................................... 100
Flags globaux de Windows ...................................................................................................... 100
Logiciel Global Flags ....................................................................................................... 102
Flags globaux d’image .................................................................................................... 103
Commande d’extension !gflag ......................................................................................... 104
Options d’exécution d’image ................................................................................................... 106
Performances .......................................................................................................................... 107

v
Dans les coulisses de
Microsoft Windows

Compteurs de performance ............................................................................................. 107


Analyseur de performances (Perfmon) .............................................................................. 107
Ensembles de collecteurs de données ............................................................................. 109
Ensembles de collecteurs de données intégrés ........................................................ 109
Création d’un ensemble de collecteurs de données .................................................. 109
Création de collecteurs depuis l’invite de commandes .............................................. 110
Moniteur de fiabilité ........................................................................................................ 111
Accéder au moniteur de fiabilité .............................................................................. 111
Index de stabilité système ....................................................................................... 112
Windows System Assessment Tool (WinSAT) ..................................................................... 112
Emplacements du registre ....................................................................................... 112
WEI (Windows Experience Index) ............................................................................. 113
Emplacements de registre pour WinSAT .................................................................. 113
Composants de l’architecture Performances ..................................................................... 114
PLA (Performance Logs and Alerts) .................................................................................. 114
PDH (Performance Data Helper) ....................................................................................... 115
Fonctions PHD ........................................................................................................ 115
Codes d’erreur ........................................................................................................ 115
Event Tracing for Windows ...................................................................................................... 118
Windows Resource Protection .................................................................................................. 118
Vérificateur de ressources (Sfc) ......................................................................................... 119
Threads système auxiliaires ...................................................................................................... 120
LPC (Local Procedure Call) ....................................................................................................... 121
APC (Asynchronous Procedure Calls) ........................................................................................ 123
IRQL ....................................................................................................................................... 124
4. Mécanismes de gestion ............................................................................................................. 126
Registre ................................................................................................................................... 126
Origines du registre ........................................................................................................ 126
Composants du registre .................................................................................................. 127
Scénarios d’utilisation du Registre .................................................................................... 127
Organisation du registre .................................................................................................. 128
Types de données du registre .......................................................................................... 128
REG_BINARY ........................................................................................................... 129
REG_DWORD .......................................................................................................... 129
REG_EXPAND_SZ .................................................................................................... 129
REG_FULL_RESOURCE_DESCRIPTOR ...................................................................... 129
REG_LINK ............................................................................................................... 129
REG_MULTI_SZ ........................................................................................................ 130
REG_NONE ............................................................................................................. 130
REG_QWORD ......................................................................................................... 130
REG_RESOURCE_LIST ............................................................................................. 130
REG_SZ ................................................................................................................... 130
Structure du registre ........................................................................................................ 130
Clés volatiles ........................................................................................................... 130
Clés racines ............................................................................................................. 130
HKEY_CURRENT_USER ............................................................................................ 131
HKEY_CURRENT_USER ............................................................................................ 131
HKEY_LOCAL_MACHINE ......................................................................................... 132
HKLM\SECURITY ............................................................................................. 132
HKLM\HARDWARE .......................................................................................... 132
HKLM\SOFTWARE ........................................................................................... 133
HKLM\SYSTEM ................................................................................................ 133
HKLM\SYSTEM\CurrentControlSet .................................................................... 133
HKEY_PERFORMANCE_DATA .................................................................................. 133
HKEY_CURRENT_CONFIG ....................................................................................... 134

vi
Dans les coulisses de
Microsoft Windows

HKEY_CLASSES_ROOT ............................................................................................ 134


Visualisation et modification du Registre .......................................................................... 134
Editeur du Registre ................................................................................................. 135
Manipuler le registre via Windows PowerShell .......................................................... 135
Fichiers d’inscription ................................................................................................ 135
Utilitaire Reg (Reg.exe) ............................................................................................ 136
Registre et sécurité .......................................................................................................... 137
Callbacks de registre ....................................................................................................... 138
Registre et droits d’accès ................................................................................................ 138
NtQueryKey .................................................................................................................... 139
Services ................................................................................................................................... 140
Applications service ......................................................................................................... 141
Type de services .............................................................................................................. 142
Etats d’un service ............................................................................................................ 143
Démarrage des services ................................................................................................... 143
Acceptation de l’amorçage .............................................................................................. 144
SCM (Service Control Manager) ....................................................................................... 145
Objectifs de conception des services Windows ................................................................ 145
Services Windows et tâches planifiées .............................................................................. 146
Comptes de services ....................................................................................................... 146
Compte système local ............................................................................................. 147
Compte service réseau ............................................................................................ 148
Compte service local ............................................................................................... 148
Exécution de service sous un compte suppléant ....................................................... 148
Démarrage automatique différé ....................................................................................... 149
Gérer les services ............................................................................................................ 149
Service Control (Sc.exe) ........................................................................................... 150
Onglet Services du Gestionnaires des tâches ........................................................... 151
Erreur de démarrage ....................................................................................................... 151
Sécurité des services ....................................................................................................... 152
Contrôle des services ...................................................................................................... 152
Erreur des services .......................................................................................................... 153
Arrêt des services ............................................................................................................ 153
Processus partagés entre des services .............................................................................. 154
Tâches planifiées ..................................................................................................................... 155
SchTasks .......................................................................................................................... 155
Protection et restauration du système ...................................................................................... 155
Créer un point de restauration ......................................................................................... 155
Restaurer les fichiers et paramètres système ..................................................................... 156
Windows Management Instrumentation (WMI) .......................................................................... 156
Fonctionnalités de WMI ................................................................................................... 157
Architecture WMI ............................................................................................................ 157
PowerShell .............................................................................................................................. 158
Considérations sur les langages de script dans Microsoft Windows .................................... 158
Vue d’ensemble de Windows PowerShell ......................................................................... 159
Environnements interactif et de script ...................................................................... 159
Orientation objet ..................................................................................................... 160
Types de commandes PowerShell .................................................................................... 160
Applets de commande ............................................................................................ 160
Fonctions shell ........................................................................................................ 161
Commandes natives ................................................................................................ 161
Scripts ..................................................................................................................... 162
WER (Windows Error Reporting) ............................................................................................... 163
Journaux d’événements ........................................................................................................... 163
Types d’événements ........................................................................................................ 164

vii
Dans les coulisses de
Microsoft Windows

5. Gestionnaire d’objets ................................................................................................................ 165


Gestionnaire d’objets ............................................................................................................... 165
Structure des objets
............................................................................................................................................... 166
Objets noyau .......................................................................................................................... 167
Objets exécutif ........................................................................................................................ 167
Objets type ............................................................................................................................. 168
Méthodes d’objet .................................................................................................................... 172
Noms des objets ..................................................................................................................... 173
Objets de base nommés ................................................................................................. 174
WinObj ................................................................................................................................... 175
Objet lien symbolique ............................................................................................................. 176
Répertoires d’objet .................................................................................................................. 177
Objets temporaires et objets permanents ................................................................................ 178
Partage d’objets entre processus ............................................................................................. 178
Handles d’objet et table des handles de processus .................................................................. 179
Rétention des objets ............................................................................................................... 180
Sécurité des objets .................................................................................................................. 180
OBJECT_INFORMATION_CLASS ............................................................................................. 181
6. Synchronisation .......................................................................................................................... 183
Exclusion mutuelle ................................................................................................................... 183
Synchronisation au niveau IRQL bas ......................................................................................... 184
Sémaphores .................................................................................................................... 184
À propos générique concernant les sémaphores ...................................................... 184
Structure de données .............................................................................................. 184
Interfaces Windows de sémaphore ........................................................................... 185
Compteur et état de signal de sémaphores .............................................................. 185
Partage d’objets sémaphore .................................................................................... 186
Limite ...................................................................................................................... 186
Synchronisation sur le plan utilisateur ....................................................................................... 186
Sections critiques ............................................................................................................ 186
Généralités .............................................................................................................. 187
Utilisation ................................................................................................................ 187
Extension de commande !cs .................................................................................... 188
Structures de données et mécanismes internes ........................................................ 189
Liste des sections critiques de processus .................................................................. 190
Sections critiques et événements à clé ..................................................................... 191
Limites .................................................................................................................... 192
Sections critiques et systèmes multi processeurs ....................................................... 192
Délai de sections critiques ....................................................................................... 192
Variables conditionnelles .................................................................................................. 193
Verrous lecture-écriture .................................................................................................... 193
Mutex ..................................................................................................................................... 195
Mutex noyau ................................................................................................................... 196
Mutex abandonné ........................................................................................................... 197
Mutex rapides ......................................................................................................................... 197
Spinlocks ................................................................................................................................. 198
Spinlocks en file ...................................................................................................................... 199
Spinlocks en file dynamiques ................................................................................................... 201
Spinlocks lecture/écriture ......................................................................................................... 201
Pushlocks ................................................................................................................................ 201
Événements ............................................................................................................................. 202
Evénements à clé .................................................................................................................... 204
Evénements appariés ............................................................................................................... 205
Ressources exécutif ................................................................................................................. 206

viii
Dans les coulisses de
Microsoft Windows

Objets noyau dispatcher .......................................................................................................... 208


Rundown ................................................................................................................................. 210
Minuteries (timers) ................................................................................................................... 210
Opérations inter verrouillées .................................................................................................... 213
7. Processus et threads ................................................................................................................. 214
Dans les coulisses des processus ............................................................................................. 214
Structure de données ...................................................................................................... 214
Objet processus de l’exécutif (EPROCESS) ............................................................... 214
Visualisation du format de la structure EPROCESS ............................................ 215
Objet processus du noyau (KPROCESS) ................................................................... 220
PEB (Process Environment Block) ............................................................................. 223
Visualisation des données du bloc PEB ............................................................ 224
Examen du bloc PEB ....................................................................................... 225
Attributs du bloc PEB ...................................................................................... 226
Bloc Win32Process .................................................................................................. 229
Interfaces ........................................................................................................................ 229
Variables noyau ............................................................................................................... 230
Visualisation des processus actifs ..................................................................................... 230
Examen des processus via le Gestionnaire des tâches ....................................................... 231
Flux de CreateProcess ..................................................................................................... 233
Hiérarchie de processus ................................................................................................... 233
Processus inactif du système ............................................................................................ 235
Processus protégés .......................................................................................................... 236
Identité de processus ...................................................................................................... 237
Identifiant de processus ................................................................................................... 237
Visualisation des informations d’identité d’un processus ............................................ 238
Heures de processus ....................................................................................................... 239
Visualisation des heures de processus ...................................................................... 239
Image exécutée ............................................................................................................... 240
Visualisation de l’image support d’un processus ....................................................... 240
Processus créateur ........................................................................................................... 240
Visualisation des liens de parenté entre deux processus .................................................... 240
Création de processus ..................................................................................................... 241
Processus et synchronisation ............................................................................................ 242
Gérer les processus ......................................................................................................... 242
Handles d’instances ......................................................................................................... 242
Pseudo-handles ............................................................................................................... 242
Notifications de niveau processus .................................................................................... 243
Notification de création et suppression des processus .............................................. 243
Terminaison de processus ................................................................................................ 243
Bureau ............................................................................................................................ 244
Station-fenêtre ................................................................................................................. 246
Enumération de processus ............................................................................................... 247
Sécurité des processus .................................................................................................... 247
Service NtQueryInformationProcess .................................................................................. 248
Liste des processus actifs ................................................................................................. 252
Dans les coulisses des threads ................................................................................................. 252
Généralités concernant les threads .................................................................................. 252
Fonctions ........................................................................................................................ 252
Structure de données ...................................................................................................... 252
Bloc thread de l’exécutif (ETHREAD) ........................................................................ 253
Bloc thread du noyau (KTHREAD) ............................................................................ 255
TEB (Thread Environment Block) .............................................................................. 261
Région et bloc de contrôle du processeur
............................................................................................................................... 264

ix
Dans les coulisses de
Microsoft Windows

Variables noyau ............................................................................................................... 270


Compteurs de performance des threads .......................................................................... 271
Restrictions concernant les threads des processus protégées ............................................ 271
Thread courant ................................................................................................................ 272
Identifiant de thread ........................................................................................................ 272
Terminaison de threads ................................................................................................... 272
Annulation de threads ..................................................................................................... 273
Création de threads ......................................................................................................... 273
Sécurité des threads ........................................................................................................ 274
THREADINFOCLASS ........................................................................................................ 275
Heures de thread ............................................................................................................ 277
Traitement multithread ..................................................................................................... 278
Notifications de niveau thread ......................................................................................... 278
Threads système .............................................................................................................. 278
Ordonnancement des threads .................................................................................................. 279
États d’un thread ............................................................................................................. 279
Fonctions Windows d’ordonnancement ............................................................................ 280
Contexte d’exécution ...................................................................................................... 281
Commutation de contexte ............................................................................................... 282
Classes de priorité ........................................................................................................... 283
Suspension et reprise de thread ...................................................................................... 284
Affinité ............................................................................................................................ 284
Thread inactif .................................................................................................................. 286
Accélérations de priorité .................................................................................................. 286
Scénarios d’ordonnancement ........................................................................................... 286
Basculement volontaire ............................................................................................ 287
Préemption ............................................................................................................. 287
Fin de quantum ...................................................................................................... 287
Fin .......................................................................................................................... 287
Généralités sur l’ordonnancement dans Windows ............................................................. 287
Quantum ......................................................................................................................... 288
Accroissement de quantum ............................................................................................. 288
Processeur idéal .............................................................................................................. 289
Base de données du dispatcher ....................................................................................... 289
Systèmes multi processeur ............................................................................................... 290
Systèmes NUMA ..................................................................................................... 290
Systèmes hyperthread ............................................................................................. 290
Algorithmes d’ordonnancement multi processeur ..................................................... 290
DLL (Dynamic Link Library) ....................................................................................................... 291
Fonctions ........................................................................................................................ 292
Communication inter processus ............................................................................................... 293
Canaux de transmission ................................................................................................... 293
Tubes anonymes et tubes nommés .......................................................................... 293
Opérations sur des tubes nommés ........................................................................... 293
Passage de messages ...................................................................................................... 293
WM_COPYDATA .............................................................................................................. 299
Fibres ...................................................................................................................................... 300
Débogage ............................................................................................................................... 300
Objets job ............................................................................................................................... 301
Conclusion .............................................................................................................................. 309
8. IPC ............................................................................................................................................. 310
Tubes ...................................................................................................................................... 310
Atomes globaux ...................................................................................................................... 310
9. Gestion de la mémoire .............................................................................................................. 312
Principes de base de la mémoire ............................................................................................. 312

x
Dans les coulisses de
Microsoft Windows

ROM ............................................................................................................................... 312


Gestionnaire de mémoire ........................................................................................................ 312
Gestion du tas ........................................................................................................................ 313
Sur la notion de tas ......................................................................................................... 313
Tas et processus .............................................................................................................. 313
Gestionnaire de tas ......................................................................................................... 314
Structure du gestionnaire de tas .............................................................................. 315
Fonctions Windows de tas ............................................................................................... 315
Synchronisation de tas ..................................................................................................... 315
Verrouillage du tas .......................................................................................................... 316
Fonctionnalités de débogage du tas ................................................................................ 316
Visualisation des tas d’un processus ................................................................................. 317
ASLR (Address Space Layout Randomization) ........................................................................... 319
Copy-on-write ......................................................................................................................... 320
Réservation et engagement de pages ...................................................................................... 321
Informations concernant l’espace d’adressage .................................................................. 322
Stratégies d’allocation ..................................................................................................... 322
Protection de la mémoire ........................................................................................................ 323
DEP (Data Execution Prevention) ..................................................................................... 325
DEP de niveau logiciel ............................................................................................ 326
Verrouillage de la mémoire ...................................................................................................... 327
Ecrivain de pages modifiées .................................................................................................... 327
Examen du thread exécutant l’écrivain de pages modifiés ................................................ 327
Défauts de page ..................................................................................................................... 328
Page système partagée ........................................................................................................... 328
Pools de mémoire système ...................................................................................................... 330
Pool tagging ................................................................................................................... 331
Taille des pools ............................................................................................................... 331
Granularité d’allocation ............................................................................................................ 332
Grandes et petites pages ........................................................................................................ 332
Géographie de l’espace d’adressage virtuel ............................................................................. 332
Géographie de l’espace d’adressage utilisateur x86 ................................................................. 333
Géographie de l’espace d’adressage système x86 .................................................................... 334
Traduction d’adresse ................................................................................................................ 334
Répertoire de pages ........................................................................................................ 334
Working set système ............................................................................................................... 335
Base de données PFN ............................................................................................................. 335
Thread de page à zéro ............................................................................................................ 336
Listes look-aside ...................................................................................................................... 336
Pagination à la demande ......................................................................................................... 336
Prefetcher ................................................................................................................................ 337
Working sets ........................................................................................................................... 337
VAD (Virtual Address Descriptor) .............................................................................................. 338
Page de garde ........................................................................................................................ 338
Fichiers de pagination ............................................................................................................. 338
Objets section ......................................................................................................................... 339
10. Portable Executable ................................................................................................................ 343
Historique ............................................................................................................................... 343
Vue d’ensemble du format ...................................................................................................... 343
Structure d’un fichier PE .......................................................................................................... 344
Entête MS-DOS ............................................................................................................... 344
Micro-programme mode réel ........................................................................................... 344
Entête PE ........................................................................................................................ 344
Types de machine ................................................................................................... 345
Caractéristiques ....................................................................................................... 346

xi
Dans les coulisses de
Microsoft Windows

Entête optionnelle ........................................................................................................... 347


DllCharacteristics ..................................................................................................... 351
Sous-système d’environnement ................................................................................ 352
Répertoires ...................................................................................................................... 352
Entête de sections ........................................................................................................... 353
Dumpbin ................................................................................................................................. 355
Chargeur d’image ................................................................................................................... 356
Base de données des modules ........................................................................................ 357
11. Sécurité ................................................................................................................................... 358
Composants du système de sécurité ........................................................................................ 358
SRM (Security Reference Monitor) ............................................................................................ 359
Contrôle d’accès ..................................................................................................................... 359
Jetons d’accès ................................................................................................................. 359
Jetons restreints ...................................................................................................... 365
Structure commune de sécurité ....................................................................................... 366
Descripteurs de sécurité .................................................................................................. 366
ACL ................................................................................................................................ 367
ACE ................................................................................................................................ 367
DACL .............................................................................................................................. 368
SACL ....................................................................................................................... 369
SID (Security Identifier) .................................................................................................... 369
Niveaux d’intégrité .......................................................................................................... 372
LSASS (Local Security Authority Subsystem Service) .......................................................... 374
Stratégies de restriction logicielle ............................................................................................ 375
Règles de stratégies et niveaux de sécurité ...................................................................... 376
Exceptions ....................................................................................................................... 376
Conflits de règles ............................................................................................................ 377
Paramètres de stratégies ................................................................................................. 377
Configurer les stratégies de restriction logicielle ............................................................... 377
Windows Defender .................................................................................................................. 377
Paramètrer Windows Defender ........................................................................................ 378
Compatibilité avec ELAM ................................................................................................ 379
Analyser la station de travail avec Windows Defender ...................................................... 379
Définitions de virus et autres programmes malveillants ..................................................... 379
Service WinDefend .......................................................................................................... 380
Automatisation de Windows Defender via PowerShell ...................................................... 380
Mise en quarantaine et autorisation des programmes ....................................................... 381
ELAM (Early Launch Anti-Malware) ........................................................................................... 381
Désactiver ELAM ............................................................................................................. 381
Situation d’ELAM dans la séquence de démarrage ........................................................... 382
Fonctionnement interne de ELAM ................................................................................... 382
SmartScreen ............................................................................................................................ 382
Configuration de SmartScreen ......................................................................................... 383
Contrôles de réputation SmartScreen ............................................................................... 383
Authenticode ........................................................................................................................... 384
Protection par Authenticode ............................................................................................ 385
Autorités de confiance ..................................................................................................... 385
Anatomie d’une signature numérique Authenticode ......................................................... 385
Limitations d’Authenticode .............................................................................................. 386
Kernel Patch Protection (PatchGuard) ....................................................................................... 386
Code Integrity ......................................................................................................................... 387
BitLocker ................................................................................................................................. 388
Droits utilisateur et privilèges .................................................................................................. 388
Droits utilisateur ...................................................................................................................... 388
Privilèges ................................................................................................................................. 389

xii
Dans les coulisses de
Microsoft Windows

Secure Boot ............................................................................................................................ 394


Emprunt d’identité .................................................................................................................. 394
Utilisateurs et groupes ............................................................................................................. 395
Comptes utilisateurs et comptes de groupes .................................................................... 395
Comptes utilisateurs ........................................................................................................ 395
Comptes utilisateurs locaux ............................................................................................. 395
Comptes utilisateurs prédéfinis ........................................................................................ 396
Compte Administrateur ........................................................................................... 396
Compte Invité ......................................................................................................... 396
Comptes utilisateurs prédéfinis système ................................................................... 396
Comptes d’utilisateurs de domaine .................................................................................. 396
Comptes de groupes ....................................................................................................... 397
UAC ................................................................................................................................ 398
Choisir le taux d’intervention du Contrôle du compte d’utilisateur ............................. 399
Exécuter un programme en tant qu’administrateur ........................................................... 400
Utilitaire Whoami ............................................................................................................. 400
Commande Runas ........................................................................................................... 400
Droits d’accès .......................................................................................................................... 400
12. Réseau ..................................................................................................................................... 403
Modèle OSI ............................................................................................................................ 403
Commandes net ...................................................................................................................... 403
Netsh ...................................................................................................................................... 404
Résolution de noms ................................................................................................................. 405
WINS (Windows Internet Name Service) ................................................................................... 405
Composants de mise en réseau Windows ................................................................................ 405
Windows Filtering Platform (WFP) ............................................................................................ 406
DFS (Distributed File System) ................................................................................................... 406
Active Directory ....................................................................................................................... 407
TDI .......................................................................................................................................... 407
Remote Differential Compression (RDC) ................................................................................... 407
Winsock .................................................................................................................................. 407
13. Système d’E/S ......................................................................................................................... 409
Composants du système d’E/S ................................................................................................ 409
Gestionnaire d’entrée/sortie ..................................................................................................... 409
E/S synchrones et E/S asynchrones .......................................................................................... 410
E/S scatter/gather .................................................................................................................... 410
IRP (I/O Request Packet) .......................................................................................................... 410
Gestionnaire de périphériques ................................................................................................. 413
Pilotes de périphériques .......................................................................................................... 414
Types de pilotes .............................................................................................................. 415
Structure d’un pilote ........................................................................................................ 416
Objet pilote ............................................................................................................................ 417
Objet périphérique .................................................................................................................. 418
Types de périphériques ........................................................................................................... 419
E/S rapides (Fast I/O) .............................................................................................................. 421
Plug and Play .......................................................................................................................... 422
Gestionnaire Plug and Play .............................................................................................. 422
Installation de pilotes ...................................................................................................... 423
Niveau de prise en charge Plug and Play ......................................................................... 423
Pilotes Plug and Play ....................................................................................................... 423
Pilotes non Plug and Play ................................................................................................ 424
Objet fichier ............................................................................................................................ 424
Énumération des périphériques ............................................................................................... 426
Attributs de niveau fichier ........................................................................................................ 427
FILE_INFORMATION_CLASS .................................................................................................... 428

xiii
Dans les coulisses de
Microsoft Windows

Gestion des fichiers ................................................................................................................. 431


Droits d’accès aux fichiers ....................................................................................................... 432
Ports de complétion ................................................................................................................ 433
Gestion des tampons IRP ........................................................................................................ 433
WDM et WDF ......................................................................................................................... 434
14. Gestion de l’alimentation ........................................................................................................ 436
Gestionnaire d’alimentation ..................................................................................................... 436
Schémas d’alimentation ........................................................................................................... 439
15. Gestion du stockage ............................................................................................................... 442
Types de stockage disque ....................................................................................................... 442
Disques de base ..................................................................................................................... 442
Etats des disques et des volumes ............................................................................................ 442
Administration des disques ...................................................................................................... 443
Utilitaire Gestion des disques .......................................................................................... 443
Mise à jour des informations de l’outil Gestion des disques ...................................... 444
Console Ordinateur ......................................................................................................... 444
DiskPart ........................................................................................................................... 444
Fsutil ............................................................................................................................... 444
ReadyBoost ............................................................................................................................. 445
ReadyDrive .............................................................................................................................. 445
16. Systèmes de fichiers ................................................................................................................ 446
Terminologie relative aux systèmes de fichiers .......................................................................... 446
Montage et démontage .......................................................................................................... 446
Formats de système de fichiers Windows ................................................................................. 446
ISO-9660 ......................................................................................................................... 447
Joliet ............................................................................................................................... 447
UDF ................................................................................................................................ 448
FAT12, FAT16 et FAT32 ................................................................................................... 448
exFAT .............................................................................................................................. 448
Unité d’allocation .................................................................................................................... 448
Étude du système FAT ............................................................................................................ 449
NTFS ....................................................................................................................................... 451
Noms Unicode ................................................................................................................ 452
Versions de NTFS ............................................................................................................ 452
Gestion des fichiers et répertoires ........................................................................................... 452
17. Démarrage et arrêt ................................................................................................................. 454
BootRec .................................................................................................................................. 454
Dernière bonne configuration connue ...................................................................................... 454
Mode sans échec .................................................................................................................... 454
Programmes utilisateur reconnaissant le mode sans échec ................................................ 455
Processus de démarrage .......................................................................................................... 455
Phase d’autotest d’allumage ............................................................................................ 455
Phase du chargeur de démarrage Windows ..................................................................... 456
Initialisation du noyau ...................................................................................................... 456
Gestionnaire de sessions (Smss) ....................................................................................... 457
Winlogon ........................................................................................................................ 458
Userinit ............................................................................................................................ 458
BCD ........................................................................................................................................ 458
18. Gestionnaire de cache ............................................................................................................. 462
Fonctionnalités clé du gestionnaire de cache ........................................................................... 462
Cohérence du cache ....................................................................................................... 462
Cache et systèmes de fichiers récupérables ...................................................................... 462
Écritures immédiates du cache ................................................................................................ 462
Désactivation de la mise en cache ........................................................................................... 463
Structures de données du cache .............................................................................................. 463

xiv
Dans les coulisses de
Microsoft Windows

Structures de données globales du cache ........................................................................ 463


Structures de données de niveau fichier du cache ............................................................ 463
Taille du cache ........................................................................................................................ 464
Taille virtuelle du cache ................................................................................................... 464
Lecture anticipée ..................................................................................................................... 464
Fast I/O .................................................................................................................................. 465
Copie vers et depuis le cache ................................................................................................. 466
Mappage et épinglage ............................................................................................................ 467
Cache et interfaces DMA ......................................................................................................... 467
19. Techniques de débogage ........................................................................................................ 468
Pseudo registres ...................................................................................................................... 468
Débogage par affichage .......................................................................................................... 468
Bug checks ............................................................................................................................. 468
20. Interceptions ............................................................................................................................ 477
Gestion des interruptions ........................................................................................................ 477
Contrôleurs d’interruption x86 ......................................................................................... 477
Contrôleurs d’interruption x64 ......................................................................................... 478
Interruptions matérielles .................................................................................................. 478
Gestion des services système .................................................................................................. 478
Interruptions logicielles ............................................................................................................ 491
DPC (Deferred Procédure Call) ................................................................................................. 491
Gestion des exceptions ........................................................................................................... 492
21. Interfaces ................................................................................................................................. 494
Structures de données ............................................................................................................. 503
KPROCESS ...................................................................................................................... 503
KTHREAD ........................................................................................................................ 503
A. Mémoire virtuelle ...................................................................................................................... 504
B. Objets et handles ...................................................................................................................... 505
C. Sections ..................................................................................................................................... 506
D. Divers ........................................................................................................................................ 507
Glossaire ......................................................................................................................................... 512

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

À qui s’adresse ce livre ?


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

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

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

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

■ Chapitre 2, Architecture du système Ce chapitre effectue un tour d’horizon des caractéristiques


structurales de Windows, définit les grandes lignes de sa structure interne, et examine les liens et
interactions entre les composants clé du système d’exploitation.

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

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

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

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

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

xvi
Introduction

■ Chapitre 8, Communication inter processus

■ Chapitre 9, Gestion de la mémoire

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

■ Chapitre 11, Sécurité

■ Chapitre 12, Réseau

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

■ Chapitre 14, Gestion de l’alimentation

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

■ Chapitre 16, Systèmes de fichiers Ce chapitre présente l’organisation et le fonctionnement interne de


quelques systèmes de fichiers Windows.

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

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

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

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

Outils et licenses d’utilisation


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

xvii
Introduction

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.

xviii
Chapitre 1. 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

1
Concepts et outils

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

2
Concepts et outils

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

3
Concepts et outils

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

4
Concepts et outils

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.

5
Concepts et outils

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.

Tableau 1.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 Juillet 1996
Release), Cairo
Windows 2000 5.0 n/a Décembre 1999
Windows XP 5.1 Whistler Aout 2001
Windows Server 2003 5.2 Whistler Server Mars 2003
Windows Vista 6.0 (Build 6000) Longhorn Janvier 2007
Windows Server 2008 6.0 (Build 6001) Longhorn Server Mars 2008
Windows 7 6.1 Blackcomb, Vienna Octobre 2009
Windows Server 2008 R2 6.1 - Octobre 2009
Windows 8 6.2 Jupiter Janvier 2012
Windows Server 2012 6.2 Windows Server 8 Aout 2012
Windows 8.1 6.3 Blue Octobre 2013
Windows Server 2012 R2 6.3 Windows Server 8 Octobre 2013
Windows 10 10.0 Threshold, Redstone Juillet 2015
Windows Server 2016 10.0 Redstone Server Septembre 2016

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


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

6
Concepts et outils

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

Tableau 1.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

7
Concepts et outils

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.

8
Concepts et outils

■ 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

9
Concepts et outils

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.

10
Concepts et outils

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

11
Concepts et outils

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

12
Concepts et outils

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.

13
Concepts et outils

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

14
Concepts et outils

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.

15
Concepts et outils

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.

16
Concepts et outils

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

17
Concepts et outils

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 :

■ The Old New Thing - http://blogs.msdn.microsoft.com/oldnewthing/

■ Ntdebugging - http://blogs.msdn.com/ntdebugging/

18
Concepts et outils

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

19
Concepts et outils

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

20
Concepts et outils

(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

21
Concepts et outils

partie en mode noyau. En outre, les opérations liées à la gestion des fenêtres et au dessin étant en grande
majorité mises en oeuvre coté noyau, les applications fortement orientées graphismes passent plus de temps
en mode noyau qu’en mode utilisateur.

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

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

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

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

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

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

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

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

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

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

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

22
Concepts et outils

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

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

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

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

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

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

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

Déterminer si un texte est ANSI ou UNICODE


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

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

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

23
Concepts et outils

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

UNC (Uniform Naming Convention)


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

Les dénominations UNC doivent se conformer à la syntaxe \\NOM_SERVEUR\NOM_PARTAGE, dans


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

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

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

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

Tableau 1.3. Systèmes de fichiers de quelques systèmes d’exploitation

Système Système de fichier


MS-DOS FAT, aussi appelé FAT-16 (File Allocation Table 16
bits)
Windows 95/98 FAT32, extension du système FAT-16 (File Allocation
Table 32 bits)
Windows NT et supérieur NTFS (New Technology File System)
OS/2 HPFS (High Performance File System)
Linux Ext4 (Fourth extended file system)

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

24
Concepts et outils

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

25
Concepts et outils

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.

26
Concepts et outils

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

27
Concepts et outils

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.

28
Concepts et outils

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.
Tableau 1.4. Préfixes pour interfaces en mode noyau

Préfixe Composant
Alpc Appel de procédure asynchrone
Cc Gestionnaire de cache
Cm Gestionnaire de configuration
Ex Routines de l’exécutif
FsRtl Bibliothèque d’exécution du pilote de système de
fichiers
Hal Couche d’abstraction matérielle
Io Gestionnaire d’E/S
Ke Noyau
Ldr Chargeur de modules
Lpc Appel de procédure locale
Mm Gestionnaire mémoire
Nt Services système
Ob Gestionnaire d’objets
Po Gestionnaire d’alimentation
Pp Gestionnaire PnP
Ps Gestionnaire de processus
Rtl Bibliothèque d’exécution
Se Sécurité
Wmi Windows Management Instrumentation
Zw Appel système

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

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

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

Si, en surface, peu de signes objectifs conviennent pour établir une distinction claire entre objets et structure
de données ordinaire, quelques différences fondamentales les séparent. D’une part, la structure interne d’un
objet est masquée. Il est pour cette raison indispensable avant d’interagir avec un objet de solliciter les
services prévus à cet effet. D’autre part, l’implémentation du code de gestion des objets (générique par

29
Concepts et outils

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

30
Concepts et outils

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

Tableau 1.5. Quantité de stockage des types fondamentaux

Type LP64 ILP64 LLP64 ILP32 LP32


char 8 8 8 8 8
short 16 16 16 16 16
int 32 64 32 32 16
long 64 64 32 32 32
long long 64 64 64 32 32
pointer 64 64 64 32 32

Microsoft Management Console (MMC)


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

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

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

Nom anglais Nom français Console


Certificates Certificats certmgr.msc
Certificates template Modèles de certificats certtmpl.msc
Indexing Service Service d’indexation ciadv.msc
Component Services Services des composants comexp.msc
Computer Management Gestion de l’ordinateur compmgmt.msc
Device Manager Gestionnaire de périphériques devmgmt.msc

31
Concepts et outils

Nom anglais Nom français Console


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

32
Concepts et outils

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

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

Exécuter une console en mode Auteur

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

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

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

Invite de commandes (Cmd)


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

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

Syntaxe de la ligne de commande Cmd


La syntaxe complète de la ligne de commande associée à Cmd est la suivante :
cmd [/a | /u] [/q] [/d] [/e:on | /e:off] [/f:on | /f:off] [/v:on | /v:off] [[/s] [/c | /k] chaînecommandes]

■ /a | /u Système d’encodage utilisé pour du texte dirigé vers un fichier ou un autre canal de communication.
Utilisez /A pour ANSI et /U pour Unicode.

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

33
Concepts et outils

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.

34
Concepts et outils

ASSOC Affiche ou modifie les applications associées aux extensions


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.

35
Concepts et outils

ASSOC Affiche ou modifie les applications associées aux extensions


de fichiers.
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

36
Concepts et outils

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

37
Concepts et outils

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

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

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

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

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

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

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

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

38
Concepts et outils

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.

Tableau 1.6. Applets de configuration

Applet (cpl) Nom canonique Description


Access.cpl Microsoft.EaseOfAccessCenter Options d’ergonomie
Admintools.cpl Microsoft.AdministrativeTools Outils d’administration
Appwiz.cpl Microsoft.ProgramsAndFeatures Programmes et fonctionnalités
Bthprops   Périphériques Bluetooth
Desk.cpl   Paramètres d’affichage
Firewall.cpl Microsoft.WindowsFirewall Pare-feu Windows Defender
Folders Microsoft.FolderOptions Options de l’Explorateur de
fichiers
Fonts Microsoft.Fonts Polices
Hdwwiz.cpl Microsoft.DeviceManager Gestionnaire de périphériques
Inetcpl.cpl Microsoft.InternetOptions Options Internet
Intl.cpl Microsoft.RegionAndLanguage Options régionales et
linguistiques
Joy.cpl Microsoft.GameControllers Contrôleurs de jeu
  Microsoft.Keyboard Propriétés du clavier
Main Microsoft.Mouse Propriétés de la souris
Mmsys.cpl Microsoft.Sound Son
Nusrmgr.cpl Microsoft.UserAccounts Comptes d’utilisateur
Powercfg.cpl   Options d’alimentation
  Microsoft.DevicesAndPrinters Périphériques et imprimantes
Sysdm.cpl   Propriétés système
Ncpa.cpl   Connexions réseau
Telephon.cpl   Options modems et téléphonie
Timedate Microsoft.DateAndTime Date et heure
Ups.cpl   Options d’alimentation
Wscui.cpl Microsoft.ActionCenter Sécurité et maintenance

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

39
Concepts et outils

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

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

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

Il existe plusieurs types de polices :

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

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

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

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

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

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

Tableau 1.7. Utilitaires de visualisation des coulisses de Windows

Utilitaire Nom de l’image Origine


Startup Programs Viewer AUTORUNS Sysinternals
Global Flags GFLAGS Debugging tools
Débogueur noyau WINDBG, KD Debugging tools, Windows SDK

40
Concepts et outils

Utilitaire Nom de l’image Origine


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

41
Concepts et outils

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

42
Concepts et outils

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.
Figure 1.1. Interface principale de DebugView

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

La seconde colonne correspond à un point donné du traitement des messages de débogage et affiche le
moment où chacun a été enregistré, soit en temps écoulé ou en temps réel. Par défaut, DegugView indique le

43
Concepts et outils

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,

44
Concepts et outils

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.

45
Concepts et outils

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

Vous pouvez enregistrer le contenu de la fenêtre principale de DebugView en choisissant Enregistrer ou


Enregistrer sous à partir du menu Fichier. Pour visualiser le fichier résultant, sélectionnez l’option Ouvrir du
menu Fichier, ou spécifiez le chemin d’accès au fichier sur la ligne de commande.

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

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

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

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

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

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

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

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

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

Quand il n’est pas utilisé pour une recherche avec des critères précis, Handle organise les donnes en autant
de sections logiques que de processus pour lesquels il montre les informations. Une ligne pointillée sert

46
Concepts et outils

de séparateur, après laquelle se trouvent le nom et l’ID du processus. Sous ce nom est présenté la valeur
du descripteur (en hexadécimal), le type de l’objet auquel le descripteur est associé et, s’il en a un, le nom
de l’objet.

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

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

Comma-separated values

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

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

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

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

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

■ Utilitaires de fichiers et de disques Utilitaires permettant de consulter et de surveiller l’accès et l’usage


des fichiers et disques ; parmi lesquels Diskmon, qui capture toute activité du disque dur, et NTFSInfo, qui
permet d’afficher des informations détaillées sur les volumes NTFS.

47
Concepts et outils

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

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

■ Utilitaires de sécurité Utilitaires de configuration et de gestion de la sécurité ; parmi lesquels AccessChk,


qui permet de visualiser le type d’accès à un objet que possède un utilisateur ou un groupe d’utilisateurs,
ou LogonSessions, chargé de répertorier les ouvertures de session actives.

■ Informations système Utilitaires permettant d’examiner l’utilisation et la configuration des ressources


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

Configuration et utilisation des symboles


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

Que sont les fichiers de symboles ?


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

■ Les noms et adresses des variables globales

■ Les noms et adresses des fonctions et leurs signatures

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

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

Chemin des symboles


Le débogueur accède aux fichiers de symboles associés aux images concernées par la session de débogage
en cours. Aussi, pour connaitre quels fichiers sont utiles, et lesquels ne le sont, le débogueur utilise deux

48
Concepts et outils

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

49
Concepts et outils

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

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

MATCH: ntkrnlmp.pdb and ntkrnlmp.exe

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

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

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

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

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

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

Une fois donné le départ à une console Gestion de l’ordinateur, vous êtes alors en mesure d’administrer
l’ordinateur sur laquelle cette console s’exécute (remarquez la mention (Local) au niveau de la première ligne
de l’arborescence). Il est cependant envisageable de se servir de cette même interface en vue d’administrer à
distance une autre station de travail. Pour ce faire, sélectionnez la racine de la console Gestion de l’ordinateur
(Local) puis le menu Action - Se connecter à un autre ordinateur (ou utilisez le menu contextuel). Dans la boite
de dialogue nouvellement apparue, nommée Sélectionner un ordinateur, saisissez le nom pleinement qualifié

50
Concepts et outils

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

51
Concepts et outils

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

Tableau 1.8. Variables d’environnement

Variable Description
%appdata% Chemin d’accès au dossier contenant les
programmes utilisateur (\Program Files par défaut)
%cmdcmdline% Commande utilisée pour accéder à l’interpréteur de
commandes (Cmd.exe)
%computername% Nom de l’ordinateur
%date% Date système
%errorlevel% Code d’erreur de la dernière commande utilisée
%homedrive% Lettre de lecteur identifiant le volume disque où le
dossier de l’utilisateur courant est situé
%homepath% Chemin d’accès au dossier de l’utilisateur courant
%number_of_processor% Nombre de processeur présents dans l’ordinateur
%os% Nom du système d’exploitation installé
%path% Chemin d’accès des programmes système
%pathext% Extensions considérées comme exécutables par le
système
%processor_architecture% Architecture du processeur
%random% Entier choisi aléatoirement
%systemdrive% Lettre de lecteur identifiant le volume disque où le
dossier système (généralement C)
%systemroot% Chemin d’accès au dossier racine du système
%temp% Chemin d’accès au dossier temporaire pour les
applications
%time% Heure système
%userdomain% Domaine auquel appartient le compte utilisateur
courant
%username% Nom de l’utilisateur courant
%userprofile% Emplacement du profil utilisateur du compte
courant

52
Concepts et outils

%windir% Chemin d’accès au dossier Windows (généralement


\WINDOWS)

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

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

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

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

Le tableau qui suit énumère les fonctions utilisables pour accéder à une console.
Tableau 1.9. Fonctions de gestion de la console

Fonction Description
AddConsoleAlias Définit un alias de console pour l’exécutable
spécifié.
AllocConsole Crée une nouvelle console pour le processus
appelant.
AttachConsole Rattache le processus appelant à la console à
laquelle est associé un processus donné.
ReadConsole Lit les caractères en entrée depuis le tampon
d’entrée d’une console donnée.
SetConsoleCP Définit la page de code en vigueur dans la console
associée au processus appelant.
SetConsoleTitle Définit le titre de la fenêtre console courante.
WriteConsole Ecrit une chaîne de caractères dans le tampon de
sortie d’une console donnée.

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

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

53
Concepts et outils

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

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

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

Architecture générale de Microsoft Windows


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

Fichiers système fondamentaux


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

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

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

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

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

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

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

■ Winlogon.exe Ouverture de session.

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

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

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

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

55
Architecture du système

■ 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

56
Architecture du système

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

57
Architecture du système

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

58
Architecture du système

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.

59
Architecture du système

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

Note
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

60
Architecture du système

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.

61
Architecture du système

■ 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

62
Architecture du système

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.

63
Architecture du système

■ 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

64
Architecture du système

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

65
Architecture du système

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 la section intitulée « Kernel Patch Protection (PatchGuard) ».

Pour replacer les choses dans le contexte qui les a vu naître, notez que la mise en conformité de Windows
avec divers processus concernant la sécurité est pour une large part un aspect concomitant des objectifs de

66
Architecture du système

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

67
Architecture du système

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

68
Architecture du système

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

69
Architecture du système

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.

70
Architecture du système

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.

Tableau 2.1. 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

71
Architecture du système

du processus du sous-système Windows (fonctions commençant par Csr), les routines générales de la
bibliothèque d’execution (fonctions commençant par Rtl).

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

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

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

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

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

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

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

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

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

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

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

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

■ Prefetcher logique

Gestionnaire de processus
Le gestionnaire de processus de Windows fournit les services nécessaires à la création, la suppression et
l’utilisation des processus, des threads et des travaux. Il a pour rôle la définition des critères et des attributs

72
Architecture du système

latents au support de ces dispositifs dans le système, et ouvre la voie à leur transposition sous forme
algorithmique, à leur mise en oeuvre, et enfin à leur programmation.

Vu la complexité de la mission à réaliser et la diversité des fonctionnalités à pourvoir, le gestionnaire


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

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

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

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

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

Gestionnaire de mémoire virtuelle


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

La fonction première du gestionnaire de mémoire est l’implémentation de la mémoire virtuelle, à savoir


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

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

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

Couche d’abstraction matérielle (HAL)


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

Vous pouvez évaluer les relations qui unissent les images du noyau (Ntoskrnl.exe) et de la couche
d’abstraction matérielle (Hal.dll) en examinant leurs tables d’importation et d’exportation respectives via
l’utilitaire Dependency Walker (Depends.exe). Vous remarquerez alors que Ntoskrnl est lié à Hal, qui lui-

73
Architecture du système

même est lié à Ntoskrnl. Chacun, en d’autres termes, sollicite et bénéficie des fonctions que l’autre rend
visible.

Processus système fondamentaux


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

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

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

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


interactives.

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

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

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

■ Sous-système Windows (Csrss.exe) Implémente le code mode utilisateur du sous-système


d’environnement Windows. Gère les fenêtres et les éléments graphiques de Windows.

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

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

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

pslist v1.3 - Sysinternals PsList


Copyright (C) 2000-2012 Mark Russinovich
Sysinternals - www.sysinternals.com

Process information for HP:

Name Pid Pri Thd Hnd VM WS Priv


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

74
Architecture du système

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

75
Architecture du système

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

76
Architecture du système

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

77
Architecture du système

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-

78
Architecture du système

système d’environnement. Elles traduisent les fonctions de l’API Windows en appels aux services système,
exécutés en mode noyau, de Ntoskrnl.exe, et Win32k.sys.

Le processus de support via lequel apparaît le sous-système Windows s’appelle en interne Client/Server
Run-Time Subsystem, ceci en référence au mode de communication à travers duquel il était initialement
prévu que les applications communiquent. Dans la conception originelle de Windows, tous les sous-systèmes
devaient être exécutés en tant que threads d’un processus de sous-système d’environnement commun au
système, Csrss.exe. On fit ensuite des sous-systèmes POSIX et OS/2 des processus à part entière, sans pour
autant modifier le nom de fichier du processus du sous-système Windows.

Le sous-système Windows classe les applications en deux catégories : les applications graphiques et
celles fondées sur du texte (mode console). Aux applications graphiques est offert un ensemble d’objets
et de contrôles standards (fenêtres, boutons, etc.) autour desquels construire et orienter le dialogue
homme-machine. Une application à interface caractère, à laquelle le sous-système Windows fournit une
représentation graphique, a sa sortie interactive dirigée vers une fenêtre texte. Chaque fois qu’une routine
de sortie est appelée, le sous-système Windows appelle une routine pour afficher le texte dans la console
associée. Cette façon de faire fonctionne pour toute les applications en ligne de commande.

Du fait de sa proximité avec les services de l’exécutif natif du système, et de son implication avec l’affichage
graphique, le sous-système Windows est indispensable au bon fonctionnement de Windows. Sa présence
étant obligatoire, les informations de démarrage le concernant le veulent toujours actif, alors que les autres
sous-systèmes sont configurés pour être exécutés à la demande. Pour plus d’informations sur comment
Windows démarre un sous-système, consultez la section Démarrage de sous-système.

Graphics Device Interface (GDI)


Jonction entre un système d’exploitation essentiellement graphique et des dispositifs d’affichage et systèmes
d’impression de nature diverses, Graphics Device Interface (GDI) est une interface de Microsoft Windows
pour la représentation d’objets graphiques ainsi que pour leur transmission aux périphériques de sortie,
typiquement un écran ou une imprimante.

La fonction principale de GDI est le dessin d’éléments visuels primitif, à savoir pixels, lignes, polygones et
bitmaps. (Un pixel est le plus petit élément constituant une image graphique ou une surface d’affichage ;
une ligne est un ensemble de points arrangés de façon contiguë ; un polygone est un ensemble de lignes,
placées bout à bout de manière à former une figure contiguë et fermée ; un bitmap est un ensemble de
pixels arrangés dans une configuration rectangulaire, le tout constituant une forme, une image ou une texture
reconnaissable.) GDI contient des fonctions de dessin de traits, de textes et de figures et des fonctions de
gestion des palettes. En revanche, il n’est pas chargé de l’affichage des fenêtres, des menus et autres, cette
tâche étant assignée au gestionnaire de fenêtres.

L’une des particularités remarquables du système GDI est son indépendance vis à vis des dispositifs
physiques, cela au sens d’être capable de s’adapter à une gamme très étendue de combinaisons matérielles,
incluant par exemple cartes graphiques et imprimantes. Avec cet objectif d’indépendance en vue, GDI fournit
des mécanismes au travers desquels créer du contenu graphique sans considération pour le type, donc les
caractéristiques, du matériel utilisé. Il devient alors simple, avec les mêmes instructions, de dessiner à l’écran,
ou d’imprimer sur du papier. GDI connait également des moyens de stockage standardisés pour les images
sur disque ou sur écran.

S’il est certain que l’émancipation de GDI en regard du matériel est un atout, une conséquence directe de
cette indépendance est le manque relatif de performances au niveau de la vitesse d’exécution. En outre, GDI
ne sait pas produire correctement des animations et ne supporte aucune fonctionnalité 3D, contrairement
aux API DirectX et OpenGL, conçues pour exposer les fonctions matérielles 3D des cartes graphiques.

GDI est un composant mode noyau (win32k.sys), élevées au rang d’entités privilégiées afin de s’adresser
directement au matériel et diminuer les temps de réaction de l’IHM. Complétant la politique globale du
noyau quant à la couche matérielle, le système GDI offre des capacités de représentation abstraite des
périphériques cibles et assure la cohérence du dessin sur des interfaces multiples.

79
Architecture du système

SYSTEM_INFORMATION_CLASS
Tableau 2.2. SYSTEM_INFORMATION_CLASS

ID Classe Type de données associé


0x0000 SystemBasicInformation SYSTEM_BASIC_INFORMATION
0x0001 SystemProcessorInformation SYSTEM_PROCESSOR_-
INFORMATION
0x0002 SystemPerformanceInformation SYSTEM_PERFORMANCE_-
INFORMATION
0x0003 SystemTimeOfDayInformation SYSTEM_TIMEOFDAY_-
INFORMATION
0x0004 SystemPathInformation  
0x0005 SystemProcessInformation SYSTEM_PROCESS_-
INFORMATION
0x0006 SystemCallCountInformation  
0x0007 SystemDeviceInformation SYSTEM_DEVICE_INFORMATION
0x0008 SystemProcessorPerformanceInformation
SYSTEM_PROCESSOR_-
PERFORMANCE_INFORMATION
0x0009 SystemFlagsInformation SYSTEM_FLAGS_INFORMATION
0x000A SystemCallTimeInformation  
0x000B SystemModulesInformation SYSTEM_MODULES_-
INFORMATION // RTL_-
PROCESS_MODULES
0x000C SystemLocksInformation RTL_PROCESS_LOCKS
0x000D SystemStackTraceInformation  
0x000E SystemPagedPoolInformation  
0x000F SystemNonPagedPoolInformation  
0x0010 SystemHandleInformation SYSTEM_HANDLE_-
INFORMATION
0x0011 SystemObjectInformation SYSTEM_OBJECT_-
INFORMATION, SYSTEM_-
OBJECTTYPE_INFORMATION
0x0012 SystemPageFileInformation SYSTEM_PAGEFILE_-
INFORMATION
0x0013 SystemVdmInstemulInformation  
0x0014 SystemVdmBopInformation  
0x0015 SystemFileCacheInformation SYSTEM_FILECACHE_-
INFORMATION
0x0016 SystemPoolTagInformation SYSTEM_POOLTAG_-
INFORMATION
0x0017 SystemInterruptInformation SYSTEM_INTERRUPT_-
INFORMATION
0x0018 SystemDpcBehaviorInformation SYSTEM_DPC_BEHAVIOR_-
INFORMATION

80
Architecture du système

ID Classe Type de données associé


0x0019 SystemFullMemoryInformation  
0x001A SystemLoadGdiDriverInformation  
0x001B SystemUnloadGdiDriverInformation 
0x001C SystemTimeAdjustmentInformation SYSTEM_QUERY_TIME_ADJUST_-
INFORMATION, SYSTEM_SET_-
TIME_ADJUST_INFORMATION
0x001D SystemSummaryMemoryInformation 
0x001E SystemMirrorMemoryInformation  
0x001F SystemPerformanceTraceInformation
 
0x0020 SystemCrashDumpInformation  
0x0021 SystemExceptionInformation SYSTEM_EXCEPTION_-
INFORMATION
0x0022 SystemCrashDumpStateInformation 
0x0023 SystemKernelDebuggerInformationSYSTEM_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 SystemCurrentTimeZoneInformationRTL_TIME_ZONE_INFORMATION
0x002D SystemLookasideInformation  
0x002E SystemTimeSlipNotification  
0x002F SystemSessionCreate  
0x0030 SystemSessionDetach  
0x0031 SystemSessionInformation  
0x0032 SystemRangeStartInformation  
0x0033 SystemVerifierInformation  
0x0034 SystemVerifierThunkExtend  
0x0035 SystemSessionProcessInformation  
0x0036 SystemLoadGdiDriverInSystemSpace
 
0x0037 SystemNumaProcessorMap  
0x0038 SystemPrefetcherInformation  
0x0039 SystemExtendedProcessInformation 
0x003A SystemRecommendedSharedDataAlignment
 

81
Architecture du système

ID Classe Type de données associé


0x003B SystemComPlusPackage  
0x003C SystemNumaAvailableMemory  
0x003D SystemProcessorPowerInformation SYSTEM_PROCESSOR_POWER_-
INFORMATION
0x003E SystemEmulationBasicInformation SYSTEM_BASIC_INFORMATION
0x003F SystemEmulationProcessorInformation
SYSTEM_PROCESSOR_-
INFORMATION
0x0040 SystemExtendedHandleInformationSYSTEM_HANDLE_-
INFORMATION_EX
0x0041 SystemLostDelayedWriteInformation 
0x0042 SystemBigPoolInformation SYSTEM_BIGPOOL_-
INFORMATION
0x0043 SystemSessionPoolTagInformation SYSTEM_SESSION_PROCESS_-
INFORMATION
0x0044 SystemSessionMappedViewInformation
SYSTEM_SESSION_MAPPED_-
VIEW_INFORMATION
0x0045 SystemHotpatchInformation  
0x0046 SystemObjectSecurityMode  
0x0047 SystemWatchdogTimerHandler  
0x0048 SystemWatchdogTimerInformation  
0x0049 SystemLogicalProcessorInformation 
0x004A SystemWow64SharedInformationObsolete
 
0x004B SystemRegisterFirmwareTableInformationHandler
 
0x004C SystemFirmwareTableInformation  
0x004D SystemModuleInformationEx RTL_PROCESS_MODULES
0x004E SystemVerifierTriageInformation  
0x004F SystemSuperfetchInformation  
0x0050 SystemMemoryListInformation  
0x0051 SystemFileCacheInformationEx  
0x0052 SystemThreadPriorityClientIdInformation
 
0x0053 SystemProcessorIdleCycleTimeInformation
 
0x0054 SystemVerifierCancellationInformation
 
0x0055 SystemProcessorPowerInformationEx
SYSTEM_FILECACHE_-
INFORMATION
0x0056 SystemRefTraceInformation  
0x0057 SystemSpecialPoolInformation  
0x0058 SystemProcessIdInformation  
0x0059 SystemErrorPortInformation  
0x005A SystemBootEnvironmentInformationSYSTEM_BOOT_-
ENVIRONMENT_INFORMATION
0x005B SystemHypervisorInformation  

82
Architecture du système

ID Classe Type de données associé


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 SystemBasicPerformanceInformationSYSTEM_BASIC_-
PERFORMANCE_INFORMATION
0x007C SystemQueryPerformanceCounterInformation
 
0x007D SystemSessionBigPoolInformation  
0x007E SystemBootGraphicsInformation  
0x007F SystemScrubPhysicalMemoryInformation
 
0x0080 SystemBadPageInformation  

83
Architecture du système

ID Classe Type de données associé


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;

84
Architecture du système

Tableau 2.3. 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;

Tableau 2.4. 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;

Tableau 2.5. Valeurs initiales des champs de la structure SYSTEM_PROCESSOR_INFORMATION

Champ Valeur initiale


ProcessorArchitecture KeProcessorArchitecture
ProcessorLevel KeProcessorLevel
ProcessorRevision KeProcessorRevision;
ProcessorFeatureBits KeFeatureBits;

SYSTEM_PERFORMANCE_INFORMATION. 
typedef struct _SYSTEM_PERFORMANCE_INFORMATION {
LARGE_INTEGER IdleProcessTime;
LARGE_INTEGER IoReadTransferCount;
LARGE_INTEGER IoWriteTransferCount;
LARGE_INTEGER IoOtherTransferCount;
ULONG IoReadOperationCount;
ULONG IoWriteOperationCount;
ULONG IoOtherOperationCount;
ULONG AvailablePages;
ULONG CommittedPages;
ULONG CommitLimit;
ULONG PeakCommitment;
ULONG PageFaultCount;
ULONG CopyOnWriteCount;
ULONG TransitionCount;
ULONG CacheTransitionCount;
ULONG DemandZeroCount;
ULONG PageReadCount;

85
Architecture du système

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;

Tableau 2.6. 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

86
Architecture du système

Champ Valeur initiale


KPRCB MmDirtyPagesWriteCount DirtyWriteIoCount
KPRCB MmDirtyWriteIoCount MappedPagesWriteCount
KPRCB MmMappedPagesWriteCount MappedWriteIoCount
KPRCB MmMappedWriteIoCount PageFaultCount
KPRCB MmPageFaultCount PageReadCount
KPRCB MmPageReadCount PageReadIoCount
KPRCB MmPageReadIoCount PeakCommitment
MmPeakCommitment ResidentPagedPoolPage
MmPagedPoolPage ResidentSystemCodePage
MmSystemCodePage ResidentSystemCachePage
MmSystemCachePage ResidentSystemDriverPage
MmSystemDriverPage SystemCalls
KPRCB KeSystemCalls TransitionCount

SYSTEM_TIMEOFDAY_INFORMATION. 
typedef struct _SYSTEM_TIMEOFDAY_INFORMATION {
LARGE_INTEGER BootTime;
LARGE_INTEGER CurrentTime;
LARGE_INTEGER TimeZoneBias;
ULONG TimeZoneId;
ULONG Reserved;
ULONGLONG BootTimeBias;
ULONGLONG SleepTimeBias;
} SYSTEM_TIMEOFDAY_INFORMATION, *PSYSTEM_TIMEOFDAY_INFORMATION;

Tableau 2.7. Valeurs initiales des champs de la structure SYSTEM_TIMEOFDAY_INFORMATION

Champ Valeur initiale


CurrentTime KeQuerySystemTime
BootTime KeBootTime
TimeZoneBias ExpTimeZoneBias
TimeZoneId ExpCurrentTimeZoneId
BootTimeBias KeBootTimeBias

SYSTEM_PROCESSOR_IDLE_INFORMATION. 
typedef struct _SYSTEM_PROCESSOR_IDLE_INFORMATION {
ULONGLONG IdleTime;
ULONGLONG C1Time;
ULONGLONG C2Time;
ULONGLONG C3Time;
ULONG C1Transitions;
ULONG C2Transitions;
ULONG C3Transitions;
ULONG Padding;
} SYSTEM_PROCESSOR_IDLE_INFORMATION, *PSYSTEM_PROCESSOR_IDLE_INFORMATION;

Tableau 2.8. 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]

87
Architecture du système

Champ Valeur initiale


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;

Tableau 2.9. 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;

88
Architecture du système

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;

89
Architecture du système

SIZE_T CurrentSizeIncludingTransitionInPages;
SIZE_T PeakSizeIncludingTransitionInPages;
ULONG TransitionRePurposeCount;
ULONG Flags;
} SYSTEM_FILECACHE_INFORMATION, *PSYSTEM_FILECACHE_INFORMATION;

SYSTEM_DPC_BEHAVIOR_INFORMATION. 
typedef struct _SYSTEM_DPC_BEHAVIOR_INFORMATION
{
ULONG Reserved;
ULONG DpcQueueDepth;
ULONG MinimumDpcRate;
ULONG AdjustDpcThreshold;
ULONG IdealDpcRate;
} SYSTEM_DPC_BEHAVIOR_INFORMATION, *PSYSTEM_DPC_BEHAVIOR_INFORMATION;

SYSTEM_INTERRUPT_INFORMATION. 
typedef struct _SYSTEM_INTERRUPT_INFORMATION {
ULONG ContextSwitches;
ULONG DpcCount;
ULONG DpcRate;
ULONG TimeIncrement;
ULONG DpcBypassCount;
ULONG ApcBypassCount;
} SYSTEM_INTERRUPT_INFORMATION, *PSYSTEM_INTERRUPT_INFORMATION;

RTL_PROCESS_MODULES. 
typedef struct _RTL_PROCESS_MODULES {
ULONG NumberOfModules;
RTL_PROCESS_MODULE_INFORMATION Modules[1];
} RTL_PROCESS_MODULES, *PRTL_PROCESS_MODULES;

RTL_PROCESS_MODULE_INFORMATION. 
typedef struct _RTL_PROCESS_MODULE_INFORMATION {
HANDLE Section;
PVOID MappedBase;
PVOID ImageBase;
ULONG ImageSize;
ULONG Flags;
USHORT LoadOrderIndex;
USHORT InitOrderIndex;
USHORT LoadCount;
USHORT OffsetToFileName;
UCHAR FullPathName[256];
} RTL_PROCESS_MODULE_INFORMATION, *PRTL_PROCESS_MODULE_INFORMATION;

SYSTEM_HANDLE_INFORMATION. 
typedef struct _SYSTEM_HANDLE_INFORMATION {
ULONG NumberOfHandles;
SYSTEM_HANDLE_TABLE_ENTRY_INFO Handles[1];
} SYSTEM_HANDLE_INFORMATION, *PSYSTEM_HANDLE_INFORMATION;

SYSTEM_HANDLE_TABLE_ENTRY_INFO. 
typedef struct _SYSTEM_HANDLE_TABLE_ENTRY_INFO {
USHORT UniqueProcessId;
USHORT CreatorBackTraceIndex;
UCHAR ObjectTypeIndex;
UCHAR HandleAttributes;
USHORT HandleValue;
PVOID Object;
ULONG GrantedAccess;
} SYSTEM_HANDLE_TABLE_ENTRY_INFO, *PSYSTEM_HANDLE_TABLE_ENTRY_INFO;

NUMA
Autre type de systèmes multi processeur reconnue par Windows : NUMA (Non Uniform Memory Access),
laquelle topologie permet de regrouper les processeurs en unités de plus large échelle appelées noeuds.

90
Architecture du système

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.
Tableau 2.10. Opérations concernant NUMA

Opération Fonction Service Routine


Récupérer le noeud qui a GetNumaHighestNodeNumber
NtQuerySystemInformationKeQueryHighestNodeNumber
le numéro le plus élevé (SystemNumaProcessorMap)
Récupérer le masque GetNumaNodeProcessorMask
NtQuerySystemInformation 
processeur d’un noeud (SystemNumaProcessorMap)
Récupérer le numéro de GetNumaProcessorNode NtQuerySystemInformation 
noeud d’un processeur (SystemNumaProcessorMap)
Obtenir la quantité de GetNumaAvailableMemoryNode
NtQuerySystemInformationExpQueryNumaAvailableMemory
mémoire disponible dans (SystemNumaAvailableMemory)
un noeud
Obtenir le numéro     KeGetCurrentNodeNumber
de noeud sur lequel
s’exécute l’appelant
Initialiser les structures s/o s/o KeNumaInitialize
noyau requises pour le
support des systèmes
NUMA.
Obtenir le masque     KeQueryNodeActiveAffinity
d’affinité d’un noeud
Tableau 2.11. 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.

91
Architecture du système

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.

92
Architecture du système

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

93
Chapitre 3. Mécanismes système
Particulièrement riche sur le plan des technologies et des services rendus afférant, Windows offre à cet égard
kyrielle de dispositifs globaux sur lesquels s’appuient les composants mode noyau, tels que l’exécutif et les
pilotes de périphérique, ainsi que ceux exécutés en mode utilisateur, y compris applications et processus de
support. Dans ce chapitre, nous allons passer à la loupe les mécanismes système que voici :

■ Flags Windows globaux

■ Options d’exécution d’image

■ Windows on Windows, incluant Wow32 et Wow64

■ Windows Resource Protection

Windows on Windows
Windows on Windows, ou plus simplement Wow, désigne une infrastructure par laquelle le système
d’exploitation présente ses services de manière analogue aux versions de Windows conçues par le passé,
dont l’information élémentaire était traité sous forme de donnes 16, puis 32 bits - cela conditionnant bon
nombre de comportements internes et de surfaces logicielles exposées. C’est via l’approche Wow (et avec
elle, ainsi que nous allons les voir dans cette section, diverses techniques) que Windows 32 bits est capable
de reproduire les conditions attendues par des programmes écrits pour Windows 95 et Windows 98, voire
Windows 3.1 (lui-même reposant sur MS-DOS), et, dans la même veine, que Windows 64 bits permet
l’exécution d’applications x86 32 bits.

Historique de Windows on Windows

Windows évoluant au rythme des avancées technologiques et en fonction de la largeur des registres
internes du processeur pour la manipulation des données, Wow a d’abord commencé en tant
qu’appui aux programmes 16 bits exécutés dans Windows NT, premier système d’exploitation de
la gamme à être entièrement 32 bits. Par la suite, avec l’introduction des processeurs 64 bits et la
diminution subséquente de l’utilisation de l’informatique 32 bits (32 bits et 64 bits faisant ici référence
non seulement à la façon dont le processeur traite les informations, mais aussi comment système et
logiciels tirent profit de ces ressources), le terme Windows sur Windows a changé de connotation
et se réfère aujourd’hui à la capacité du système d’exploitation 64 bits à exécuter côte à côte des
processus Win32 et Win64. Notez, en ce qui concerne l’écosystème logiciel, que Wow vise moins à
conserver l’existant qu’à préparer l’avenir. Que ce soit pour les utilisateurs, les concepteurs de logiciel
ou les administrateurs système, il n’existe aucune raison de refuser les changements induits par le
passage au 64 bits.

Wow32
Imitation des conditions attendues par les programmes écrits pour Windows 3.1, dernière version 16 bits d’un
système d’exploitation Microsoft, et la dernière aussi à se reposer sur MS-DOS, l’environnement d’exécution
Windows 16 bits est supporté par le biais d’une couche intermédiaire, dévolue à la compatibilité, appelée
Windows sur Windows (WOW32, Windows on Windows 32-bits), laquelle intègre et étend les technologies
permettant d’exécuter des programmes MS-DOS (NTVDM).

L’environnement Windows 16 bits est disponible dans les diverses éditions 32 bits de Microsoft Windows,
dont Windows NT, 2000, XP, Serveur 2003, Vista, Serveur 2008, 7, 8 et 10. Les versions 64 bits de Windows,
en revanche, n’incluent pas de couche d’émulation pour le code 16 bits, et ne peuvent donc pas exécuter
des applications Win16.

94
Mécanismes système

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.

95
Mécanismes système

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 à

96
Mécanismes système

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

97
Mécanismes systè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).

98
Mécanismes système

■ 16 bits Les versions 64 bits de Windows, donc par association le sous-système Wow64, ne supportent
aucune application 16 bits. De ce fait, si vous possédez une application héritée 16 bits (ou une application
32 bits avec un programme d’installation 16 bits), vous devrez soit conserver l’infrastructure existante en
assumant la charge, soit vous tourner vers les diverses solutions de virtualisation présentes sur le marché.

■ Posix et OS/2 Wow64 n’intègre pas de support à destination des applications Posix ou OS/2, avec la
conséquence que ces programmes ne fonctionnent pas nativement sur les systèmes Microsoft 64 bits.
(Des alternatives sont néanmoins disponibles.)

■ 32 bits en Mode noyau Wow64 ne permet pas de charger des pilotes des périphériques mode noyau 32
bits. Cela a pour conséquence que les pilotes de niveau système doivent être compilés en mode 64 bits,
portées, voire repensées, afin de tirer le meilleur avantage du 64 bits natif.

■ Mixité entre programmes 32 et 64 bits Les processus Wow64 ne peuvent charger que des DLL 32 bits,
mais pas de DLL 64 bits natives. De même, les processus 64 bits natifs ne peuvent pas charger de DLL 32
bits. Divers cas particuliers illustrant cette limite sont, par exemple, Microsoft Internet Explorer ne pouvant
charger de contrôles ActiveX 32 bits, l’interpréteur de commandes standard ne pouvant interagir avec
les extensions d’environnement 32 bits, ou les programmes d’installation 32 bits ne pouvant enregistrer
des DLL en 64 bits.

Redirection du système de fichiers


Pour diverses raisons mal définies, un certain nombre de programmes 32 bits font référence aux répertoires
système non via la méthode appropriée, à laquelle correspond la fonction Windows GetSystemDirectory,
mais sur l’assertion que le chemin d’accès \Windows\System32 fasse référence inconditionnellement au
dossier racine du système d’exploitation. Autrement dit, même une fois exécuté dans un contexte 64 bits,
ces programmes essaieront toujours d’accéder au répertoire \Windows\System32. Pour donner une solution
efficace à cette problématique, les noms des répertoires système communs entre Win32 et Windows 64
bits ont été conservés, et un mécanisme de redirection intégré pour assurer le bon fonctionnement de
l’ensemble.

Remarque A l’époque de Windows 16 bits, le répertoire hôte de la plupart des fichiers nécessaires au
système était \Windows\System. Avec l’introduction de Win32, un autre répertoire fut ajouté, soit \Windows
\System32, contenant les fichiers et modules natifs 32 bits. Windows 95 jeta le trouble et commença à semer
la confusion en faisant cohabiter dans System32 les deux types de fichiers système, 16 bits et 32 bits.

Dans les systèmes Windows 64 bits, le répertoire \Windows\System32 contient les images 64 bits natives,
réservées aux applications 64 bits.(Notez que le nombre 32, partie du nom, perd pour l’occasion toute
signification particulière.) Wow64, quand il intercepte les appels système, traduit les API liées aux chemins,
de sorte que lorsqu’un processus 32 bits accède au répertoire \Windows\System32, ses opérations sont
redirigées vers le répertoire \Windows\SysWOW64, lequel héberge les versions 32 bits des modules
habituels. De plus, la plupart des programmes 32 bits sont détectés a l’installation et enregistrées dans le
\Program Files (x86), alors que les programmes 64 bits vont dans le dossier \Program Files.

Les modalités dont s’effectuent l’accès à quelques sous-répertoires de \Windows\System32 sont, pour des
raisons de compatibilité, exemptées de la redirection du système de fichiers, les opérations des applications
32 bits qui y accèdent ciblant du coup de vrais répertoires. Ceux-ci incluent :

■ %windir%\system32\drivers\etc

■ %windir%\system32\spool

■ %windir%\system32\catroot et %windir%\system32\catroot2

■ %windir%\system32\logfiles
Par défaut, la redirection de système de fichiers intégrée à Wow64 est active pour tout processus
exécutée conjointement à ce sous-système. Les processus peuvent pour interagir avec le mécanisme

99
Mécanismes système

avoir recours aux API Wow64DisableWow64FsRedirection, Wow64EnableWow64FsRedirection et


Wow64RevertWow64FsRedirection.

Les diverses fonctions Windows apparentées à la redirection de système de fichiers affectent toutes les E/
S orientées fichier émises par le thread appelant. Il en résulte quelques situations conflictuelles du moment
où la redirection est désactivée. Les procédures de chargement de DLL, par exemple, émettent des E/
S dépendantes de chemins d’accès redirigées, et auront dans ce contexte des résultats inattendus. Ces
procédures ne répondent en outre pas toujours à un chemin d’exécution évident : une DLL peut avoir des
dépendances envers d’autres DLL, une application charger une DLL au nom d’une autre application, ou
encore Windows différer le chargement d’une DLL jusque-là survenue d’un événement. Dans n’importe
laquelle de ces situations, l’application pourrait dépendre d’un chemin d’accès habituellement redirigé par
Wow64, qui ne l’est pas quand le système concrétise les traitements nécessaires à la requête d’E/S. Pour
éviter ces problèmes, il est vivement conseillé de désactiver la redirection immédiatement avant une fonction
d’E/S, et de la réactiver immédiatement après.

Les opérations concernant la redirection de système de fichiers s’effectuent à l’échelle du thread. Certaines
fonctions, tel CreateProcessAsUser, qui exécutent diverses tâches pour le compte (et dans le contexte)
d’autres threads ne sont donc pas concernées par l’état de la redirection dans le thread appelant.

Variables d’environnement
Corollaire aux quelques divergences que le sous-système instaure en ce qui concerne le registre et des
parties du système de fichiers, WOW64 expose aux applications 32 bits des variables d’environnement
différentes de celles vues par les applications 64 bits. Les processus 32 bits voient par exemple la variable
d’environnement relative au chemin d’installation des programmes (%ProgramFiles%) en tant que \Program
Files (x86), cela en référence au répertoire des programmes x86 enregistrés dans Windows 64 bits, alors que
les programmes 64 bits voient la valeur \Program Files, soit le chemin normal des programmes installés.

Quand un processus 32 bits est créé par le système 64 bits natif, ou quand un processus 64 bits est créé
par un processus 32 bits, Wow64 participe à la condition (l’état) de quelques-unes des variables dynamiques
utilisées par ce processus. Le tableau montre ces variables, et présente les fluctuations se manifestant à ce
niveau entre processus 32 bits natifs, processus 32 bits sur plateforme matérielle 64 bits - emmenées par
Wow64 donc, et les processus 64 bits.
Tableau 3.1. Variables d’environnement pour processus 32 bits, processus 64 bits et processus Wow64

Variable 32 bits natif 64 bits natif Wow64


PROCESSOR_- x86 amd64 x86
ARCHITECTURE
PROCESSOR_- Non défini Non défini amd64
ARCHITEW6432
ProgramFiles \Program Files \Program Files \Program Files (x86)
ProgramW6432 - \Program Files \Program Files (x86)
CommonProgramFiles \Program Files\Common \Program Files\Common \Program Files\Common
Files Files 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

100
Mécanismes système

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_- 0x00000004 dic Debug initial command
COMMAND
FLG_STOP_ON_HUNG_GUI 0x00000008 shg Stop on hung GUI
FLG_HEAP_ENABLE_TAIL_- 0x00000010 htc Enable heap tail checking
CHECK
FLG_HEAP_ENABLE_FREE_- 0x00000020 hfs Enable heap free checking
CHECK
FLG_HEAP_VALIDATE_- 0x00000040 hpc Enable heap parameter
PARAMETERS checking
FLG_HEAP_VALIDATE_ALL 0x00000080 hvc Enable heap validation on call
FLG_APPLICATION_VERIFIER 0x00000100 vrf Enable application verifier
FLG_POOL_ENABLE_- 0x00000400 ptg Enable pool tagging
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_- 0x00002000 kst kernel mode stack trace
DB database
FLG_MAINTAIN_OBJECT_- 0x00004000 otl Maintain a list of objects for
TYPELIST each type
FLG_HEAP_ENABLE_TAG_BY_- 0x00008000 htd Enable heap tagging by DLL
DLL
FLG_DISABLE_STACK_- 0x00010000 dse Disable stack extension
EXTENSION
FLG_ENABLE_CSRDEBUG 0x00020000 d32 Enable debugging of Win32
subsystem
FLG_ENABLE_KDEBUG_- 0x00040000 ksl Enable loading of kernel
SYMBOL_LOAD debugger symbols
FLG_DISABLE_PAGE_- 0x00080000 dps Disable paging of kernel stacks
KERNEL_STACKS
FLG_ENABLE_CLOSE_- 0x00400000 ece Enable close exception
EXCEPTIONS
FLG_DEBUG_INITIAL_- 0x04000000 dwl Debug WinLogon
COMMAND_EX
FLG_DISABLE_PROTDLLS 0x80000000 dpd Disable protected DLL
verification

Les flags globaux du système sont stockés sous la forme d’un masque binaire dans une variable globale,
nommée NtGlobalFlag, initialisée lors de l’amorçage de Windows depuis la clé de registre HKLM\SYSTEM
\CurrentControlSet\Control\Session Manager dans la valeur GlobalFlag. Par défaut, cette valeur de registre
est 0x400, à quoi correspond en interne l’activation du balisage de pool.

101
Mécanismes système

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager
GlobalFlag REG_DWORD 0x400

La représentation binaire (et à l’échelle d’une seule clé de registre) étant quelquefois insuffisante pour
englober toutes les informations relatives à un statut, une condition ou à un chemin d’exécution alternatif,
certains composants de Windows ont en partie pour tâche de gérer des protocoles additionnels en vue de
leur propre configuration. C’est, par exemple, la situation du gestionnaire de tas qui, une fois ses options
activées par l’intermédiaire de flags globaux, emploie une valeur de registre spécifique (PageHeapFlags) de
sorte à pouvoir gérer ses fonctionnalités de façon plus granulaire.

Logiciel Global Flags


La manière dont sont stockés les flags Windows globaux (en l’occurrence un masque binaire) ne se prête
que très malaisément à une perception intuitive. Heureusement, Windows SDK et les outils de débogage
standard incluent un utilitaire graphique nommé Global Flags via lequel interagir sur ces aspects, et par
conséquent voir et modifier les flags globaux du système (soit dans le registre, soit dans le système en cours
d’exécution), ainsi que les flags globaux d’une image.

Le module exécutable sous-jacent à Global Flag, gflags.exe, peut être lancé à partir du chemin d’installation
par défaut ou depuis un des raccourcis créés par le programme d’installation. L’utilitaire demande
automatiquement l’élévation de ses privilèges au niveau administratif. Ainsi que vous pouvez le voir au niveau
de la figure Figure 3.1, l’interface principale de Global Flags est divisée en onglets regroupant plusieurs
options d’une même catégorie.

Figure 3.1. Boîte de dialogue Global Flags

Vous pouvez basculer entre paramètres du registre (en cliquant sur System Registry) et valeur courante de la
variable en mémoire système (en cliquant sur Kernel Flags). S’il est possible dans quelques cas de remanier
la disposition générale des flags d’un système en cours d’exécution, la plupart des scénarios exigent un
réamorçage système afin que les modifications prennent effet.

Les possibilités de configuration mises en avant dans l’onglet System Registry (le plus à gauche) s’appuient
sur l’existence de paramètres dans le registre Windows. Les modifications ainsi faites sont répercutées sous
la clé correspondante appartenant au gestionnaire de session, et alimentent la variable NtGlobalFlags lors
du prochain démarrage du système d’exploitation.

Les options rendues visibles depuis l’onglet Kernel Flags peuvent être utilisées pour ajuster en temps réel
la valeur courante de la variable globale système NtGlobalFlag. Tout changement apporté par ce biais est
effectif sans avoir besoin de redémarrer Windows, au détriment de sa survie entre deux amorçages du
système. Notez que quelques-uns des comportements appuyés par des flags globaux ne peuvent prendre
effet à la volée, dans la mesure où les paramètres associés sont lus uniquement durant le démarrage du
système d’exploitation - il n’existe pas de prise en compte dynamique de la conduite à tenir. Ceci est la
raison pour laquelle quelques options de la liste des paramètres du registre sont absentes de la gamme des
choix accessibles en ce qui concerne le noyau.

102
Mécanismes système

Les contrôles regroupés sous l’onglet Image File permettent de modifier les flags globaux relatifs à une
image exécutable, plutôt que ceux du système dans son ensemble.
Figure 3.2. Configuration des flags globaux d’image avec Gflags

Les informations dans le champ de saisie Image doivent faire référence à un nom de module, et non à
un emplacement du système de fichiers. Cela signifie qu’il vous suffit d’entrer dans cette zone de texte
le nom de fichier d’une image exécutable, par exemple notepad.exe. Remarquez que vous devez inclure
l’extension de fichier dans le nom du fichier. Les flags globaux d’une image se propageant au processus
associé seulement à l’occasion de sa mise en route, les modifications apportées à l’aide de l’outil Gflags
(ou même les changements effectués directement dans le Registre) s’appliquent uniquement aux instances
nouvellement créées.

Une fois que vous avez défini par l’intermédiaire de l’outil Gflags les flags globaux d’une image exécutable,
vous pouvez vérifier que le Registre comporte bel et bien une nouvelle entrée concernant le module dont
vous avez renseigné le nom dans la boite de dialogue Image (notepad.exe dans notre exemple). Pour ce
faire, à l’aide de n’importe quel outil d’édition du registre, portez votre attention sur les clés et valeurs
hébergées sous HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options.
Vous devriez voir quelque chose ressemblant à ce qui suit.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\notepad.exe
GlobalFlag REG_DWORD 0x2000000
PageHeapFlags REG_DWORD 0x3

Idéalement, vous ne devriez interférer sur le cours des évènements induit par les flags globaux de Windows
que par l’entremise d’outils tiers spécialisés à cette fin. Au cas où vous souhaiteriez passer outre cet
avertissement et procéder à des changements directs dans le registre, veillez à garder à l’esprit que dans les
versions 64 bits de Windows, programmes natifs et programmes 32 bits ne disposent pas de la même vue
de certaines parties du système d’exploitation. Cela signifie que si un module renvoie à du code x86 32 bits,
vous devrez mettre à jour la clé de registre située sous l’arborescence HKLM\SOFTWARE\Wow6432Node
\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\. L’utilitaire Gflags est en la situation
assez pratique pour modifier à la fois la vue native (portion 64 bits) et la vue Wow64 (portion 32 bits) du
Registre, de sorte que vous n’ayez pas à vous préoccuper de ces détails.

Flags globaux d’image


De façon similaire à comment le comportement du système peut être dirigé par l’intermédiaire de
modificateurs (flags), chaque image exécutable dispose également d’un ensemble de flags globaux chargés
d’activer du code interne de trace, de vérification et de recouvrement d’erreurs. Au contraire des flags
globaux du système, qui étendent leur portée sur tout l’environnement, les flans globaux relatifs à un fichier
image n’ont d’influence que sur les instances d’un processus.

La configuration d’ensemble des flags globaux d’image trouve un abri dans le Registre sous HKLM
\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\. Lors de la création de
processus, le système s’en remet à cet emplacement de sorte à voir s’il existe une sous-clé nommée à

103
Mécanismes système

partir du nom de fichier et de l’extension de l’image exécutable. Si tel est le cas, il recherche une valeur
nommée GlobalFlag pour cette clé. S’il y en a une, les données sont alors enregistrées en tant que flags
globaux du processus. Autrement, à savoir dans l’éventualité où la valeur GlobalFlag est absente ou qu’il
n’est nulle part fait mention de l’image sous Image File Execution Options (ce qui sur ce sujet revient au
même), les flags globaux du processus sont dérivés de la valeur de la variable en mémoire système nommée
NtGlobalFlag (bien que la disposition binaire de ces flags soit complètement différente de celles des flags
système globaux).

Une fois que les flags globaux d’une image ont été déterminés, le chargeur répercute ces informations
à l’attribut NtGlobalFlag du bloc PEB dans l’espace d’adressage mode utilisateur du processus exécutant
l’image.
0:000> dt ntdll!_PEB NtGlobalFlag @$Peb
+0x0bc NtGlobalFlag : 0x2000400

Lors de vos expérimentations sur les flags globaux d’une image, sachez que quelques-uns sont
automatiquement mis en oeuvre dès lors que le processus associé est démarré depuis un débogeur en mode
utilisateur. Quand une requête de création de processus survient, le code d’initialisation afférent dans le
module ntdll, par nature instruit des conditions dans lesquelles tout fichier image a été exécuté, observe
si ces dernières sont de nature à assurer le diagnostic des applications, et si elles le sont effectivement,
anime de façon silencieuse un petit nombre de modificateurs. Le cas concerne uniquement les modules pour
lesquelles aucun paramètre n’est explicitement défini à cet égard dans le Registre. A titre d’illustration, la
sortie suivante montre la valeur courante des flags globaux du processus calc.exe lorsque l’image concernée
n’a pas d’attributs déterminés en la matière.
0:000> !gflag
Current NtGlobalFlag contents: 0x00000070
htc - Enable heap tail checking
hfc - Enable heap free checking
hpc - Enable heap parameter checking

Ainsi que vous pouvez le voir, un petit nombre paramètres qui ont trait au suivi du tas sont au niveau de
l’image notepad.exe à l’état actif, sans par ailleurs que rien de concret nous ai préparé à cette situation.
Un fait intéressant à relever ici et qui découle directement de cette caractéristique est qu’une application
peut se comporter différemment selon son exécution au sein d’un environnement de débogage. Dans notre
exemple, ceci explique pourquoi un programme fautif vis-à-vis du tas en manifeste tous les signes quand il
est pris en charge par un débogueur, et jamais ou dans de rares occasions quand il ne l’est pas.

Vous pouvez si vous le souhaitez couper court à l’influence des procédés de diagnostic sur la gestion du tas, a
fortiori sur les flags globaux de niveau image, en définissant la variable d’environnement _NO_DEBUG_HEAP
avant de donner naissance à un processus, ou en indiquant l’option de ligne de commande dh lors du
démarrage de WinDbg. Ces deux opérations ont pour effet de demander de disposer du tas standard plutôt
que de celui axé sur le débogage. Une autre alternative consiste à attacher le débogueur à un processus
en cours d’exécution, dont les conditions initiales ne le préparaient par conséquent pas de façon spécifique
à l’analyse.

À titre informatif, notez que la manière dont influent les pratiques de débogage sur les flags globaux d’image
constitue un moyen parmi d’autres de détecter la présence d’environnement virtuel ou d’outils utilisés dans
le cadre de l’analyse dynamique. Une application qui souhaite freiner l’étude de son code exécutable ou de
certaines de ses informations peut par exemple observer le positionnement des flags globaux qui lui ont été
attribués, et adopter un comportement particulier en conséquence.

Commande d’extension !gflag


L’extension !gflag, accessible depuis les outils de débogage standard, permet d’interagir avec les flags
globaux de Windows. Sollicitée dans un contexte mode utilisateur, la commande permet de voir l’état de
la variable NtGlobalFlag conservée au niveau du bloc d’environnement du processus sous le contrôle du
débogueur.
0:001> !gflag

104
Mécanismes système

Current NtGlobalFlag contents: 0x00000002


sls - Show Loader Snaps

Vous pouvez si vous le souhaitez obtenir une assistance en ce qui concerne cette extension en spécifiant le
commutateur -?. L’aide textuelle qui apparait alors contient une liste détaillée d’abréviations dont l’emploi
ambitionne de simplifier la manipulation des flags globaux.
0:003> !gflag -?
usage: !gflag [-? | flags]
Flags may either be a single hex number that specifies all
32-bits of the GlobalFlags value, or it can be one or more
arguments, each beginning with a + or -, where the + means
to set the corresponding bit(s) in the GlobalFlags and a -
means to clear the corresponding bit(s). After the + or -
may be either a hex number or a three letter abbreviation
for a GlobalFlag. Valid abbreviations are:
soe - Stop On Exception
sls - Show Loader Snaps
htc - Enable heap tail checking
hfc - Enable heap free checking
hpc - Enable heap parameter checking
hvc - Enable heap validation on call
vrf - Enable application verifier
htg - Enable heap tagging
ust - Create user mode stack trace database
htd - Enable heap tagging by DLL
dse - Disable stack extensions
scb - Enable system critical breaks
dhc - Disable Heap Coalesce on Free
eel - Enable exception logging
hpa - Place heap allocations at ends of pages
cse - Early critical section event creation
sue - Stop on Unhandled Exception
dpd - Disable protected DLL verification

La commande !gflag du débogueur noyau permet de voir la valeur de la variable NtGlobalFlag en mémoire
système.
lkd> dd nt!NtGlobalFlag
fffff800`2f5661c0 00000400 00000000 00000000 00000000

lkd> !gflag
Current NtGlobalFlag contents: 0x00000400
ptg - Enable pool tagging

lkd> !gflag -?
soe - Stop On Exception
sls - Show Loader Snaps
dic - Debug Initial Command
shg - Stop on Hung GUI
htc - Enable heap tail checking
hfc - Enable heap free checking
hpc - Enable heap parameter checking
hvc - Enable heap validation on call
vrf - Enable application verifier
ptg - Enable pool tagging
htg - Enable heap tagging
ust - Create user mode stack trace database
kst - Create kernel mode stack trace database
otl - Maintain a list of objects for each type
htd - Enable heap tagging by DLL
dse - Disable stack extensions
d32 - Enable debugging of Win32 Subsystem
ksl - Enable loading of kernel debugger symbols
dps - Disable paging of kernel stacks
scb - Enable system critical breaks
dhc - Disable Heap Coalesce on Free
ece - Enable close exception
eel - Enable exception logging
eot - Enable object handle type tagging
hpa - Place heap allocations at ends of pages
dwl - Debug WINLOGON
ddp - Disable kernel mode DbgPrint output
cse - Early critical section event creation
sue - Stop on Unhandled Exception
bhd - Enable bad handles detection
dpd - Disable protected DLL verification

105
Mécanismes système

La commande !gflag peut également être utilisée afin de prendre la main sur l’état des flags globaux. Dans
la pratique, cela peut s’effectuer de façon naturelle, en indiquant en paramètre une nouvelle valeur de la
variable, soit sous la forme d’opérations basiques. Les signes plus (+) et moins (-) servent auquel cas à armer
et désarmer tel ou tel drapeau. En guise d’exemple, ce qui suit montre comment activer et désactiver les
informations de trace du chargeur d’image.
lkd> !gflag
Current NtGlobalFlag contents: 0x00000400
ptg - Enable pool tagging

lkd> !gflag +soe


New NtGlobalFlag contents: 0x00000401
soe - Stop On Exception
ptg - Enable pool tagging

lkd> !gflag -1
New NtGlobalFlag contents: 0x00000400
ptg - Enable pool tagging

Pour finir, notez que si l’extension !gflag permet une approche définitivement pratique des flags Windows
globaux, vous restez bien évidement libre de correspondre avec eux sans son intermédiaire, moyennant
un confort bien moindre. Utilisiez dans ce scénario les options classiques en matière d’interaction avec la
mémoire, comme nous le faisons (en partie) dans l’exemple qui suit.
lkd> ed nt!NtGlobalFlag 0x401

lkd> !gflag
Current NtGlobalFlag contents: 0x00000401
soe - Stop On Exception
ptg - Enable pool tagging

Options d’exécution d’image


Les options d’exécution de fichier image (IFEO, Image File Execution Options) sont une collection de
paramètres utilisés en amont de la création des processus de sorte à en assurer un contrôle spécifique.
Étroitement liées au mode opératoire et aux agissements du chargeur (loader), un composant qui est par
ailleurs doté lui-même de multiples ramifications dans de nombreux champs, ces données permettent de
s’introduire à plusieurs étapes de la naissance d’un processus, mais aussi et surtout à divers niveaux :
scénarios pour l’ouverture du fichier image à exécuter, niveaux d’analyse des fonctionnalités de débogage,
détails des informations de trace, et bien d’autres.

Le registre Windows offre un toit aux options d’exécution par le biais de HKLM\SOFTWARE\Microsoft
\Windows NT\CurrentVersion\Image File Execution Options, lequel contient pour chaque image exécutable
à prendre en compte dans un scénario particulier (toutes ne le sont pas) une sous-clé nommée depuis le
nom de fichier et l’extension de l’image (mais sans les données de répertoire et de chemin, par exemple
Image.exe). Les valeurs sous ces clés peuvent constituer un référentiel d’informations potentiellement vaste.
Pour voir quelles applications de votre système ont des options d’exécution, tournez-vous vers la clé Image
File Execution Options au moyen de n’importe quel outil permettant de le faire, Regedit ou autre.

Les options d’exécution permettent une interaction très poussée tant avec les processus qu’avec les
composants Windows chargés de les gérer. Elles sont de ce fait potentiellement impliquées dans un plus ou
moins grand nombre de cas de figure, avec plus ou moins de relations entre eux. La liste qui suit énumère
quelques-uns des leviers manœuvrés par des options d’exécution. (Pour des raisons de clarté, et afin de
vous donner dès ici les bonnes pistes à suivre dans le registre, nous signalons entre parenthèses les noms
des clés adéquates.)

■ Contrôle externe (Debugger) Permet à un processus de démarrer automatiquement sous la coupe d’un
autre logiciel, généralement un débogueur.

■ Gestion du tas (DisableHeapLookAside) Joue un rôle dans la décision de délaisser l’emploi de listes
look-acide parmi les mécanismes d’allocation du tas. Cela est notamment utile pour résoudre d’éventuels
problèmes de compatibilité.

106
Mécanismes système

■ Débogage de tas (PageHeapFlags) Indique sur le plan des fonctionnalités de débogage de tas lesquelles
lesquelles sont actives, et à quel degré.

■ Flags globaux (GlobalFlag) Anime un ensemble de techniques en association avec le diagnostic et le suivi,
y compris des données de trace et des fonctions de validation internes.

■ Informations de taille de pile (MinimumStackCommitInBytes) Apporte des garanties en ce qui concerne


le dimensionnement et l’accessibilité de l’espace de pile.

■ Application Verifier (VerifierFlags) Base de données des contrôles et des vérifications auxquels se livre le
logiciel Microsoft Application Verifier.

Il apparaît clairement à la teneur des mécanismes dans lesquels elles s’insèrent que les options d’exécution
d’image ont une dimension pour l’essentiel orientée sur le débogage, et dans une moindre mesure sur le
profilage, des applications. Elles mettent en l’occurrence aux mains des concepteurs de logiciels diverses
sources de données de trace, ainsi que les fonctions, les caractéristiques, voire les utilitaires, qui s’y réfèrent.

Performances
Compteurs de performance
Les compteurs de performance Windows permettent de mesurer l’évolution de certaines données de
performance liées à une machine (taux d’occupation du processeur, mémoire utilisée, E/S) ou à un ou
plusieurs processus (taille des piles, quantité de mémoire utilisée, etc). Windows offre nativement un large
éventail de compteurs de performance, qu’administrateurs et utilisateurs peuvent étoffer en définissant les
leurs propres.

Les compteurs de performance sont affichables sous forme graphique à l’aide de l’Analyseur de
performance, ou sous forme textuelle à l’aide de l’utilitaire Logman.

L’architecture sous-jacente aux compteurs de performance se présente dans les grandes lignes comme suit :

■ Objets Les objets de performance sont issues de la répartition logique des ressources système en plusieurs
catégories distinctes. Il existe par exemple un objet de performance pour le processeur, un autre pour la
mémoire, pour les services, et ainsi de suite.

■ Compteurs Les compteurs forment la base de l’observation de l’usage des ressources, et constituent ainsi
les paramètres réels mesurés.

■ Instances Les instances d’objets de performance sont des ensembles d’un même type d’objet. Par
extension, une instance identifie le paramètre de performance que le compteur mesure. Certains types
d’objets comportent plusieurs instances. Par exemple, sur un système multi processeur, le type d’objet
Processeur dispose de plusieurs instances. Si un système contient deux disques, le type d’objet Disque
physique possède deux instances. Certains objets, tels que ceux relatifs à la mémoire, ne disposent que
d’une seule instance.

Analyseur de performances (Perfmon)


Analyseur de performances permet de créer des ensembles interactifs de compteurs système ou des
ensembles de collecteurs de données. (Lesdits ensembles sont étudiés plus en détail dans la section
"Ensembles de collecteurs de données", plus loin dans ce chapitre.

Comme socle technique, l’utilitaire Performance s’appuie sur les fonctions de l’API Performance Data Helper
afin d’interagir avec les diverses sources de données de performances, dont les compteurs de performance
en temps réel ou les fichiers journaux spécifiques à cet égard.

107
Mécanismes système

L’Analyseur de performances se présente sous la forme d’un composant logiciel enfichable de la console
MMC, mis en oeuvre dans perfmon.msc.

Utilisez l’une ou l’autre des méthodes suivantes afin d’accéder à l’utilitaire Performances.

■ Ouvrez la console Gestion de l’ordinateur (compmgmt.msc), développez Outils système, puis cliquez sur
Performance.

■ Depuis Outils d’administration, sélectionnez le raccourci nommé Analyseur de performances.

■ Saisissez perfmon.msc ou perfmon.msc et appuyez sur Entrée dans le menu Démarrer, la boite de dialogue
Exécuter ou encore dans une fenêtre d’invite de commandes.

Ajouter des compteurs dans l’Analyseur de performances.  L’Analyseur de performances affiche


uniquement les informations relatives aux compteurs suivis. Plusieurs milliers de compteurs sont disponibles,
réparties en un petit nombre de catégories tels que Processus, Threads, Mémoire, Cache, et ainsi de suite.
Les compteurs les plus utiles en matière de suivi du système du système et de ses composants incluent ceux
que voici :

■ Processus Rend visible des compteurs de performance apparentés aux différentes applications en cours
d’exécution, par exemple l’activité CPU en mode utilisateur et noyau, le nombre de handles ouverts, etc.

■ Processeur Rend visible des compteurs de performance concernant l’activité du processeur, par exemple
le nombre d’interruptions par seconde, le nombre de DPC par seconde, etc.

■ Mémoire Rend visible des compteurs de performance au sujet de la consommation mémoire, par exemple
la quantité de mémoire disponible sur le moment, le nombre de pages et défauts de pages par seconde,
etc.

Lorsque l’Analyseur de performances surveille un objet particulier, il peut suivre toutes les instances de tous
les compteurs de cet objet. Les instances correspondent à toutes les instances d’un compteur particulier. Par
exemple, si vous vous êtes engagés sur la piste de compteurs concernant les processus, vous avez le choix
de suivre les instances de tous les processus ou celles de processus spécifiques.

Voici comment procéder en vue de sélectionner les compteurs à surveiller :

1. Démarrez l’Analyseur de performances (les méthodes pour ce faire ont été indiquées plus haut).

2. L’Analyseur de performances comporte plusieurs modes d’affichage. Assurez-vous d’afficher l’activité en


cours en cliquant sur le bouton Affiche l’activité actuelle ou en appuyant sur CTRL+T. Pour basculer entre
les types de vues (Ligne, Barre d’histogramme et Rapport), cliquez sur le bouton Modifier le type de
graphique ou cliquez sur CTRL+G.

3. Pour ajouter des compteurs, cliquez sur le bouton Ajouter de la barre d’outils, ou appuyez sur CTRL+I. La
boîte de dialogue Ajouter des compteurs apparait alors.

4. Dans le panneau Compteurs disponibles, les objets de performances sont classés par ordre alphabétique.
Cliquez sur un objet pour le sélectionner : tous les compteurs correspondants le sont aussi. Si vous
développez l’entrée d’un objet, vous affichez tous les compteurs associés et pouvez sélectionner des
compteurs individuels en cliquant dessus.

5. Quand vous sélectionnez un objet ou l’un de ses compteurs, les instances en cours s’affichent dans le
panneau Instances de l’objet sélectionné. Sélectionnez une instance particulière ou Toutes les instances.
Pour rechercher une instance particulière, entre quelques lettres dans le champ déroulant sous Instances
de l’objet sélectionné et cliquez sur Rechercher.

6. Lorsque vous avez sélectionné un objet ou un groupe de compteurs pour un objet, ainsi que les instances
de l’objet, cliquez sur Ajouter pour intégrer ces compteurs à la liste Compteurs ajoutés.

108
Mécanismes système

7. Lorsque vous avez terminé, cliquez sur OK.

La manière la plus simple, et le meilleur moyen, d’appréhender les compteurs véhiculées par l’Analyseur de
performance consiste à lire les explications disponibles dans la boîte de dialogue Ajouter des compteurs.
Accédez dans cette optique audit élément d’interface et cochez ensuite la case Afficher la description dans
l’angle inférieur gauche de la fenêtre.

Droits utilisateurs de l’analyseur de performances.  Les droits utilisateurs de l’analyseur de performances


sont spécifiés comme suit.

■ Administrateurs Contrôle total local et distant.

■ Utilisateurs des journaux de performances Peuvent accéder et mettre en journal des données de
compteur de performance localement et à distance (créer, manipuler et voir les journaux).

■ Utilisateurs de l’Analyseur de performances Peuvent accéder aux données de compteur de performance


localement et à distance (voir les journaux).

Ensembles de collecteurs de données


Les ensembles de collecteurs de données sont des objets de performance qui permettent de gérer
comme un tout plusieurs types de collecteurs de données : compteurs de performance, données de suivi
d’événements et informations de configuration système (comme les valeurs de certaines clés spécifiques
du Registre).

Introduits sous Windows Server 2008, les ensembles de collecteurs de données ressemblent dans une
certaine mesure aux journaux de performance employés dans les versions précédentes de Windows. Ils
sont cependant beaucoup plus élaborés, tant sur le plan de la réalisation que des schémas qu’ils rendent
possibles.

Windows offre la possibilité d’interagir avec des ensembles de collecteurs de données au travers notamment
de deux outils : Analyseur de performance et Logman.

Ensembles de collecteurs de données intégrés


Windows propose par l’intermédiaire de la console Performances plusieurs ensembles de collecteurs de
données intégrés situés dans Ensembles de collecteurs de données\Système.

■ Performances du système Regroupe un certain de compteurs de performance liés au disque, à la mémoire


et au réseau, ainsi que différentes informations de suivi concernant le noyau. Utilisez cet ensemble de
collecteurs pour auditer un ordinateur lent, et de la sorte diagnostiquer les facteurs qui diminuent ses
performances générales.

■ Diagnostics du système Enregistre toutes les informations comprises dans l’ensemble de collecteurs
de données Performances du système, plus des métriques système détaillées. Utilisez cet ensemble de
collecteur lorsque vous résolvez des problèmes de fiabilité, et faites par exemple face à du matériel
défaillant, des pilotes défectueux ou des effondrements inopinés du système.

Pour employer un ensemble de collecteurs de données, effectuez dessus un clic avec le bouton droit de la
souris, puis sélectionnez Démarrer. Dans la configuration par défaut, les ensembles Performances du système
et Diagnostics du système s’arrêtent automatiquement au bout d’une minute.

Création d’un ensemble de collecteurs de données


Procédez comme suit afin d’enregistrer des informations de performances par le biais d’un ensemble de
collecteurs de données.

109
Mécanismes système

1. Ouvrez Analyseur de performances.

2. Dans le volet gauche, effectuez un clic droit de la souris sur ensemble de collecteurs de données
\Personnalisés, sélectionnez Nouveau, puis Ensemble de collecteurs de données.

3. Dans l’assistant Créer un nouvel ensemble de collecteurs de données, spécifiez un nom pour l’ensemble,
idéalement qui reflète la nature des objets que vous voulez suivre, par exemple Performances du système
ou Moniteur de l’état du processeur.

4. Sélectionnez l’option Créer manuellement et cliquez sur Suivant.

5. Sur la page Quels type de données inclure, l’option Créer des journaux de données est sélectionnée par
défaut. Cochez la case Compteur de performance et cliquez sur Suivant.

6. Sur la page Quels compteurs de performance enregistrer dans un journal, cliquez sur Ajouter pour
provoquer l’apparition de la boite de dialogue Ajouter des compteurs. Une fois les compteurs de
performance selectionnés, cliquez sur le bouton Ok.

7. Toujours sur la page Quels compteurs de performance enregistrer dans un journal ?, personnalisez si
besoin l’intervalle d’échantillonnage et sélectionnez l’unité de temps en secondes, minutes, heures, jours
ou semaines. Cet intervalle spécifie quand collecter les nouvelles données. Cliquez sur Suivant pour
poursuivre.

8. Sur la page Où enregistrer les données, spécifiez l’emplacement d’enregistrement des journaux
(%systemdrive%\PerfLogs\Admin par défaut). Comme alternative, cliquez sur Parcourir et servez-vous de
la boite de dialogue Rechercher un dossier afin de sélectionner un autre répertoire. (Voir note plus loin
en ce qui concerne les proportions que peuvent atteindre les fichiers journaux.) Cliquez sur Suivant pour
continuer.

9. Sur la page Créer l’ensemble de collecteurs de données, la zone Exécuter en tant que contient <Par
défaut> de sorte à indiquer que le collecteur de données s’exécutera avec les privileges et les autorisations
de l’utilisateur actuel. Cliquez éventuellement sur le bouton Modifier pour indiquer d’autres informations
d’identification. Sélectionnez une des trois options avant de cliquer sur le bouton Terminer :

a. Ouvrir des propriétés pour cet ensemble de collecteurs de données Personnalise immédiatement
l’ensemble de collecteurs de données.

b. Démarrer maintenant cet ensemble de collecteurs de données Commence sur-le-champ à


enregistrer des données sans passer par la personnalisation de l’ensemble de collecteurs de données.

c. Enregistrer et fermer Ferme l’ensemble de collecteur de données sans le démarrer. Vous pouvez
modifier les propriétés et le démarrer à tout moment après l’avoir enregistré.

Notez que les paramètres que vous aurez choisis au niveau de l’intervalle d’échantillonnage ont un impact
direct plus ou moins significatif sur la charge de travail demandée à l’ordinateur d’une part, et le volume
des données résultant d’autre part (autrement dit la taille du fichier journal). C’est précisément la raison pour
laquelle, au titre de ce second point, il est généralement conseillé d’utiliser comme lieu de stockage des
journaux une partition différente de celle où le système est installée.

Création de collecteurs depuis l’invite de commandes


Vous pouvez créer des collecteurs de données depuis une invite de commandes à l’aide de l’utilitaire logman.
Les commandes admissibles en la circonstance comptent entre autres celles voici.

■ Logman create counter Cette commande crée un collecteur de données de compteur de performance. Par
exemple, la commande logman create counter perf_log -c "\Processor{_ Total/)\% Processor Time" crée

110
Mécanismes système

un compteur nommé perf_log qui enregistre les valeurs du compteur Pourcentage de temps processeur
de l’instance de compteur Processeur(_Total).

■ Logman create trace Cette commande crée un collecteur de données de suivi d’événement. Par exemple,
la commande logman create trace trace_log -o c:\ trace_log_file crée un collecteur de données de suivi
d’événement nommé trace_log et enregistre les résultats dans le fichier trace_log_file à la racine du disque.

■ Logman create alert Cette commande crée une alerte de compteur de performances. Par exemple,
la commande logman create alert alert -th "\ Processor(_Total)\% Processor Time>90" crée une alerte
nommée alert qui se déclenche lorsque le compteur de performances Pourcentage temps processeur de
l’instance de compteur Processeur(_Total) excède 90.

Moniteur de fiabilité
Moniteur de fiabilité procure des informations en lesquelles jouxtent les aspects robustesse et stabilité de
la station de travail. Les ordinateurs les moins frappés par des événements causés par des défaillances sont
considérés comme stables et peuvent éventuellement obtenir l’index de stabilité maximum (10). Plus le
système enregistre des dysfonctionnements de toute nature, plus la stabilité du système décroit. La valeur
minimale de l’index est zéro.

Les événements de fiabilité suivants peuvent être enregistrées dans le rapport de stabilité du système.

■ Modification de l’horloge système

■ Installations et désinstallations de logiciels

■ Défaillances d’applications

■ Défaillances matérielles

■ Echec Windows

■ Echecs divers

Moniteur de fiabilité conserve un historique d’un an des événements de stabilité système et de fiabilité.

Pour prendre les bonnes décisions, le moniteur de fiabilité produit des rapports détaillés permettant une
juste compréhension des évènements qui ont contribué à abaisser l’index de stabilité système. Vous pouvez
cliquer sur Afficher tous les rapports de problèmes pour afficher l’intégralité des problèmes rencontrés triés
par logiciels.

Accéder au moniteur de fiabilité


Pour accéder au moniteur de fiabilité de Windows, rendez-vous dans le Panneau de configuration puis cliquez
ensuite sur Sécurité et maintenance. Déroulez le panneau Maintenance puis cliquez sur Afficher l’historique
de fiabilité. Plus simplement, saisissez perfmon /rel à l’intérieur d’une fenêtre d’invite de commandes. Une
fenêtre semblable à la figure suivante s’affiche.

Pour obtenir des informations détaillés sur les problèmes rencontrés un certain jour ou une certaine semaine,
il suffit de cliquer sur la bande temporelle correspondante et de lire les données affichées dans la partie
inférieure de la fenêtre.

En bas de la fenêtre de Moniteur de fiabilité figurent plusieurs options :

■ Enregistrer l’historique de fiabilité Permet d’enregistrer des détails complets sur l’ordinateur pour
référence ultérieure. L’information est enregistrée comme rapport Moniteur de fiabilité au format XML.

111
Mécanismes système

■ Afficher tous les rapports de problèmes Ouvre la fenêtre d’historique des problèmes, qui affiche
l’historique de tous les problèmes rencontrés et leur statut.

■ Rechercher des solutions à tous les problèmes Lance le processus d’examen automatique des
problèmes. Une fois celui-ci achevé, Centre de maintenance est actualisé de sorte à montrer les solutions
à tous les problèmes nouvellement découverts.

Index de stabilité système


Dans la perspective Windows, la stabilité d’un ordinateur est exprimée par un indice variant entre 1 (stabilité
déplorable) et 10 (stabilité parfaite), qui est une mesure pondérée dérivant du nombre de problèmes
matériels et logiciels observées pendant une durée historique continue (période roulante). Dès qu’un
événement a une influence sur la stabilité globale de l’ordinateur, Windows procède à une réévaluation
de ladite valeur. Au premier lieu, cet effet de rééquilibrage permet de refléter au plus près l’amélioration
ou la dégradation qui s’est produite au fil du temps dans un index de stabilité du système ascendant ou
descendant lorsqu’un problème de fiabilité a été rencontré, ou au contraire résolu.

Fondée sur des données collectés au cours de la durée de vie d’un système, la valeur d’index est calculée
sur les 28 jours précédents. Les jours où le système est éteint, en état de veille ou d’hibernation ne sont pas
pris en compte. S’il n’y a pas assez de données pour établir un index de stabilité système fiable et sérieux,
Moniteur de fiabilité affiche une ligne pointillée (continue autrement).

A titre informatif, notez pour finir que l’index de stabilité ne constitue pas une mesure exacte de fiabilité.
Il existe à cet égard un petit nombre de situations spéciales qui tendent à diminuer la valeur d’index mais
rendent finalement le système plus fiable qu’il ne l’était par le passé. Entre dans cette catégorie notamment
toute forme de mise à jour nécessitant à terme un redémarrage de l’ordinateur, y compris service packs et
mises à niveau d’édition.

Windows System Assessment Tool (WinSAT)


L’outil d’évaluation système Windows (WinSAT, Windows System Assessment Tool) mesure les performances
de divers équipements intégrés à la station de travail, et donne ce faisant un pressenti de l’utilisation du
système d’exploitation s’exécutant dessus.

Les résultats des mesures effectués par WinSAT sont présentés sous la forme d’un indice de performance,
sujet qui sera approfondi plus loin.

Emplacements du registre
WinSAT enregistre les résultats d’évaluation sous la clé HKEY_LOCAL_MACHINE\Software\Microsoft
\Windows NT\CurrentVersion\WinSAT.
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\WinSAT
LastExitCode REG_DWORD 0x0
LastExitCodeCantMsg REG_SZ Évaluation terminée.
LastExitCodeWhyMsg REG_SZ Les évaluations ou les autres opérations se sont terminées avec succès.
CKCLStart REG_QWORD 0x0
PrimaryAdapterString REG_SZ NVIDIA GeForce GTX 770
VideoMemoryBandwidth REG_DWORD 0x2fe741c
VideoMemorySize REG_DWORD 0x7ae61000
DedicatedVideoMemory REG_DWORD 0x7c5d0000
SharedVideoMemory REG_DWORD 0xfe891000
NumMonitors REG_DWORD 0x1
TotalMonitorPixels REG_DWORD 0xe1000
DedicatedSystemMemory REG_DWORD 0x0
MOOBE REG_DWORD 0x2
WindeployTimeDate REG_QWORD 0x5446fa42
GraphicsFPS REG_DWORD 0x2d2404
WsSwapResult REG_DWORD 0x74c00
WsSwapInterference REG_DWORD 0xd0004
WsSwapThroughput REG_DWORD 0x74c00

112
Mécanismes système

MFMediaMaxRunTime REG_DWORD 0x1d4c0


MediaMaxRunTime REG_DWORD 0x1d4c0
Disk0RandomReadThroughput REG_DWORD 0x6588f
Disk1RandomReadThroughput REG_DWORD 0x5e1
CpuUPExpressCompressThroughput REG_DWORD 0x164
MemoryThroughputMBS REG_DWORD 0x4a9d
RandomReadDiskScore REG_DWORD 0x6588f
SequentialReadDiskScore REG_DWORD 0x79e43
WinCRSScore REG_DWORD 0x51
MemoryScore REG_DWORD 0x54
CPUScore REG_DWORD 0x54
DWMScore REG_DWORD 0x55
D3DScore REG_DWORD 0x63
DiskScore REG_DWORD 0x51
HistoryVersionRead REG_DWORD 0x0
TimeLastFormalAssessment REG_QWORD 0x1d1d7908df3b8e5

WEI (Windows Experience Index)


1. Ouvrez une fenêtre d’invite de commandes et tapez la commandes winsat formal. Votre ordinateur devrait
alors travailler pendant quelques temps.

2. Depuis Explorateur de fichiers, rendez-vous sur C:\Windows\Performance\WinSAT\DataStore. En toute


logique, ce dossier devrait héberger deux sous-ensembles de fichiers, l’un concernant les fichiers générés
par le programme d’installation de Windows, l’autre les fichiers générés à l’instant.

3. Ouvrez le fichier Format.Assessment, par exemple en utilisant Internet Explorer, Edge ou tout autre outil
via lequel visualiser facilement du contenu XML, et intéressez-vous plus particulièrement à la section
nommée WinSPR (pour Windows System Performance Rating). Le résultat devrait ressembler à quelque
chose comme ce qui suit.
<WinSPR>
<SystemScore>8.15</SystemScore>
<MemoryScore>8.4</MemoryScore>
<CpuScore>8.4</CpuScore>
<CPUSubAggScore>8.3</CPUSubAggScore>
<VideoEncodeScore>8.4</VideoEncodeScore>
<GraphicsScore>8.5</GraphicsScore>
<Dx9SubScore>9.9</Dx9SubScore>
<Dx10SubScore>9.9</Dx10SubScore>
<GamingScore>9.9</GamingScore>
.
.
.
</WinSPR>

Emplacements de registre pour WinSAT


WinSAT enregistre les résultats des évaluations auxquelles il procède par l’intermédiaire des diverses clés et
valeurs situés sous HKLM\Software\Microsoft\Windows NT\CurrentVersion\WinSAT.
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\WinSat
LastExitCode REG_DWORD 0x0
LastExitCodeCantMsg REG_SZ ...valuation terminÈe.
LastExitCodeWhyMsg REG_SZ Les Èvaluations ou les autres opÈrations se sont terminÈes avec succËs.
CKCLStart REG_QWORD 0x0
PrimaryAdapterString REG_SZ NVIDIA GeForce GTX 770
VideoMemoryBandwidth REG_DWORD 0x2fe741c
VideoMemorySize REG_DWORD 0x7ae61000
DedicatedVideoMemory REG_DWORD 0x7c5d0000
SharedVideoMemory REG_DWORD 0xfe891000
NumMonitors REG_DWORD 0x1
TotalMonitorPixels REG_DWORD 0xe1000
DedicatedSystemMemory REG_DWORD 0x0
MOOBE REG_DWORD 0x2
WindeployTimeDate REG_QWORD 0x5446fa42
GraphicsFPS REG_DWORD 0x2d2404
WsSwapResult REG_DWORD 0x65000
WsSwapInterference REG_DWORD 0xa0001
WsSwapThroughput REG_DWORD 0x65000
MFMediaMaxRunTime REG_DWORD 0x1d4c0

113
Mécanismes système

MediaMaxRunTime REG_DWORD 0x1d4c0


Disk0RandomReadThroughput REG_DWORD 0x6588f
Disk1RandomReadThroughput REG_DWORD 0x5e1
CpuUPExpressCompressThroughput REG_DWORD 0x164
MemoryThroughputMBS REG_DWORD 0x4a9d
RandomReadDiskScore REG_DWORD 0x6588f
SequentialReadDiskScore REG_DWORD 0x79e43
WinCRSScore REG_DWORD 0x51
MemoryScore REG_DWORD 0x54
CPUScore REG_DWORD 0x54
DWMScore REG_DWORD 0x55
D3DScore REG_DWORD 0x63
DiskScore REG_DWORD 0x51
HistoryVersionRead REG_DWORD 0x0
TimeLastFormalAssessment REG_QWORD 0x1d1d7908df3b8e5

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\WinSat\MediaEx
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\WinSat\WindowsExperienceIndexOemInfo

Composants de l’architecture Performances


La liste qui suit décrit quelques-uns des composants binaires spécifiques à l’architecture Performances.

■ pdh.dll Sert à interagir avec les différences sources de compteurs de performance. Pour plus
d’informations, consultez la section PDH (Performance Data Helper).

■ pdhui.dll Procure les boîtes de dialogue réutilisables qui sont communes à toutes les applications liés aux
performances.

■ pla.dll DLL sous-jacente au service Journaux et alertes de performance (PLA, Performance Logs and Alerts).

■ perftrack.dll Suivi des performances.

■ perfdisk.dll Recueille des données liées à la performance des disques physiques et logiques.

■ relmon.dll Moniteur de fiabilité.

PLA (Performance Logs and Alerts)


L’outil Journaux et alertes de performance prend en charge la définition d’objets de performance, de
compteurs de performance et d’instances d’objets de performance. Il permet également de définir des
intervalles d’échantillonnage pour l’analyse de données relatives aux ressources matérielles et aux services
système.

Le service PLA intervient à la demande et démarre lorsqu’il est nécessaire de mettre en journal des
données de performance. Il s’exécute dans un processus hôte partagé (svchost) avec comme nom abrégé
PLA. Les informations de configuration du service PLA sont dans la clé nommé pla sous HKLM\System
\CurrentcontrolSet\Services.

Paramètres de registre pour la configuration PLA. 


HKEY_LOCAL_MACHINE\System\CurrentcontrolSet\Services\pla
DisplayName REG_SZ @%systemroot%\system32\pla.dll,-500
ErrorControl REG_DWORD 0x1
ImagePath REG_EXPAND_SZ %SystemRoot%\System32\svchost.exe -k LocalServiceNoNetwork
Start REG_DWORD 0x3
Type REG_DWORD 0x20
Description REG_SZ @%systemroot%\system32\pla.dll,-501
DependOnService REG_MULTI_SZ RPCSS
ObjectName REG_SZ NT AUTHORITY\LocalService
ServiceSidType REG_DWORD 0x3
RequiredPrivileges REG_MULTI_SZ SeImpersonatePrivilege
FailureActions REG_BINARY
840300000000000000000000030000001400000001000000C0D4010001000000E09304000000000000000000

HKEY_LOCAL_MACHINE\System\CurrentcontrolSet\Services\pla\Configuration

114
Mécanismes système

HKEY_LOCAL_MACHINE\System\CurrentcontrolSet\Services\pla\Parameters
HKEY_LOCAL_MACHINE\System\CurrentcontrolSet\Services\pla\Security

PDH (Performance Data Helper)


L’API Performance Data Helper (Pdh.dll) offre des moyens d’accès structurés aux informations de
performance et de diagnostic issues des différentes sources établies en la matière, y compris les compteurs
de performance en temps réel, les fichiers binaires stockés et d’autres plus anciens formats de journaux de
compteurs.

Les interfaces PDH présentent un niveau d’abstraction plus fort et une meilleure flexibilité que les fonctions
du registre Windows. Les concepteurs de logiciels peuvent, entre autres, employer les interfaces PDH pour
lire les valeurs des compteurs de performances, configurer, analyser et agréger des journaux de compteurs,
et accéder à bien d’autres fonctionnalités indisponibles autrement.

Fonctions PHD
■ PdhOpenQuery Crée une nouvelle requête utilisable pour gérer la collecte des données de performance.

Codes d’erreur
La liste qui suit énumère les codes d’erreur spécifiques à PDH. Ces valeurs sont définies dans le fichier
d’entête pdhmsg.h.

■ 0x00000000 - PDH_CSTATUS_VALID_DATA

■ 0x00000001 - PDH_CSTATUS_NEW_DATA

■ 0x800007D0 - PDH_CSTATUS_NO_MACHINE

■ 0x800007D1 - PDH_CSTATUS_NO_INSTANCE

■ 0x800007D2 - PDH_MORE_DATA

■ 0x800007D3 - PDH_CSTATUS_ITEM_NOT_VALIDATED

■ 0x800007D4 - PDH_RETRY

■ 0x800007D5 - PDH_NO_DATA

■ 0x800007D6 - PDH_CALC_NEGATIVE_DENOMINATOR

■ 0x800007D7 - PDH_CALC_NEGATIVE_TIMEBASE

■ 0x800007D8 - PDH_CALC_NEGATIVE_VALUE

■ 0x800007D9 - PDH_DIALOG_CANCELLED

■ 0x800007DA - PDH_END_OF_LOG_FILE

■ 0x800007DB - PDH_ASYNC_QUERY_TIMEOUT

■ 0x800007DC - PDH_CANNOT_SET_DEFAULT_REALTIME_DATASOURCE

■ 0xC0000BB8 - PDH_CSTATUS_NO_OBJECT

■ 0xC0000BB9 - PDH_CSTATUS_NO_COUNTER

115
Mécanismes système

■ 0xC0000BBA - PDH_CSTATUS_INVALID_DATA

■ 0xC0000BBB - PDH_MEMORY_ALLOCATION_FAILURE

■ 0xC0000BBC - PDH_INVALID_HANDLE

■ 0xC0000BBD - PDH_INVALID_ARGUMENT

■ 0xC0000BBE - PDH_FUNCTION_NOT_FOUND

■ 0xC0000BBF - PDH_CSTATUS_NO_COUNTERNAME

■ 0xC0000BC0 - PDH_CSTATUS_BAD_COUNTERNAME

■ 0xC0000BC1 - PDH_INVALID_BUFFER

■ 0xC0000BC2 - PDH_INSUFFICIENT_BUFFER

■ 0xC0000BC3 - PDH_CANNOT_CONNECT_MACHINE

■ 0xC0000BC4 - PDH_INVALID_PATH

■ 0xC0000BC5 - PDH_INVALID_INSTANCE

■ 0xC0000BC6 - PDH_INVALID_DATA

■ 0xC0000BC7 - PDH_NO_DIALOG_DATA

■ 0xC0000BC8 - PDH_CANNOT_READ_NAME_STRINGS

■ 0xC0000BC9 - PDH_LOG_FILE_CREATE_ERROR

■ 0xC0000BCA - PDH_LOG_FILE_OPEN_ERROR

■ 0xC0000BCB - PDH_LOG_TYPE_NOT_FOUND

■ 0xC0000BCC - PDH_NO_MORE_DATA

■ 0xC0000BCD - PDH_ENTRY_NOT_IN_LOG_FILE

■ 0xC0000BCE - PDH_DATA_SOURCE_IS_LOG_FILE

■ 0xC0000BCF - PDH_DATA_SOURCE_IS_REAL_TIME

■ 0xC0000BD0 - PDH_UNABLE_READ_LOG_HEADER

■ 0xC0000BD1 - PDH_FILE_NOT_FOUND

■ 0xC0000BD2 - PDH_FILE_ALREADY_EXISTS

■ 0xC0000BD3 - PDH_NOT_IMPLEMENTED

■ 0xC0000BD4 - PDH_STRING_NOT_FOUND

■ 0x80000BD5 - PDH_UNABLE_MAP_NAME_FILES

■ 0xC0000BD6 - PDH_UNKNOWN_LOG_FORMAT

■ 0xC0000BD7 - PDH_UNKNOWN_LOGSVC_COMMAND

116
Mécanismes système

■ 0xC0000BD8 - PDH_LOGSVC_QUERY_NOT_FOUND

■ 0xC0000BD9 - PDH_LOGSVC_NOT_OPENED

■ 0xC0000BDA - PDH_WBEM_ERROR

■ 0xC0000BDB - PDH_ACCESS_DENIED

■ 0xC0000BDC - PDH_LOG_FILE_TOO_SMALL

■ 0xC0000BDD - PDH_INVALID_DATASOURCE

■ 0xC0000BDE - PDH_INVALID_SQLDB

■ 0xC0000BDF - PDH_NO_COUNTERS

■ 0xC0000BE0 - PDH_SQL_ALLOC_FAILED

■ 0xC0000BE1 - PDH_SQL_ALLOCCON_FAILED

■ 0xC0000BE2 - PDH_SQL_EXEC_DIRECT_FAILED

■ 0xC0000BE3 - PDH_SQL_FETCH_FAILED

■ 0xC0000BE4 - PDH_SQL_ROWCOUNT_FAILED

■ 0xC0000BE5 - PDH_SQL_MORE_RESULTS_FAILED

■ 0xC0000BE6 - PDH_SQL_CONNECT_FAILED

■ 0xC0000BE7 - PDH_SQL_BIND_FAILED

■ 0xC0000BE8 - PDH_CANNOT_CONNECT_WMI_SERVER

■ 0xC0000BE9 - PDH_PLA_COLLECTION_ALREADY_RUNNING

■ 0xC0000BEA - PDH_PLA_ERROR_SCHEDULE_OVERLAP

■ 0xC0000BEB - PDH_PLA_COLLECTION_NOT_FOUND

■ 0xC0000BEC - PDH_PLA_ERROR_SCHEDULE_ELAPSED

■ 0xC0000BED - PDH_PLA_ERROR_NOSTART

■ 0xC0000BEE - PDH_PLA_ERROR_ALREADY_EXISTS

■ 0xC0000BEF - PDH_PLA_ERROR_TYPE_MISMATCH

■ 0xC0000BF0 - PDH_PLA_ERROR_FILEPATH

■ 0xC0000BF1 - PDH_PLA_SERVICE_ERROR

■ 0xC0000BF2 - PDH_PLA_VALIDATION_ERROR

■ 0x80000BF3 - PDH_PLA_VALIDATION_WARNING

■ 0xC0000BF4 - PDH_PLA_ERROR_NAME_TOO_LONG

■ 0xC0000BF5 - PDH_INVALID_SQL_LOG_FORMAT

117
Mécanismes système

■ 0xC0000BF6 - PDH_COUNTER_ALREADY_IN_QUERY

■ 0xC0000BF7 - PDH_BINARY_LOG_CORRUPT

■ 0xC0000BF8 - PDH_LOG_SAMPLE_TOO_SMALL

■ 0xC0000BF9 - PDH_OS_LATER_VERSION

■ 0xC0000BFA - PDH_OS_EARLIER_VERSION

■ 0xC0000BFB - PDH_INCORRECT_APPEND_TIME

■ 0xC0000BFC - PDH_UNMATCHED_APPEND_COUNTER

■ 0xC0000BFD - PDH_SQL_ALTER_DETAIL_FAILED

■ 0xC0000BFE - PDH_QUERY_PERF_DATA_TIMEOUT

Event Tracing for Windows


Le suivi d’événements Windows (ETW, Event Tracing for Windows) est une infrastructure de journalisation qui
fournit des données de trace et permet l’analyse dynamique des événements déclenchés par les différents
composants du système, dont le noyau et divers pilotes de périphérique.

Dans les grandes lignes, ETW fonctionne sur la base d’un modèle de prestataires et d’abonnés. Des
applications et des composants du système peuvent conformément à cette perspective enregistrer et rendre
visible des données de trace, et d’autres applications et composants peuvent récupérer et exploiter ces
données, le plus souvent à des fins de dépannage ou d’audit. Il est possible d’accéder aux informations
émises depuis ETW de nombreuses façons : langages natifs et gérés, scripts, PowerShell, utilitaire
Performances, entres autres.

Les applications utilisant ETW entrent dans l’une au moins des catégories suivantes :

■ Contrôleur Un contrôleur démarre et arrête les sessions de journalisation.

■ Fournisseur Un fournisseur définit des classes d’événements pour lesquelles il peut produire des traces.

■ Consommateur Un consommateur sélectionne une ou plusieurs sessions de trace dont il veut lire les
données.

Les fonctions mises en œuvre par ETW le sont par l’intermédiaire de la bibliothèque Advapi32 jusque
Windows 8, et de la bibliothèque Sechost pour ce qui concerne les versions supérieures du système. Les
interfaces idoines, prototypes d’appels et structures de données notamment, sont quant à elles déclarés
dans le fichier en-tête EvnTrace.h du kit de développement Windows.

Windows Resource Protection


Pour préserver l’intégrité du système d’exploitation et maintenir au mieux ses capacités opérationnelles,
Windows possède une technologie appelée Windows Resource Protection (WRP) qui permet de détecter
tout changement suspect de la configuration ou au sein de fichiers, réduisant par là même la possibilité
d’altérations nuisibles induites par des logiciels ou des utilisateurs.

Suite logique des fonctionnalité WFP (Windows File Protection) et SFP (System File Protection) des versions
de Windows précédant Vista, WRP couvre les éléments que voici :

■ Composants impliqués dans le processus de démarrage

118
Mécanismes système

■ Fichiers exécutables et bibliothèques (DLL)

■ Répertoires et fichiers

■ Clés de registre essentielles au bon fonctionnement du système

En interne, la protection offerte par WRP l’est par l’intermédiaire de listes de contrôle d’accès minimales
attribués aux paramètres, fichiers et emplacements critiques de la plateforme, listes qui sont configurés
pour n’accorder l’accès qu’à un seul compte, en l’occurence le service Trusted Installer. Autrement dit,
dans la perspective WRP, même les administrateurs et utilisateurs disposant d’informations d’identification
administratives ne peuvent opérer de changements parmi les ressources protégées.

WRP possède une copie des fichiers indispensables au démarrage de Windows. Ces fichiers sont
sauvegardés dans le répertoire servant de cache à l’emplacement \Windows\winsxs\Backup. Les fichiers du
système protégés par WRP mais non utiles au démarrage ne sont pas copiés dans le répertoire de cache. La
taille de ce répertoire ainsi que la liste des fichiers qu’il contient ne sont pas modifiables.

Vérificateur de ressources (Sfc)


Expression parmi les plus manifestes de la protection des ressources Windows, le Vérificateur de ressources
est un outil en ligne de commandes qui vérifie que la plateforme possède les versions correctes des fichiers
système protégés. Pour utiliser le Vérificateur de ressources, ouvrez une fenêtre d’invite de commandes en
tant qu’administrateur et tapez la commande Sfc suivie du paramètre approprié. Le tableau suivant liste les
paramètres admissibles en matière d’interaction avec le programme Vérificateur de ressources.

Tableau 3.2. Paramètres du Vérificateur de ressources.

/SCANNOW Analyse les fichiers protégés et répare ceux


éventuellement endommagés.
/VERIFYONLY Analyse les fichiers protégées mais n’effectue
aucune pas de réparation.
/VERIFYFILE Analyse le fichier dont le chemin d’accès est
spécifié.
/OFFBOOTDIR Pour les réparations hors ligne. Spécifie
l’emplacement du répertoire d’amorçage hors ligne.
/OFFWINDIR Pour les réparations hors ligne. Spécifie
l’emplacement du répertoire Windows hors ligne.

Dans l’éventualité où Sfc découvre qu’un fichier sous sa tutelle a été remplacé, modifié ou est corrompu,
l’utilitaire se met alors en quête d’une mouture correcte dudit fichier depuis le répertoire cache prévu à cet
égard : \Windows\System32\Dllcache pour les versions de Windows antérieures à Vista et \Windows\Winsxs
\Backup pour les versions de Windows depuis Vista. S’il en trouve une, l’élément incriminé est alors supprimé
afin de céder la place à une version attendue, dûment approuvée - et par ailleurs signée.

Les investigations menées sous la houlette du Vérificateur de ressources, de même que les actions qui
potentiellement en découlent (autrement dit les réparations), peuvent s’étendre à l’ensemble des fichiers
protégées du système, ou à plus petite échelle ne concerner qu’un seul d’entre eux. Dans ce second cas de
figure, indiquez auprès des commutateurs verifyfile et scanfile le le chemin d’accès complet à un fichier. Par
exemple, sfc /verifyfile=c:\windows\system32\kernel32.dll vérifie si le fichier kernel32.dll est valide.

Sfc consigne les détails relatifs aux opérations effectuées par ses soins via le fichier CBS.log, situé sous
\Windows\Logs\CBS. Chaque entrée dans ce journal en lien avec Sfc comporte la balise prédéfinie [SR], de
sorte que vous puissiez repérer facilement quelles procédures de vérification et/ou de réparation ont eu lieu.
Pour effectuer des recherches parmi ce fichier, utilisez la commande findstr.

119
Mécanismes système

Threads système auxiliaires


Tôt dans la phase d’amorçage du système, Windows orchestre la création parmi le processus System de
plusieurs threads, appelés threads système auxiliaires, chargés d’effectuer des taches pour le compte d’autres
threads.

L’un des rôles premiers des threads système auxiliaires est d’agir en tant qu’intermédiaire entre des threads
exécutés au niveau IRQL haut et des opérations dont la nature et/ou les caractéristiques les prédisposent à
un IRQL inférieur. Par exemple, une routine DPC exécutée dans un contexte de thread à l’IRQL DPC/dispatch
(car l’exécution DPC peut usurper n’importe quel thread du système) pourrait avoir besoin d’accéder au
pool paginé. Etant donné, d’une part, qu’il est impossible de satisfaire aux défauts de page au niveau DPC/
dispatch, et d’autre part, qu’une routine DPC ne peut pas diminuer l’IRQL, elle doit en l’occurrence passer
le relais pour ce genre de traitement à un thread exécuté à un IRQL inférieur, ce à quoi répond précisément
le mécanisme des threads auxiliaires.

Un autre avantage procuré par les threads système auxiliaires, du reste non le moindre, réside dans la
diminution de la surcharge d’ordonnancement et de mémoire induite par la multiplication des threads dans
le système.

Pilotes de périphériques et composants de l’exécutif interagissent avec les threads auxiliaires en premier lieu
par l’intermédiaire des fonctions ExQueueWorkItem et IoQueueWorkItem, toutes deux chargées d’insérer
un élément de travail (work item) dans une file d’attente où le système recherche des tâches à accomplir.
Chaque élément de travail contient un pointeur vers une routine de rappel et un paramètre spécifiant les
informations de contexte qui seront utiles quand ladite routine prendra vie. A un moment ultérieur, un thread
système auxiliaire supprimera l’élément de travail de sa file et exécutera la routine idoine. Lorsque cette
dernière se termine, le thread système auxiliaire vérifie si d’autres éléments de travail sont en attente et, si
oui, les traite. Cette approche et ses effets se poursuivent indéfiniment.

Il existe trois types de thread système auxiliaires :

■ Les threads auxiliaires différés, exécutés au niveau de priorité 12, prennent en charge des fonctions qui
ne sont pas considérés comme temporellement critiques et peuvent voir leur pile remisée dans un fichier
de pagination.

■ Les threads auxiliaires critiques, exécutés au niveau de priorité 13, prennent en charge des fonctions
temporellement critiques.

■ L’unique thread auxiliaire hypercritique est exécuté au niveau de priorité 15 et a sa pile toujours présente
en mémoire physique.

Le nombre de threads auxiliaires critiques est revue en permanence en fonction de la charge de travail de
l’ordinateur. Chaque seconde, un sous-ensemble du balance set manager examine le besoin de nouveaux
threads auxiliaires critiques et, si ce dernier est jugé réel, en crée un. Les threads créés par ce biais sont dits
threads auxiliaires dynamiques ; la création d’un tel thread exige que soient remplies un certain nombre de
conditions, à savoir :

■ La file de travail critique contient des éléments à traiter.

■ Le nombre de threads auxiliaires critiques inactifs est inférieur au nombre de processeurs dont dispose
le système. (Les threads critiques inactifs le sont du fait d’attendre soit des éléments de travail, soit des
objets dispatcher.)

■ Le nombre de threads auxiliaires dynamiques est inférieur à 16.

Dans la configuration par défaut, le nombre initial de threads auxiliaires différés et critiques dépend
de la capacité mémoire du système (valeur retournée par MmQuerySystemSize) et de la version de

120
Mécanismes système

Windows. Les administrateurs peuvent apporter des modifications sur ces aspects en modifiant les valeurs
AdditionalCriticalWorkerThreads et AdditionalDelayedWorkerThreads sous la clé de registre HKLM\SYSTEM
\CurrentControlSet\Control\SessionManager\Executive.

La commande !exqueue du débogueur noyau affiche des informations détaillées en ce qui concerne les
threads système auxiliaires.

Une chose importante à garder à l’esprit lors de l’utilisation des threads système auxiliaires se situe dans le
fait que tous les composants noyau se partagent à cet égard les mêmes ressources (une file de travail ne peut
satisfaire qu’un nombre limité de threads). Les opérations exécutés de la sorte, quand elles sont couteuses
en temps, retardent l’exécution d’autres services, et peuvent de ce fait entrainer une diminution plus ou
moins accentuée des performances du système. Par conséquent, l’exécution par l’intermédiaire d’éléments
de travail devrait dans l’idéal ne concerner que des séquences de traitement relativement courtes.

LPC (Local Procedure Call)


L’appel de procédure locale (Local Procedure Call, mais aussi Lightweight Procedure Call ou Local Inter-
Process Communication) est une technologie de communication inter processus pour transmission rapide
de messages. S’imposant comme l’une des clés de voûte du modèle de communication de Windows
(architecture client-serveur), LPC se rencontre très fréquemment partout dans le système d’exploitation, y
compris les scénarios que voici :

■ Les programmes applicatifs requièrent des services de la part des différents sous-systèmes de Windows
via LPC. Par exemple, quelques API Windows aboutissent à l’envoi de messages au processus du sous-
système Windows, Csrss.

■ Les applications Windows qui emploient RPC (Remote Procedure Call) utilisent indirectement LPC quand
elles spécifient RPC local (protocole ncalrpc), variante de RPC employée pour la communication entre
processus d’un même système.

■ Le processus serveur d’authentification de sécurité locale (Lsass), le gestionnaire de session (Smss) et le


gestionnaire de contrôle des services (Scm) se servent de LPC pour communiquer avec leur processus
client respectifs.

■ Certains processus système s’appuient sur LPC de sorte à interagir entre eux, par exemple Winlogon et
Lsass, ou encore le moniteur de références de sécurité et Lsass.

Essentiellement fondé sur le paradigme du passage de messages, LPC s’utilise en principe entre un processus
serveur et un ou plusieurs processus client. Il est possible de créer une connexion LPC entre deux processus
mode utilisateur, ou entre un composant mode noyau et un processus utilisateur.

Similaire par bien des aspects à RPC (Remote Procédure Call), lequel protocole est utilisé dans une vaste
gamme de systèmes d’exploitation (y compris, du reste, Windows) pour faire du traitement distribué sur un
réseau, LPC est par contraste optimisé pour l’usage local et est spécifique à Windows.

Les fonctions mettent en oeuvre LPC ont comme point d’ancrage ntdll et ntoskrnl.exe. Elles ne sont en
l’occurence pas directement accessibles depuis l’API Windows.

Le composant LPC distingue deux types de ports : les ports de connexion et les ports de communication.
Les ports de connexion sont des objets dotés d’un nom, visibles de tous les processus, qui donnent aux
applications un moyen commode de mettre un canal de communication, lequel canal est dans la perspective
LPC constitué d’une paire de ports privés de communication : un pour les message du client vers le serveur et
l’autre pour les messages du serveur vers le client. Les canaux de communication supportent un mécanisme
de rappel. Le client et le serveur peuvent donc accepter des requêtes tandis qu’ils attendent une réponse.
Voici, en définitive, quelles sont les différentes extrémités d’une communication LPC. Voici, en définitive,
quelles sont les différentes sorts de port potentiellement visibles parmi une communication LPC.

121
Mécanismes système

■ Port de connexion serveur Port nommé créé par le serveur de façon à être à l’écoute des éventuelles
connexions entrantes, et sur lequel les processus client peuvent se connecter pour dialoguer avec le
serveur.

■ Port de communication serveur Port non nommé permettant au processus serveur de dialoguer avec un
processus client donné. Le serveur a un seul port de ce genre par client actif.

■ Port de communication client Port non nommé utilisé par un processus client pour communiquer avec
un processus serveur donné.

■ Port de communication anonyme Port non nommé utilisé par deux threads d’un même processus pour
communiquer.

LPC s’utilise généralement comme ceci :

1. Un serveur crée un objet de type port de connexion nommé (NtCreatePort) puis donne lieu à une écoute
du port en question (NtListenPort).

2. Un client fait une demande de connexion à ce port (NtConnectPort).

3. Le serveur détermine si la demande est valide et, si elle l’est, l’accepte (NtAcceptConnectPort, suivie
d’un appel à NtCompleteConnectPort). Il y a à ce moment création de deux ports sans nom, un port de
communication serveur et un port de communication client. Le client et le serveur se servent alors de ces
nouveaux ports pour leur communication.

4. Le serveur enregistre une boucle par l’intermédiaire de laquelle il continue à traiter de nouveaux messages
et à y répondre en conséquence (NtReplyWaitReceivePort).

5. Le client envoie une nouvelle demande au serveur et attend que ce dernier lui donne suite
(NtRequestWaitReplyPort). Cette étape et la précédente se répètent tout le temps du lien entre serveur
et client.
LPC offre trois méthodes d’échange de messages :

■ La première méthode, également la plus simple d’entre elles, est adaptée aux petits messages (d’au
plus 256 octets). Dans ce cas, la file d’attente de messages du port est employée comme espace
de stockage intermédiaire et les messages sont copiées d’un processus à l’autre. Le noyau effectue
une copie du tampon contenant le message depuis l’espace d’adressage du processeur émetteur vers
l’espace d’adressage système, puis réitère l’opération dans le sens nécessaire, autrement dit depuis
l’espace d’adressage système vers l’espace d’adressage du processus récepteur.

■ La seconde méthode, approprié aux messages plus grands, s’appuie sur un object section de mémoire
partagée donnant lieu auprès des processus émetteur et récepteur à une représentation du canal de
communication. Dans cette configuration, l’émetteur écrit tout d’abord dans la section partagée les
informations qu’il souhaite publier, puis envoie dans la file d’attente du port un court message (en
utilisant la méthode décrite plus haut) qui contient des pointeurs vers l’emplacement des données dans
la section partagée, permettant de cette façon au receveur de les voir.

■ La troisième technique de messages LPC, mise en place du moment qu’un serveur veut interagir avec
des données trop volumineuses pour être hébergées dans une section partagée, s’appuie sur des API
qui lisent/écrivent directement dans l’espace d’adressage d’un processus. Le composant LPC fournit un
petit nombre de fonctions permettant au serveur de procéder de la sorte, et ainsi pouvoir accéder à une
donnée dans un client. (Pour d’évidentes raisons de sécurité, l’inverse n’est bien entendu pas possible.)

Tableau 3.3. Services concernant LPC

NTSTATUS NtAcceptConnectPort (PHANDLE PortHandle, PVOID PortContext, PPORT_-


MESSAGE ConnectionRequest, BOOLEAN AcceptConnection, PPORT_VIEW
ServerView, OUT PREMOTE_PORT_VIEW ClientView)

122
Mécanismes système

NTSTATUS NtCreateWaitablePort (PHANDLE PortHandle, POBJECT_ATTRIBUTES


ObjectAttributes, ULONG MaxDataSize, ULONG MaxMessageSize, ULONG
Reserved)
  NtImpersonateClientOfPort
NTSTATUS NtListenPort (HANDLE PortHandle, PPORT_MESSAGE Message)
NTSTATUS NtQueryInformationPort (HANDLE PortHandle, PORT_INFORMATION_CLASS
PortInformationClass, PVOID PortInformation, ULONG PortInformationLength,
PULONG ReturnLength)
  NtQueryPortInformationProcess
NTSTATUS NtReplyPort (HANDLE PortHandle, PPORT_MESSAGE ReplyMessage)
NTSTATUS NtRequestPort (HANDLE PortHandle, PPORT_MESSAGE LpcMessage)
NTSTATUS NtRequestWaitReplyPort (HANDLE PortHandle, PPORT_MESSAGE LpcReply,
PPORT_MESSAGE LpcRequest)

Tableau 3.4. Variables noyau concernant LPC

Variable Type Description


AlpcpPortMapping GENERIC_MAPPING Mappage générique des droits
d’accès aux ports (A)LPC
LpcPortObjectType POBJECT_TYPE  
LpcWaitablePortObjectType POBJECT_TYPE  

APC (Asynchronous Procedure Calls)


Les APC (Asynchronous Procedure Calls) offrent un moyen aux programmes utilisateur et aux composants
système d’exécuter du code dans le contexte (et partant, dans l’espace d’adressage) d’un thread spécifique.
Étant donné que les APC sont mis en file pour exécution dans le contexte d’un thread choisi (par opposition
à un thread arbitraire) et qu’ils sont exécutés à un IRQL inférieur au niveau DPC/dispatch, ils ne sont pas
soumis aux mêmes restrictions qu’un DPC. Une routine APC peut ainsi acquérir des ressources, attendre des
handles d’objet, subir des défauts de page, et ainsi de suite.

Il existe deux sortes d’APC : mode noyau et mode utilisateur, l’un et l’autre se différenciant essentiellement
par les conditions attendues et par la temporalité dans laquelle le traitement qui résulte d’une interruption
APC peut entrer en lice (du point de vue de l’ordonnancement). Ainsi, les APC mode noyau interrompent
un thread et exécutent une procédure à l’insu et sans le consentement des parties concernées (autrement
dit le thread cible) ; les APC mode utilisateur sont quant à eux livrés à un thread seulement quand ce
dernier se trouve dans une situation spécifique, à savoir l’état d’attente alertable. La catégorie des APC
mode noyau se subdivise encore en deux sous-types : normal et spécial. Les APC mode noyau normales
sont exécutées au niveau passif, les APC mode noyau spéciales au niveau APC. Un thread peut désactiver
les APC normales par le biais de la routine KeEnterCriticalRegion, la livraison des APC spéciales étant dans
cette configuration toujours maintenue. Un thread peut désactiver à la fois les APC normales et les APC
spéciales soit par augmentation de l’IRQL au niveau APC (KeRaiseIrql), soit en s’en remettant à une région
gardée (KeEnterGuardedRegion).

Plusieurs des mécanismes centraux pris en charge par Windows le sont via des APC. Le système emploie
par exemple des APC pour initier l’exécution des threads, compléter les entrées/sorties, mettre fin à des
processus et des threads, attacher un débogueur à une applications, gérer les expirations de minuterie, etc.

Du code mode utilisateur peut mettre en file d’attente un APC pour un thread par le biais de la fonction
QueueUserAPC, laquelle s’appuie en interne sur le service système NtQueueUserApcThread. Suite à cet
appel, le noyau alloue alors depuis le pool paginé un objet de contrôle KAPC, associé à l’APC en vue
de le représenter. Dans l’éventualité où la quantité de mémoire disponible est trop faible pour répondre

123
Mécanismes système

positivement à la demande, l’opération échoue, empêchant de ce fait la distribution de l’APC - ce qui dans le
cas contraire serait susceptible d’entraver le fonctionnement efficace du système d’exploitation (relativement
quand même à ce à quoi l’APC est employé). Pour anticiper un tel scénario, une application peut lors de son
démarrage utiliser NtAllocateReserveObject afin de demander au noyau l’allocation préalable de la structure
susmentionnée.

Comme nous l’avons déjà dit, les APC mode utilisateur sont livrés à un thread seulement quand il est dans un
état d’attente alertable, ce qui peut potentiellement impliquer un délai plus ou moins long entre le moment
où un APC est mis en file et le moment où la routine APC apparentée est réellement exécutée. Quand un
thread en état alertable a un APC mode utilisateur en suspens, le noyau alerte le thread, passe le relais à
la routine APC puis, du moment que cette dernière a fini, reprend l’exécution du thread. Dans l’éventualité
où un thread en état alertable voit son attente satisfaite avant mise en file de l’APC (ce qui a pour effet en
définitive de court-circuiter l’état alertable), la routine n’est pas exécutée, et le sera quand les circonstances
se montreront propices (autrement dit la prochaine fois que le thread sera en état d’attente d’altertable.

Chaque APC est au niveau du noyau représenté par le biais d’une structure KAPC.

KAPC. 
lkd> dt nt!_KAPC
+0x000 Type : UChar
+0x001 SpareByte0 : UChar
+0x002 Size : UChar
+0x003 SpareByte1 : UChar
+0x004 SpareLong0 : Uint4B
+0x008 Thread : Ptr64 _KTHREAD
+0x010 ApcListEntry : _LIST_ENTRY
+0x020 KernelRoutine : Ptr64 void
+0x028 RundownRoutine : Ptr64 void
+0x030 NormalRoutine : Ptr64 void
+0x020 Reserved : [3] Ptr64 Void
+0x038 NormalContext : Ptr64 Void
+0x040 SystemArgument1 : Ptr64 Void
+0x048 SystemArgument2 : Ptr64 Void
+0x050 ApcStateIndex : Char
+0x051 ApcMode : Char
+0x052 Inserted : UChar

IRQL
Au delà de l’importance préférentielle donnée aux interruptions sur le plan matériel, Windows met en
exergue de cette dynamique divers niveaux de requête d’interruptions (IRQL, Interrupt Request Level),
lesquelles servent à prioriser les interruptions émanant des différents composants du système, autant
physiques que logiques. Le noyau représente les IRQL en interne sous forme de numéros compris entre 0
et 31 sous x86 et entre 0 et 15 sous x64 ; plus le numéro est élevé, plus la priorité est forte.

Chaque processeur a une configuration IRQL qui détermine quelles sont les interruptions que peut recevoir
ce processeur. Les interruptions servies dans ce contexte le sont par ordre de priorité, une interruption
préemptant le traitement d’une autre de priorité inférieure. Les interruptions ayant pour origine une source
dont l’IRQL est supérieur au niveau courant, impliquant dès lors une prise en charge la plus rapide possible,
interrompent le processeur, tandis que les interruptions provenant de sources ayant des IRQL inférieurs
ou égaux au niveau courant ne l’interrompent pas, et sont de la sorte remises à plus tard. Modifier l’IRQL
d’un processeur étant une opération délicate, elle ne peut s’effectuer qu’en mode noyau, les threads mode
utilisateur n’ayant dans ce domaine, et à quelque niveau que ce soit, aucun impact. Sur le plan factuel,
cela signifie que l’IRQL d’un processeur est toujours au niveau le plus faible (autrement dit le plus sujet aux
interruptions de toutes sortes) quand il exécute du code mode utilisateur, et ce n’est dès lors que quand le
processeur exécute du code mode noyau que l’IRQL peut être supérieur.

Un thread ajuste (augmente ou diminue) l’IRQL du processeur sur lequel il est exécuté selon la nature des
tâches qu’il envisage d’accomplir (attendre des objets dispatcher, accéder au pool paginé, et ainsi de suite).
Ainsi, quand une interruption à haute priorité se manifeste, le gestionnaire d’interception augmente l’IRQL

124
Mécanismes système

du processeur afin de lui donner la valeur de l’IRQL assignée à la source de l’interruption. Cette augmentation
masque toutes les interruptions égales ou inférieures à cet IRQL (sur ce processeur uniquement), ce qui a
pour effet de garantir que le processeur assurant le traitement de l’interruption ne pourra être monopolisé
qu’au bénéfice d’une interruption de priorité supérieure. Après exécution de de la routine de service idoine,
le dispatcher abaisse l’IRQL, faisant au passage éventuellement apparaitre des interruptions jusqu’alors
masquées. (Les interruptions masquées sont soit traitées par un autre processeur, soit suspendues jusqu’à
ce que la configuration IRQL du processeur s’y prête). Par conséquent, tous les composants du système, y
compris le noyau et les pilotes de périphérique, s’efforcent de maintenir l’IRQL à son seuil le plus faible (en
l’occurence le niveau passif, sur lequel nous reviendrons plus loin).

S’ils peuvent sembler apparentés, les niveaux de priorité d’interruption n’existent pas à la même échelle ni
n’ont la même signification que les priorités d’ordonnancement de thread. Une priorité d’ordonnancement
est une valeur dont la portée ne va pas au-delà d’un thread, éventuellement d’un groupe de threads, tandis
qu’un IRQL est un attribut de source d’interruption (processeur, clavier, souris, etc.).

■ L’IRQL le plus faible, à quoi correspond le niveau passif (parfois appelé niveau bas), se rapporte au contexte
d’exécution normale de threads, dans lequel toutes les interruptions peuvent survenir.

Les niveaux DPC/dispatch et APC sont des interruptions logicielles générées par le noyau et les pilotes de
périphériques en différentes occasions.

Les IRQL périphérique servent à prioriser les interruptions émanant des périphériques.

Le niveau horloge est employé pour l’horloge du système, que le noyau utilise pour gérer l’heure ainsi que
pour mesurer et allouer le temps processeur aux threads.

125
Chapitre 4. Mécanismes de gestion
Ce chapitre procure une vue détaillée de quelques-uns des dispositifs fondamentaux de Microsoft Windows
en rapport avec l’administration et la configuration du système :

■ Registre

■ Services

■ WMI (Windows Management Instrumentation)

■ Événements

Registre
Jouant un rôle clé dans la supervision et le contrôle des systèmes, composants et logiciels Windows, le
registre sert de lieu d’hébergement à moult paramètres de configuration, qu’ils soient de niveau global
ou spécifiques à l’utilisateur. Cela inclut, par exemple, les options d’amorçage du noyau, les paramètres
d’applications et de pilotes, les préférences et affinités des utilisateurs, leur profil de sécurité, et bien d’autres.

Une large majorité des utilisateurs voient le registre tel un ensemble de données statiques rangées sur
le disque dur, à la façon, par exemple, d’une boite de dépôt. Si elle a de solides raisons d’exister, cette
perceptive est aussi très réductrice, dans la mesure où, ainsi que vous le verrez plus loin, le registre constitue
en réalité une passerelle vers toutes sortes de données mouvantes dans le temps : état du système, liste des
services actifs, reflets des structures gérées en mémoire par l’exécutif et le noyau, compteurs de performance,
etc.

Tableau 4.1. Fonctions Windows concernant le registre

Fonction Description
RegCloseKey Ferme la clé spécifiée.
RegCreateKey Crée, ou éventuellement ouvre, une clé de registre.
RegDeleteKey Supprime une clé.
RegEnumKeyEx Liste les sous-clés présentes sous une clé.
RegEnumValue les valeurs contenues dans une clé.
RegOpenKeyEx Ouvre une clé de registre.
RegQueryValueEx Interroge la clé spécifié.
RegSetValueEx Crée ou modifie les valeurs contenues dans une clé.

Origines du registre
S’il dispose aujourd’hui bel et bien d’une place prépondérante au sein des systèmes Microsoft, le registre
n’a pas toujours toujours endossé des responsabilités aussi lourdes. Les versions initiales de Windows se
passaient du reste totalement de ce genre de procédé, et les quelques déclinaisons qui suivirent (jusqu’à
Windows 95 en réalité) ne l’employaient que de façon très superficielle.

Avant Windows 3.1, les plateformes Windows utilisaient pour la mémorisation des paramètres relatifs aux
composants systèmes et aux programmes des fichiers INI. Hébergeant des données de nature uniquement
textuelle (donc facilement manipulable au travers une large gamme de logiciels), ces fichiers étaient divisées
en sections comportant chacune un nombre plus ou moins important de déclarations. Chaque donnée était
déclarée par un nom de variable, suivi par un signe égal, lui-même suivi par la valeur de la variable. Les noms

126
Mécanismes de gestion

des sections étaient indiqués entre crochets et tout ce qui suivait ce nom appartenait à la section. Partant
de cette nomenclature, un fichier INI ressemble à ce qui suit.
[section 1]
Parameter1=Value1
Parameter2=Value2
Parameter3=Value3

Avec l’apparition d’OLE dans Windows 3.1, et plus généralement des composants basés sur COM, les
besoins en stockage et consultation de paramètres divers augmentèrent considérablement, cela avec
comme effet secondaire d’attirer l’attention sur les limites, tant pratiques que conceptuelles, des fichiers INI.
Depuis la sortie du système d’exploitation Windows NT, en 1993, l’essentiel des éléments de la configuration
est enregistré à l’échelle d’une base de données dévolue spécifiquement à cet usage, en l’occurence le
registre.

Composants du registre
Les éléments suivants sont à considérer pour leurs relations (plus ou moins directes) avec le registre :

■ Gestionnaire de configuration Le gestionnaire de configuration est le composant de l’exécutif Windows


chargé d’implémenter la base de données du registre.

■ Ruches La sauvegarde physique (sur disque) de la base de données du registre se présente comme un
ensemble de fichiers appelés ruches. Chaque ruche correspond à un fichier, et contient une arborescence
de registre.

■ Regedit Windows inclut nativement plusieurs outils afin de superviser le registre, dont Regedit, qui permet
d’agir de manière très fine dans la configuration du système, et met entre les mains d’utilisateurs avancés
la possibilité de modifier la base, et d’attribuer des droits spécifiques sur les clés du registre. Un portait
plus large de l’Editeur de Registre est donné plus loin dans ce chapitre.

■ Clés, sous-clé, valeurs La base de données du registre est faite de clés, de sous-clés et de valeurs. Une
clé peut contenir d’autres clés (sous-clés) ou des valeurs. Une valeur contient des données.

■ Synchronisation de ruche Un thread système fait de la synchronisation de ruche, opération rendue


nécessaire par le fait que les données mémoire correspondant au registre doivent un temps après leur
modification être conservées (écrites) sur le disque (ce que l’on appelle l’écriture différée).

Scénarios d’utilisation du Registre


Windows sollicite les données de configuration stockées dans le registre en de multiples occasions :

■ Amorçage du système Lors de l’amorçage, le système lit des paramètres spécifiant quels sont les pilotes
de périphérique et les services à charger et comment les divers composants (gestionnaire de mémoire,
gestionnaire de processus, et d’autres.) interagissent entre eux et optimisent le comportement du système.
La structure initiale du registre et nombre de paramètres par défaut sont définis par un prototype du
registre qui est copié sur le disque lors d’une nouvelle installation de Windows.

■ Ouverture de session Lors d’une ouverture de session, le registre sert à la mise en conformité de
l’environnement par rapport aux préférences de l’utilisateur connecté. Cela comprend, par exemple,
les désignations (les lettres) de lecteur réseau, l’économiseur d’écran, l’environnement de bureau
(comprendre l’explorateur), le style des menus, le papier peint du bureau, l’emplacement des icônes, etc.

■ Démarrage d’application Lors de son démarrage, une application peut éventuellement orienter son
comportement en fonction de paramètres de niveau système, en rapport par exemple à des informations
de licence ou à d’autres données qualitatives, ou de niveau utilisateur, par exemple l’emplacement des
menus et barres d’outils ou la liste des derniers documents manipulés. Certaines applications surveillent

127
Mécanismes de gestion

leurs données de configuration dans le registre et lisent les paramètres modifiés quand elles détectent
un changement.

■ Installation d’application Le registre permet aux applications de disposer d’un endroit unique où
conserver leurs options de configuration. Les programmes d’installation des applications créent des
paramètres et des profils qui reflètent les choix de configuration de l’installation.

■ Ajout de nouveau pilote Lors de l’installation d’un pilote de périphériques, le système de prise en charge
Plug and Play créé dans le registre des paramètres indiquant au gestionnaire d’E/S comment démarrer
et configurer le pilote.

■ Création de profils utilisateur La création de nouveaux utilisateurs alimente implicitement le registre,


dans la mesure où c’est à cet endroit qu’est rangé l’ensemble des données spécifiques à un utilisateur
et à ses préférences.

■ Modification de la configuration Que vous modifiiez des paramètres de niveau système ou de niveau
application, les modifications idoines sont souvent reportées dans le registre. Elles sont de cette façon
pérennes et existent au delà une réinitialisation du système.

Organisation du registre
Le Registre est agencée sous une forme analogue à celles de volumes disque, faite en l’occurence d’éléments
empruntés aux systèmes de fichiers. Les informations dans le Registre sont rangées dans un système en
arbre contenant des clés et des valeurs, équivalents des répertoires et des fichiers. Une clé peut contenir
d’autres clés (sous-clés) ou des valeurs. Une valeur, en revanche, contient des données. Les clés de premier
niveau (dans l’arbre) sont les clés racine.

Les conventions de nommage à l’intérieur du Registre s’inspirent de celles à l’oeuvre dans une partition
Windows. Ainsi, une valeur de nom y stockée dans une clé de nom x est identifié par le nom x\y. On retrouve
comme élément utilisé pour la classification la barre contre-oblique. S’il vient seul (\) ce caractère représente
la racine du registre. Autrement, il permet de repérer sans ambiguïté clés et valeurs de registre.

Types de données du registre


A l’instar des langages de programmation, le registre Windows offre plusieurs types primitifs grâce auxquels
représenter (et donc manipuler) des informations de toutes sortes, tels que chaînes, compteurs, intervalles,
booléens (valeurs oui/non), liens symboliques (clé pointant vers une autre), etc.

Le tableau ci-dessous apporte un bref éclairage sur les quelques types de données (au nombre, du reste, de
15) admis dans le Registre, et les sections qui suivent des informations complémentaires en ce qui concerne
chacun d’entre eux.

Tableau 4.2. Types des valeurs du registre

Type Description
REG_BINARY Données binaires de longueur variable
REG_DWORD Nombre de 32 bits
REG_DWORD_BIG_ENDIAN Nombre de 32 bits avec octet de poids fort en
premier
REG_DWORD_LITTLE_ENDIAN Nombre de 32 bits avec octet de poids faible en
premier (équivaut à REG_DWORD)
REG_EXPAND_SZ Chaîne Unicode de longueur variable
REG_FULL_RESOURCE_DESCRIPTOR Description de ressource matérielle

128
Mécanismes de gestion

REG_LINK Lien symbolique


REG_MULTI_SZ Tableau de chaînes
REG_NONE Aucun type
REG_QWORD Nombre de 64 bits
REG_QWORD_BIG_ENDIAN Nombre de 64 bits avec octet de poids fort en
premier
REG_QWORD_LITTLE_ENDIAN Nombre de 64 bits avec octet de poids faible en
premier (équivaut à REG_QWORD)
REG_RESOURCE_LIST Description de ressource matérielle
REG_RESOURCE_REQUIREMENTS_LIST Exigences de la ressource REG_SZ

REG_BINARY
Les valeurs REG_BINARY renferment des données binaires brutes, telles que des clés cryptographiques ou
des mots de passe chiffrés. Par nature, de telles informations n’incorporent pas de commodité ni au niveau
de l’analyse ni de la présentation (pas de caractère de terminaison, d’expansion de chaines, etc.) Une large
majorité des utilitaires permettant de visualiser le registre montrent ces informations au format hexadécimal.
Pour voir concrètement à quoi ressemble des données du type REG_BINARY, consultez par exemple la valeur
nommée FailureActions sous la clé HKLM\SYSTEM\CurrentControlSet\Services\lmhosts.

REG_DWORD
Le type REG_DWORD stocke un nombre entier sur 4 octets (32 bits). Moults paramètres sont dépeints à
l’échelle de ce format, par exemple des compteurs, intervalles, booléens (valeurs oui/non), masques binaires,
etc. Les valeurs connexes sont DWORD_LITTLE_ENDIAN, où l’octet le moins important se trouve à l’adresse
la plus basse, et REG_DWORD_BIG_ENDIAN, où l’octet le moins important se trouve à l’adresse la plus
haute.

REG_EXPAND_SZ
Les valeurs REG_EXPAND_SZ renferment des chaînes extensibles qui elles-mêmes intègrent des variables
résolues lors de leur utilisation. Les applications peuvent intégrer un jeton spécial dans la chaîne de
caractères, signifiant que la chaîne contient un élément dont le système devra se charger de remplacer le
contenu. Le jeton est une variable dont le nom est délimité par le caractère %. Par exemple, la variable
d’environnement %SystemRoot% est un type REG_EXPAND_SZ représentant le dossier Windows effectif.
Quand le système lit la chaine de caractères, il remplace %SystemRoot% par le chemin d’accès complet au
répertoire d’installation du système d’exploitation.

REG_FULL_RESOURCE_DESCRIPTOR
Le type REG_FULL_RESOURCE_DESCRIPTOR enregistre des informations sur les ressources système
requises par un périphérique particulier. Etant donné sa nature, ce type n’est visible que parmi les sous-clés
de HKLM\HARDWARE.

REG_LINK
Le type REG_LINK instaure dans le registre différents niveaux d’indirection et, à l’instar des liens symboliques
des systèmes de fichier, permet à une clé de pointer de façon transparente vers une autre clé ou valeur.
Quand vous traversez le registre via un lien, la recherche de chemin continue à partir de la cible du lien. Par
exemple, si \Root1\Link à une valeur REG_LINK \Root2\RegKey, et que RegKey contient la valeur RegValue,
alors deux chemins identifient RegValue : \Root1\Link\RegValue et \Root2\RegKey\RegValue. Windows fait
un usage intensif des liens : trois des six clés de premier niveau définies dans le registre sont en réalité

129
Mécanismes de gestion

des liens vers des sous-clés des trois autres clé racine. Les liens sont recréés dynamiquement après chaque
réamorçage du système.

REG_MULTI_SZ
Le type REG_MULTI_SZ est un ensemble de valeurs REG_SZ et correspond à ce titre à une collection de
chaine. Les valeurs qui contiennent des listes ou plusieurs valeurs dans un format que l’utilisateur peut lire
sont généralement enregistrées sous cette forme. Les entrées sont séparées par des espaces, des virgules ou
autre forme de ponctuation - c’est donc aux applications de savoir comment extraire une portion spécifique
d’une valeur REG_MULTI_SZ.

REG_NONE
Très certainement le plus basique des types de données exprimables au sein du registre, REG_NONE a trait
au seul fait qu’un emplacement soit laissé vacant ou est au contraire occupé. Les composants utilisant ce
schéma le font généralement dans l’optique de vérifier la présence d’une clé ou d’une valeur pour adapter
leur comportement au moment de l’exécution.

REG_QWORD
Le type REG_QWORD représente des données par un nombre entier 64 bits. Les valeurs connexes
sont REG_QWORD_LITTLE_ENDIAN (nombre de 64 bits avec octet de poids faible en premier) et
REG_QWORD_BIG_ENDIAN (nombre de 64 bits avec octet de poids fort en premier). Notez que, Windows
étant conçu pour fonctionner sur des architectures informatiques little-endian, les valeurs REG_QWORD et
REG_QWORD_LITTLE_ENDIAN sont équivalentes.

REG_RESOURCE_LIST
Le type REG_RESOURCE_LIST stocke des informations sur les ressources utilisée par un pilote de
périphérique matériel ou l’un des périphériques physiques qu’il contrôle. Ces données sont détectées et
écrites par le système dans l’arborescence HKLM\HARDWARE\ResourceMap.

REG_SZ
Le type REG_SZ correspond à une chaine de caractères de longueur variable. Les valeurs REG_SZ renferment
généralement des messages, des noms de fichier, des données de chemin, etc.

Structure du registre
Si les informations publiées via le Registre sont de forme et de nature diverses (un système comme Windows
est entouré d’un nombre important de logiciels et matériels, donc a fortiori de très nombreux paramètres
de configuration), il est possible de dresser la cartographie dudit lieu en fonction des données qui y sont
stockées.

Clés volatiles
Certaines clés et valeurs du Registre sont volatiles, c’est-à-dire qu’elles peuvent disparaitre à tout moment,
et ne perdurent surtout pas au-delà de l’extinction de la machine. Par exemple, aucune des données que
renferme la clé HKLM\HARDWARE n’ont d’existence sur le disque, mais uniquement en mémoire. Les clés
volatiles sont pratiques pour les données qu’il n’est pas nécessaire de conserver entre deux démarrages.

Clés racines
Le registre est organisé à la façon d’une structure arborescente à six niveaux, dites clés racines (il est
impossible d’en ajouter ou supprimer), montrées au tableau suivant.

130
Mécanismes de gestion

Tableau 4.3. Clés racine

Clé racine Description


HKEY_CLASSES_ROOT Contient les données d’associations de fichier et de déclarations d’objet
COM
HKEY_CURRENT_CONFIG Contient des données relatives au le profil matériel courant
HKEY_CURRENT_USER Contient les données associées à l’utilisateur courant
HKEY_LOCAL_MACHINE Contient des informations de configuration spécifiques à l’ordinateur
HKEY_PERFORMANCE_DATA Contient des données concernant les performances.
HKEY_USERS Contient les données concernant les comptes/profils utilisateur

Les noms des clés racine commencent par la lettre H, car ils représentent des handles (H) Windows vers les
clés (KEY). Pour des raisons de concision, les noms des clés racine sont souvent montrés sous une forme
plus brève, par exemple HKCU pour HKEY_CURRENT_USER, HKLM pour HKEY_LOCAL_MACHINE, et ainsi
de suite.

Les sections qui suivent apportent plus de précisions sur chacune des clés racine.

HKEY_CURRENT_USER
La ruche HKEY_USERS contient une clé, enregistrée sous forme de SID, pour chaque compte d’utilisateur
sur l’ordinateur. Quand un utilisateur ouvre une session, le système repère le SID du compte auquel le
profil correspond et charge depuis HKEY_USERS vers la branche HKEY_CURRENT_USER la portion du profil
d’utilisateur.

HKEY_CURRENT_USER
La clé racine HKEY_CURRENT_USER contient des données relatives aux préférences et à la configuration
logicielle de l’utilisateur actif. Les informations dans cette clé sont créées pendant le processus d’ouverture
de session, ce à partir du profil de l’utilisateur ayant ouvert la session courante, profil situé sur le disque dans
\Users\<username>\Ntuser.dat.

Chaque fois qu’un profil utilisateur est chargé (par exemple, lors d’une ouverture de session ou lors du
démarrage d’un service exécuté sous le contexte d’un certain utilisateur), HKEY_CURRENT_USER est créé
sous forme de lien vers la clé associée à l’utilisateur sous HKEY_USERS. (Pas étonnant, donc, que toutes les
données trouvées dans la clé HKEY_CURRENT_USER soient par défaut une copie de la sous-clé HKEY_USERS
\nom d’utilisateur, où nom d’utilisateur est le nom de l’utilisateur actif.) Le tableau suivant énumère quelques-
unes des sous-clés de HKEY_CURRENT_USER.

Tableau 4.4. Sous-clés de HKEY_CURRENT_USER

Sous-clé Description
AppEvents Associations son/événement (par exemple, quand un message d’erreur
s’affiche).
Console Paramètres de fenêtre d’invite de commandes (hauteur, largeur, couleurs,
etc.­)
Control Panel Paramètres concernant l’économiseur d’écran, l’aspect du bureau, le
clavier et la souris, plus quelques paramètres concernant l’accessibilité et
l’internationalisation/régionalisation
Environnement Variables d’environnement
Keyboard Layout Paramètres concernant la disposition du clavier (par exemple, US ou FR)
Network Mappages et paramètres des lecteurs réseau

131
Mécanismes de gestion

Sous-clé Description
Printers Paramètres concernant les connexions aux imprimantes
RemoteAccess Adresses et profils pour l’accès réseau à distance
Software Préférences logicielles spécifiques à l’utilisateur

HKEY_LOCAL_MACHINE
HKEY_LOCAL_MACHINE (HKLM) est une sous arborescence du registre où sont définit l’ensemble des
paramètres associés à la configuration de l’environnement local. La clé racine englobe toutes les sous clés de
configuration de niveau système : HARDWARE (processeur, carte mère…), SOFTWARE (options des logiciels
installés), SYSTEM (dernière bonne configuration connue), SECURITY (Sam et stratégies de sécurité locales),
et BCD (données d’amorçage).
C:\>reg QUERY HKEY_LOCAL_MACHINE

HKEY_LOCAL_MACHINE\BCD00000000
HKEY_LOCAL_MACHINE\HARDWARE
HKEY_LOCAL_MACHINE\SAM
HKEY_LOCAL_MACHINE\SECURITY
HKEY_LOCAL_MACHINE\SOFTWARE
HKEY_LOCAL_MACHINE\SYSTEM

HKLM\BCD contient les données de configuration définies pour l’amorçage du système, lesquelles
suppléent au fichier boot.ini des anciennes versions de Windows. Plus proche de l’époque actuelle, les
fichiers de données de configuration de démarrage (BCD, Boot Configuration Data) fournissent un répertoire
d’informations sur les applications de démarrage et les paramètres de ces dernières. Les magasins BCD
remplissent essentiellement les mêmes fonctions que leurs ainés (les fichiers ini donc), mais offrent un éventail
d’options de démarrage plus large et améliorent la prise en charge de l’écriture de script.

HKLM\SAM contient les informations sur les comptes et groupes locaux, par exemple les mots de passe
utilisateur, les associations de groupe et de domaine. HKLM\SECURITY contient les stratégies de sécurité.

HKLM\SECURITY
HKLM\SECURITY restitue de façon tangible bon nombre des aspects de Windows liés à la sécurité. Les
informations stockées à cet égard incluent les paramètres de stratégie, les valeurs de sécurité par défaut,
les secrets partagés par les serveurs, les informations de compte, telles que les informations d’identification
mises en cache d’ouverture de session, et bien d’autres informations apparentées à la protection de
l’ordinateur. Une copie de la base de données SAM est également enregistrée à cet endroit, même s’il est
protégé.

Par défaut, les mécanismes de protection en oeuvre concernant HKLM\SECURITY se montrent


particulièrement restrictifs, cela en considération de la nature critique des informations que ladite clé
héberge, et sont en l’occurence configurés pour accorder l’accès uniquement au compte système local. Vous
pouvez néanmoins modifier le descripteur de sécurité pour permettre l’accès en lecture aux administrateurs,
ou éventuellement utiliser PsExec pour exécuter Regedit (ou n’importe quel autre utilitaire dévolu à la lecture
du Registre) dans le contexte du compte système local.

HKLM\HARDWARE
HKLM\HARDWARE contient les descriptions des matériels de l’ordinateur et toutes les associations
périphérique-à-pilote. Elle permet ce faisant à Windows et à ses pilotes de périphériques d’enregistrer et
de partager les informations sur les équipements présents au démarrage du système, ou reconnus par la
suite lors d’une procédure Plug and Play.

De nombreuses commandes d’administration permettant l’examen de données relatives au matériel, dont


l’utilitaire Gestionnaire de périphériques et la boite de dialogue Système, prennent leur source à partir de
valeurs appropriées dans la clé HKLM\HARDWARE.

132
Mécanismes de gestion

HKLM\SOFTWARE
HKLM\SOFTWARE fait office de racine de stockage des paramètres globaux des composants et applications
Windows, renfermant de la sorte autant des données de configuration de niveau système (mais qui ne sont
pas requises pour l’amorçage) que des paramètres de niveau application.

Une large majorité des logiciels, tierce partie ou livré avec Windows, enregistre sous HKLM\SOFTWARE
leurs paramètres, par exemple les chemins des fichiers et répertoires, les informations de licence et
date d’expiration, etc. Les paramètres présents à cet endroit s’appliquent à tous les utilisateurs. D’autres
paramètres spécifiques à l’utilisateur se trouveront dans les clés HKEY_USERS ou HKEY_CURRENT_USER.

HKLM\SYSTEM
HKLM\SYSTEM contient les options de configuration requises lors de l’amorçage du système, par exemple
quels sont les pilotes à charger et les services à démarrer.

HKLM\SYSTEM\CurrentControlSet
Une fois terminée la procédure d’amorçage de l’ordinateur, Windows met à jour le Registre afin qu’il reflète
les derniers composants et contrôles utilisés pour démarrer correctement. La clé CurrentControlSet fait pour
l’occasion référence à l’ensemble de contrôles actuellement en vigueur sur la plateforme (sous entendu
l’ensemble le plus récent qui ai permis de démarrer). Dans un contexte parallèle, la sous-clé HKLM\SYSTEM
renferme un nombre variable de clés ControlSetXXX, qui chacune représente un ensemble de contrôles
ayant existé, indépendamment du succès ou de l’échec de l’entreprise auquel il donnait lieu.

Visualisation des jeux de contrôle dans HKLM\SYSTEM. 


C:\>reg query HKLM\SYSTEM /f ControlSet

HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet
Fin de la recherche : 2 correspondance(s) trouvée(s).

C:\>reg query HKLM\SYSTEM\ControlSet001

HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Enum
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Hardware Profiles
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Policies
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Software

CurrentControlSet renferme plusieurs sous-clés :

■ Control Contient des informations de contrôle pour les services et les outils du système.

■ Enum Contient une entrée pour chaque périphérique physique ou logique détectable par le système.
Certaines de ces informations sont accessibles depuis le gestionnaire de périphériques de Windows.

■ Harware Profiles Contient une entrée par profil matériel défini sur la machine. De la même façon que le
système de numérotation de l’arborescence HKLM\SYSTEM, chaque profil possède un numéro, le premier
étant 0001. HKLM\SYSTEM\Harware Profiles\Current pointe toujours vers le profil sélectionné lors de
l’amorçage du système. Les informations relatives aux profils matériels peuvent être configurés depuis
Panneau de configuration / onglet Système / Matériel / Profils Matériels.

■ Services Contient une sous-clé par service installé. Ces sous-clés incluent les informations de configuration
nécessaires aux services Windows.

HKEY_PERFORMANCE_DATA
HKEY_PERFORMANCE_DATA est utilisée de sorte à accéder aux valeurs des compteurs de performance
sous Windows, ce qui donne par ailleurs une dimension toute nouvelle au relevé de ces informations. Déjà

133
Mécanismes de gestion

spéciale par nature, HKEY_PERFORMANCE_DATA l’est encore plus du fait de n’être accessible que du point
de vue de la programmation, c’est à dire par l’intermédiaire des fonctions de l’API Windows (Kernel32.dll)
ou de l’API Performance Data Helper (Pdh.dll).

Les informations que véhicule HKEY_PERFORMANCE_DATA ne sont pas en réalité stockés dans le registre -
et n’ont de toutes les façons pas vocation à l’être. Il faut en l’occurence imaginer une telle clé non comme un
intermédiaire direct vers les valeurs des compteurs de performances, mais plutôt comme une rampe d’accès
vers divers fournisseurs de données de performance.

HKEY_CURRENT_CONFIG
HKEY_CURRENT_CONFIG est un lien vers le profil matériel courant, stocké sous HKLM\SYSTEM
\CurrentControlSet\Hardware Profiles\Current. Les profils matériels permettent de décrire quelles pièces
de matériel sont activés ou désactivés quand le système est démarré sous un profil donné. Ils donnent
ainsi la possibilité à l’administrateur d’adapter les paramètres des pilotes du système aux variations de
l’environnement matériel de l’ordinateur. Par exemple, sur un ordinateur portable avec un plug and play
compatible station d’accueil, deux profils pourraient être créés et chargés automatiquement selon les
besoins : un pour quand l’ordinateur est amarré à la station, un autre pour quand il ne l’est pas. Si plusieurs
profils matériels sont connus du système, ce dernier affiche au démarrage un menu spécifique, attendant le
choix d’une configuration appropriée à charger.

HKEY_CLASSES_ROOT
HKEY_CLASSES_ROOT renferme principalement trois sortes d’information : des associations d’extension de
fichier, la vue virtualisée du Registre, et des détails de configuration concernant les objets COM.

Il existe sous HKEY_CLASSES_ROOT une clé pour toute extension de nom de fichier connue. La plupart des
clés contiennent une valeur REG_SZ qui pointe vers une autre clé de HKCR incluant les données d’association
concernant la classe de fichiers que cette extension représente. Ainsi, par exemple, HKCR\.doc pointe
vers des informations sur les fichiers Microsoft Word stockées dans Word.Document.8. S’ajoute à cela, les
propriétés, la commande associée à un double clic et les commandes disponibles dans le menu contextuel
du dit document.

Les données sous HKEY_CLASSES_ROOT proviennent de deux sources (la branche en elle-même est en
quelque sorte le produit de ce couple) :

■ Les données de déclaration de classe de niveau utilisateur sous HKCU\SOFTWARE\Classes (correspondant


au fichier \Users\<username>\AppData\Local\Microsoft\Windows\Usrclass.dat)

■ Les données de déclaration de classe de niveau système sous HKLM\SOFTWARE\Classes.

La raison pour laquelle il existe une séparation entre données de déclaration de classe de niveau utilisateur
et données de déclaration de classe de niveau système vient de ce qu’on veut que les profils itinérants
puissent contenir ces personnalisations. En outre, une telle manière de procéder referme d’emblée une
potentielle brèche de sécurité : un utilisateur non privilégié ne peut ni modifier ni supprimer des clés dans la
version HKEY_CLASSES_ROOT de niveau système, et ne peut donc pas affecter le fonctionnement global
des applications.

Visualisation et modification du Registre


S’il reste communément admis que la manipulation du registre ne devrait pas s’effectuer de manière directe
(les paramètres des applications et du système susceptibles de modifications devraient légitimement avoir
une interface utilisateur associée rendant visible les possibilités les concernant), certains paramètres du
système n’ont aucun intermédiaire pour les restituer, raison pour laquelle Windows offre plusieurs outils
permettant de visualiser et modifier le registre.

134
Mécanismes de gestion

■ Éditeur du Registre

■ Reg.exe

■ Windows PowerShell

Editeur du Registre
L’Éditeur du Registre est composé de deux parties  : un volet de navigation à gauche et un volet
d’informations à droite. Le volet de navigation contient la liste hiérarchique des ruches de Registre
correspondant au Registre d’un ordinateur cible (une riche est un groupe de clés, de sous-clés et de valeurs
dans le Registre). Quand une ruche de Registre est sélectionnée dans le volet de navigation, toutes les
entrées du Registre ajoutées pour cette ruche sont affichées dans le volet de droite.

Manipuler le registre via Windows PowerShell


Conçu spécialement pour l’administration du système, dont une des attributions courantes consiste à
surveiller voire modifier le Registre, Windows PowerShell intègre en la matière diverses commandes et
fonctionnalités. En utilisant le fournisseur Registry de Windows PowerShell, vous pouvez faire des recherches
entre les informations du Registre, créer de nouvelles clés, supprimer des clés existantes et modifier des
listes de valeurs et de contrôles d’accès (ACL) depuis Windows PowerShell.

Afin de permettre l’accès aux informations du Registre, externes à l’environnement du Shell, le fournisseur
Registry maintient un espace de noms hiérarchique organisé à partir des clés et sous-clés de la base de
données du Registre. Ces données, des éléments sur les lecteurs Windows PowerShell, sont rendues visibles
comme s’il s’agissait d’une structure de fichiers de disque ; leur utilisation est en conséquence très semblable
à celle des fichiers et dossiers. Les valeurs et données, considérées dans Powershell comme des propriétés
des éléments (et non des éléments distincts), ne sont pas des composants de cette hiérarchie.

Le fournisseur Registry prend en charge pour l’interaction avec les clés de Registre tous les applets de
commande Item (- Item), telles que Get-Item, Copy-Item et Rename-Item. Utilisez les applets de
commande Item lors de l’utilisation de clés et sous-clés de Registre. Par exemple, Vous pouvez afficher
tous les éléments situés directement dans une clé de Registre en utilisant Get-ChildItem. Le fournisseur
Registry prend également en charge les applets de commande ItemProperty (- ItemProperty). Utilisez
les applets de commande ItemProperty lors de l’utilisation de valeurs et données de Registre. Par exemple,
L’applet de commande Remove-ItemProperty supprime une propriété et sa valeur d’un élément. Vous
pouvez l’utiliser pour supprimer des valeurs de Registre et les données qu’elles contiennent.

Fichiers d’inscription
Établis comme un moyen commode de gérer le registre autrement que par l’intermédiaire d’utilitaires
dédiés, les fichiers d’inscription (extension .reg) sont des fichiers à base de texte (donc facilement lisibles par
l’homme) qui permettent l’importation et l’exportation de constituants (clés, sous-clés et valeurs) depuis et
vers la base de registre. Lorsque vous exécutez un tel fichier, son contenu est fusionné dans le Registre local.
Les administrateurs peuvent du même coup utiliser ces fichiers pour distribuer à distance des modifications
du Registre sur plusieurs ordinateurs Windows.

Vous pouvez envoyer un fichier d’inscription à des utilisateurs dans un message électronique, placer un
fichier .reg sur un partage réseau et demander aux utilisateurs du partage réseau de l’exécuter, ou encore
ajouter une commande aux scripts d’ouverture de session des utilisateurs pour importer automatiquement
le fichier .reg lorsqu’ils se connectent.

Lorsque les utilisateurs exécutent le fichier .reg, ils reçoivent les messages suivants : "Éditeur du Registre /
Voulez-vous vraiment ajouter les informations contenues dans chemin_fichier_.reg au Registre  ?". Si
l’utilisateur clique sur Oui, il reçoit le message suivant  : "Éditeur du Registre / Les informations de

135
Mécanismes de gestion

chemin_fichier_.reg ont été inscrites dans le Registre.". Regedit.exe prend en charge un commutateur de
ligne de commande /s pour ne pas afficher ces messages. Par exemple, pour exécuter silencieusement le
fichier .reg (avec le commutateur /s) à partir d’un fichier de commandes de script de connexion, utilisez la
syntaxe chemin_fichier_.reg.

Utilitaire Reg (Reg.exe)


L’utilitaire Reg (Reg.exe) permet de visualiser, de modifier ou d’ajouter des entrées dans le Registre à partir
de l’invite de commandes. Aussi performant que n’importe lequel de ses homologues en mode graphique,
Reg est essentiellement destinée aux administrateurs système, lesquels l’utilisent surtout dans des fichiers
de commandes appliquant de manière successive et répétitive des modifications au Registre. L’emploi de la
commande Reg reste néanmoins un choix stratégique dans la plupart des scénarios et pour de nombreux
utilisateurs.

Comme tant autres utilitaires sollicités depuis l’invite de commandes, l’utilitaire Reg possède sa propre série
de sous-commandes. Les options disponibles sont nombreuses et se passent en tant que paramètres à
l’exécutable. Voici la syntaxe générale de la commande Reg :
reg action [options]

Où Reg correspond au nom de l’exécutable Reg, action à la commande de registre à effectuer et options
à la liste des paramètres spécifiques à la commande. Les principales commandes reconnues par Reg sont
listées dans le tableau suivant.

Tableau 4.5. Commandes Reg

Commande Action
Add Ajoute une nouvelle sous-clé ou entrée au Registre
Compare Compare les valeurs de deux sous-clés ou de deux
entrées
Copy Copie les informations du Registre à un nouvel
emplacement d’un Registre local ou réseau
Delete Supprime des informations du Registre
Export Crée une copie des sous-clés ou valeurs spécifiées
dans un fichier. Ce fichier permet de transférer les
données du Registre vers d’autres ordinateurs à
l’aide de la commande Import.
Import Importe un fichier registre et crée et modifie les clés
du fichier dans le Registre local.
Load Permet de déplacer les données du registre à un
nouvel emplacement.
Query Affiche toutes les informations du Registre sous la
clé spécifiée.
Restore Restaure les informations du Registre à partir d’un
fichier crée avec la commande Save.
Save Enregistre les informations du Registre dans un
fichier. Cela est utile pour effectuer une sauvegarde
avant de modifier une clé.
Unload Supprime les données du Registre ajoutées avec la
commande Load.

Plusieurs remarques additionnelles concernant la syntaxe de Reg.exe :

136
Mécanismes de gestion

■ Reg.exe exige que les noms des clés des racines figurent sous forme abrégée. Saisissez HKLM, par
exemple, et non HKEY_LOCAL_MACHINE

■ Dans l’éventualité où un nom de clé ou de valeur comporte des espaces, il est impératif de le faire
apparaitre entre guillemets.

■ Si vous introduisez une commande Reg.exe dans un programme batch et qu’elle renferme une variable
d’environnement, il est impératif de placer le nom de la variable entre deux paires de symboles de
pourcentage (et non un seul). Autrement, l’interprète de commandes développe le nom de la variable
avant de la passer à Reg.exe.

Registre et sécurité
Compte tenu du rôle clé joué par la base de registre au sein de la configuration du système d’exploitation,
il est facile de concevoir l’importance de conserver, rétablir, et garantir sa sécurité.

Regedit permet d’ajuster la sécurité des clés du Registre via la commande Autorisations du menu Edition.
Les autorisations des clés sont identiques à celles des fichiers.

Tableau 4.6. Autorisations du Registre

Autorisation Implication de cette autorisation


Contrôle total L’utilisateur peut ouvrir, modifier et prendre
possession d’une clé.
Requête sur une valeur L’utilisateur peut interroger la valeur que renferme
une clé.
Définir la valeur L’utilisateur peut créer de nouvelles valeurs sous
une clé ou remplacer une valeur existante.
Créer une sous-clé L’utilisateur peur créer une nouvelle sous-clé sous
une clé
Énumérer les sous-clés L’utilisateur a accès à la liste de toutes les sous-clés
d’une clé particulière (dans la perspective NTFS,
cette possibilité à traverser un répertoire).
Avertir L’utilisateur peut enregistrer une fonction qui se
déclenche lorsque la valeur sélectionnée a fait
l’objet de modifications.
Créer une liaison L’utilisateur peut créer une liaison vers une clé.
Supprimer L’utilisateur peut créer une clé ou une valeur.
Accès en écriture à la liste de contrôle d’accès L’utilisateur dispose d’un accès en écriture aux
contrôles d’accès de la clé sélectionnée.
Accès du propriétaire L’utilisateur peut prendre possession de la clé
sélectionnée.
Contrôle en lecture L’utilisateur peut lire la liste de contrôle d’accès
discrétionnaire (DACL) de la clé.

Par défaut, le profil de sécurité attribué à certains composants sensibles de la base de registre empêche
l’accès par un compte autre que le compte système local. Citons par exemple les clés HKLM\SECURITY
et HKLM\SAM, qui contiennent pas moins que les politiques de sécurité du système, les affectations
de droits d’usagers, et les mots de passe. Un moyen rudimentaire d’accéder à ces données consiste
simplement à réinitialiser leur sécurité, ce qui en plus de n’être pas conforme aux bonnes pratiques en matière
d’administration, pourrait avoir des résultats malencontreux sur la sécurité d’ensemble du système. Une autre

137
Mécanismes de gestion

façon consiste à exécuter l’utilitaire Regedit.exe, ou tout autre outil offrant la possibilité d’éditer le registre,
sous le compte système local. L’utilitaire PsExec prend en charge une option permettant de procéder ainsi.

Callbacks de registre
Windows donne aux composants de l’exécutif, pilotes et autres codes système l’occasion de surveiller les
activités se déroulant dans le registre, ce par l’intermédiaire de routines de rappel (callbacks) spéciales. Un
thread mode noyau emploie la fonction CmRegisterCallbackEx en vue de déclarer auprès du gestionnaire
de configuration un point d’entrée RegistryCallback, que Windows exécute chaque fois qu’une opération
liée au registre a lieu (comprendre chaque fois qu’un service système apparenté au registre est sollicité). Ce
genre de fonctionnalités s’illustre, par exemple, dans divers produits de sécurité, qui examinent les données
du registre afin de détecter d’éventuelles malveillances.

Registre et droits d’accès


Tableau 4.7. Droits d’accès concernant clés et valeurs de registre

Constante Valeur Description


KEY_QUERY_VALUE 0x0001 Requis pour interroger les valeurs
présentes dans une clé. Voir
service NtEnumerateValueKey,
NtEnumerateKey
(KeyInformationClass =
KeyNameInformation),
NtQueryValueKey.
KEY_ENUMERATE_SUB_KEYS 0x0008 Requis pour énumérer des sous--
clés.
KEY_NOTIFY 0x0010 Requis pour effectuer un audit
(recevoir des notifications de
modification) d’un clé.
KEY_SET_VALUE 0x0002 Requis pour créer, supprimer ou
modifier une valeur. Voir service
NtDeleteValueKey.
KEY_CREATE_SUB_KEY 0x0004 Requis pour créer une sous-clé.
KEY_CREATE_LINK 0x0020 Requis pour créer un lien
symbolique.

Tableau 4.8. Mappage générique des droits d’accès au registre

Droit générique Signification


KEY_ALL_ACCESS STANDARD_RIGHTS_ALL
KEY_QUERY_VALUE
KEY_SET_VALUE
KEY_CREATE_SUB_KEY
KEY_ENUMERATE_SUB_KEYS
KEY_NOTIFY
KEY_CREATE_LINK
KEY_EXECUTE KEY_READ
KEY_READ STANDARD_RIGHTS_READ
KEY_QUERY_VALUE

138
Mécanismes de gestion

Droit générique Signification


KEY_ENUMERATE_SUB_KEYS
KEY_NOTIFY.
KEY_WRITE STANDARD_RIGHTS_WRITE
KEY_SET_VALUE
KEY_CREATE_SUB_KEY

NtQueryKey
Tableau 4.9. KEY_INFORMATION_CLASS

ID Classe Type de données associé


0x0000 KeyBasicInformation KEY_BASIC_INFORMATION
0x0001 KeyNodeInformation KEY_NODE_INFORMATION
0x0002 KeyFullInformation KEY_FULL_INFORMATION
0x0003 KeyNameInformation KEY_NAME_INFORMATION
typedef struct _KEY_BASIC_INFORMATION {
LARGE_INTEGER LastWriteTime;
ULONG TitleIndex;
ULONG NameLength;
WCHAR Name[1];
} KEY_BASIC_INFORMATION, *PKEY_BASIC_INFORMATION;

typedef struct _KEY_CACHED_INFORMATION {


LARGE_INTEGER LastWriteTime;
ULONG TitleIndex;
ULONG SubKeys;
ULONG MaxNameLen;
ULONG Values;
ULONG MaxValueNameLen;
ULONG MaxValueDataLen;
ULONG NameLength;
} KEY_CACHED_INFORMATION, *PKEY_CACHED_INFORMATION;

typedef struct _KEY_FULL_INFORMATION {


LARGE_INTEGER LastWriteTime;
ULONG TitleIndex;
ULONG ClassOffset;
ULONG ClassLength;
ULONG SubKeys;
ULONG MaxNameLen;
ULONG MaxClassLen;
ULONG Values;
ULONG MaxValueNameLen;
ULONG MaxValueDataLen;
WCHAR Class[1];
} KEY_FULL_INFORMATION, *PKEY_FULL_INFORMATION;

typedef struct _KEY_NAME_INFORMATION {


ULONG NameLength;
WCHAR Name[1];
} KEY_NAME_INFORMATION, *PKEY_NAME_INFORMATION;

typedef struct _KEY_NODE_INFORMATION {


LARGE_INTEGER LastWriteTime;
ULONG TitleIndex;
ULONG ClassOffset;
ULONG ClassLength;
ULONG NameLength;
WCHAR Name[1];
} KEY_NODE_INFORMATION, *PKEY_NODE_INFORMATION;

typedef struct _KEY_VALUE_BASIC_INFORMATION {


ULONG TitleIndex;
ULONG Type;
ULONG NameLength;
WCHAR Name[1];
} KEY_VALUE_BASIC_INFORMATION, *PKEY_VALUE_BASIC_INFORMATION;

139
Mécanismes de gestion

typedef struct _KEY_VIRTUALIZATION_INFORMATION {


ULONG VirtualizationCandidate : 1;
ULONG VirtualizationEnabled : 1;
ULONG VirtualTarget : 1;
ULONG VirtualStore : 1;
ULONG VirtualSource : 1;
ULONG Reserved : 27;
} KEY_VIRTUALIZATION_INFORMATION, *PKEY_VIRTUALIZATION_INFORMATION;

Le champ NameLength précise la taille, en octets, de la chaine de caractères véhiculée par le tableau Name,
représentant le nom de clé dans le registre. Le champ Name constitue un tableau de caractères larges (dont
la taille est indiquée par l’attribut NameLength) qui renferme le nom de la clé.

Services
Presque tous les systèmes d’exploitation disposent d’un mécanisme pensé pour des tâches non attachées
explicitement à l’utilisateur interactif. Sous Windows, ce genre de processus porte le nom de service ou
service Windows. Analogues des "démons" UNIX, qui fonctionnent en arrière-plan plutôt que sous le
contrôle direct d’un utilisateur, les services Windows sont des programmes qui se chargent automatiquement
dans le cadre du processus de démarrage d’une application ou du processus de démarrage de système pour
prendre en charge les différentes tâches nécessaires au système d’exploitation.

Les fonctionnalités implémentées au niveau service, souvent orientés réseau et dont la durée d’exécution
est généralement longue, rendent les services parfaitement adaptés à une utilisation sur un serveur. Ils sont
aussi particulièrement utiles lorsqu’une fonctionnalité du système doit n’être pas tributaire d’une identité
numérique directe (utilisateurs comme administrateurs). Les exemples de composants Windows existants
sous forme de services incluent le spouleur d’impression, le journal des événements et le planificateur de
tâches.

Les services Windows sont constitués de trois composants : une application service, un programme de
contrôle de service (SCP), et le gestionnaire de contrôle de service (SCM). Dans cette section, nous
commencerons par d’écrire les applications et le fonctionnement du SCM. Nous expliquerons ensuite
comment se fait le démarrage des services automatiques lors de l’amorçage du système. Nous verrons aussi
les mesures que prend le SMC lorsqu’un service échoue lors de son démarrage et la façon dont le SMC
arrête les services.

Le tableau qui suit énumère les fonctions Windows utilisées dans le contexte des services.
Tableau 4.10. Fonctions de gestion de services

Fonction Description
ChangeServiceConfig/2 Modifie la configuration d’un service
ControlService/Ex Envoie un code de contrôle à un service
CreateService Crée un service (l’ajoute au Registre)
DeleteService Supprime un service (du Registre)
EnumDependentServices Énumère les dépendances de service
EnumServicesStatusEx Énumère les services sur la base d’un niveau
d’information
ControlService/Ex Envoie une requête de contrôle à un service
GetServiceDisplayName Obtient le nom d’affichage d’un service
GetServiceKeyName Obtient le nom de la clé de service d’un service
OpenSCManager Établit une connexion au gestionnaire de contrôle
de service sur l’ordinateur spécifié
QueryServiceConfig Retourne les paramètres de configuration d’un
service

140
Mécanismes de gestion

Fonction Description
SetServiceObjectSecurity Modifie la sécurité d’un service
StartService Démarre un service

Applications service
Une application service est un ensemble logiciel dont au moins un composant fonctionne en tant que service
Windows.

Quand vous installez une application qui inclut un service, le programme d’installation de cette application
a pour obligation préalable de déclarer ledit service auprès du système, chose qu’il accomplit en sollicitant
CreateService, laquelle fonction a dans ce contexte pour rôle de partager au SCM l’ensemble des
informations nécessaires (pas moins de 13 paramètres) à une future prise en charge. Comme tant d’autres
des fonctions de gestion de services, CreateService est implémentée dans Advapi32.dll, DLL qui recueille
en réalité toutes les API coté client du SCM.

Tout utilisateur qui interagit avec un service le fait par non pas directement mais par le biais d’un programme
de contrôle de service (SCP). Windows fournit des SCP intégrés dotés de fonctionnalités génériques de
démarrage, d’arrêt, de suspension et de reprise. Certaines applications service incluent toutefois leurs
propres SCP, cela essentiellement en vue de pouvoir instaurer des dispositions spécifiques (des paramètres
de configuration particuliers) au service concerné.

Lors de la mise en avant d’un service par un programme d’installation, il y a envoi d’un message au SCM de
la machine appelée à accueillir le service (l’ordinateur local dans une large majorité des cas). Le SCM crée à
cette occasion une clé de registre pour le service sous HKLM\SYSTEM\CurrentControlSet\Services.

Le SCM enregistre chacune des caractéristiques relatives un service ou à un pilote par l’intermédiaire de la
clé HKLM\System\CurrentControlSet\Services. (Une caractéristique particulière ne s’applique pas forcément
à tous les types de service, ni non plus à tous les types de pilote.) Les paramètres admissibles en la matière
sont les suivants :

■ Type de démarrage (Start) Indique si le démarrage de ce service est effectué automatiquement, défini de
manière manuelle ou s’il est désactivé. Les services automatiques sont démarrés à l’amorçage. Les services
manuels sont démarrés à la demande par les utilisateurs ou par d’autres services. Les services désactivés
ne peuvent être démarrés tant qu’ils sont en l’état.

■ Niveau de contrôle d’erreur (ErrorControl) Oriente la manière dont le système sanctionne avec plus
ou moins de sévérité les ratés et dysfonctionnements émanant d’un service ou d’un pilote : ignorer le
problème, afficher un avertissement, faire s’effondrer et réamorçer le système avec la dernière bonne
configuration connue, etc. Pour plus d’informations, consultez la section Erreurs des services.

■ Type de composant (Type) Type auquel se rapporte un composant. Comme les services et les pilotes
de périphériques Windows stockent tous deux leurs paramètres de configuration sous la même clé de
registre, il est de ce fait nécessaire de faire une distinction entre les deux. Voir tableau plus loin.

■ Nom de groupe (Group) Désigne le groupe auquel appartient le pilote ou le service. Cela permet
à des pilotes ou services apparentés de démarrer conjointement (par exemple, des pilotes de
système de fichiers). L’entrée de registre List de la sous-clé HKLM\SYSTEM\CurrentControlSet\Control
\ServiceGroupOrder spécifie l’ordre de démarrage du groupe.

■ Numéro de tag (Tag) Désigne l’ordre de démarrage d’un pilote au sein d’un groupe de pilotes. Ce
paramètre ne concerne pas les services.

■ Dépendance de service (DependOnService) Enumère les services spécifiques qui doivent être chargés
avant le chargement de ce service. Ce paramètre ne s’applique pas aux pilotes autres que ceux ayant le
type de démarrage SERVICE_AUTO_START.

141
Mécanismes de gestion

■ Dépendance de groupes (DependOnGroup) Au moins un élément de ce groupe doit démarrer avant


le chargement de ce service.

■ Chemin de fichier exécutable (ImagePath) Chemin du fichier exécutable sous-jacent au service ou


pilote. Dans l’éventualité où ImagePath n’est pas spécifié, le gestionnaire d’E/S recherche les pilotes dans
\Windows\System32\Drivers et le SCM dans les différents emplacements du système de fichier auxquels
conduit la variable PATH.

■ Compte de service (ObjectName) Nom du compte sous lequel le service est exécuté. Si ObjectName
n’est pas spécifié, le système emploie le compte système local (LocalSystem). Ce paramètre ne s’applique
pas aux pilotes.

■ Nom de service (DisplayName) Nom par lequel se fait connaitre le service auprès des différents logiciels,
par exemple l’application Services. Dans l’éventualité où aucun nom n’a été donné, c’est le nom de la clé
de registre renfermant les informations du service qui est utilisé.

■ Description de service (Description) Contient une brève description textuelle du service et de son but
(32767 octets maximum)

■ Actions en cas d’échec (FailureActions) Description des actions que doit exercer le SCM dans
l’éventualité où le processus service se termine de manière inattendue ; plusieurs cas de figure ici : le
redémarrage du processus service, l’exécution d’un programme spécifié et le réamorçage du système. Ce
paramètre ne concerne pas les pilotes.

■ Commande de processus (FailureCommand) Le SCM ne s’appuie sur cette valeur que si FailureActions a
enjoint le SCM à exécuter un programme spécifique en cas d’échec du service. Ce paramètre ne concerne
pas les pilotes.

■ Descripteur de sécurité (Security) Contient la descripteur de sécurité qui définit qui a accès à l’objet
service créé en interne par le SCM.

Type de services
Chaque service a parmi ses propriétés définitoires un certain nombre d’attributs qui le caractérisent auprès
du SCM, par exemple si le service est exécuté dans un seul processus ou au contraire partage un processus
avec d’autres composants, s’il peut interagir avec le bureau actif, etc. En interne, toutes ces informations sont
regroupées sous la valeur Type de la clé associée au service. Le tableau suivant décrit les valeurs susceptibles
d’apparaitre à ce niveau.
Tableau 4.11. Valeurs de registre Type

Constante Valeur Description


SERVICE_ADAPTER 0x00000004 Spécifie un adaptateur. Cet
attribut est désormais obsolète.
SERVICE_FILE_SYSTEM_DRIVER 0x00000002 Spécifie un pilote de système de
fichiers mode noyau.
SERVICE_KERNEL_DRIVER 0x00000001 Spécifie un pilote de
périphérique.
SERVICE_RECOGNIZER_DRIVER 0x00000008 Spécifie un pilote reconnaisseur
de système de fichiers.
SERVICE_WIN32_OWN_- 0x00000010 Spécifie un service qui s’exécute
PROCESS dans un processus qui héberge un
seul service
SERVICE_WIN32_SHARE_- 0x00000020 Spécifie un service qui s’exécute
PROCESS dans un processus qui héberge
plusieurs services.

142
Mécanismes de gestion

Constante Valeur Description


SERVICE_INTERACTIVE_- 0x00000100 Spécifie un service autorisé à
PROCESS afficher des fenêtres sur la console
et à recevoir des saisies de la part
de l’utilisateur.

Chaque service peut éventuellement avoir une description qui le caractérise auprès des autres composants
du système, lui permettant de la sorte de mettre en avant son but ou les diverses tâches qu’il accomplit.
Pour associer une description à un service, sollicitez ChangeServiceConfig2 en lui spécifiant la valeur
SERVICE_CONFIG_DESCRIPTION. Pour voir la description qui accompagne tel ou tel service, employez la
commande sc qdescription, suivie d’un nom de service.

Etats d’un service


Comme d’autres composants opérationnels, dont par exemple processus et threads, les services Windows
ont leur dynamique dominée par des transitions entre plusieurs états.

Tableau 4.12. État des services

Constante Valeur Description


SERVICE_STOPPED 0x00000001 Le service est arrêté.
SERVICE_START_PENDING 0x00000002 Le service est en cours de
démarrage.
SERVICE_STOP_PENDING 0x00000003 Le service est en cours d’arrêt.
SERVICE_RUNNING 0x00000004 Le service est démarré.
SERVICE_CONTINUE_PENDING 0x00000005 Le service est en cours de reprise
après une pause.
SERVICE_PAUSE_PENDING 0x00000006 La mise en pause du service est
en cours.
SERVICE_PAUSED 0x00000007 Le service est en pause.

Démarrage des services


La façon dont gestionnaire de contrôle des services (Scm) orchestre le démarrage est en interne piloté par
l’entrée de registre Start.

Tableau 4.13. Valeurs de registre Start

Valeur Type de démarrage Description


SERVICE_BOOT_START(0) Démarrage Spécifie un pilote chargé (mais
pas démarré) par le programme
d’amorçage (Winload). En
l’absence d’erreur, le pilote est
démarré pendant l’initialisation
du noyau, avant le chargement de
tout pilote non-démarrage.
SERVICE_SYSTEM_START (1) Système Spécifie un chargé et initialisé
pendant l’initialisation du noyau.
SERVICE_AUTO_START (2) Chargement automatique Spécifie un pilote ou un service
initialisé lors du démarrage
système par le gestionnaire
de session (Smss.exe) ou le

143
Mécanismes de gestion

contrôleur de services (Services.-


exe).
SERVICE_DEMAND_START (3) Chargement à la demande Spécifie un pilote ou un service
que le SCM démarre uniquement
à la demande.
SERVICE_DISABLED (4) Désactivé Spécifie un pilote ou un service
désactivé.
5 Démarrage retardé Spécifie un service démarrant peu
après le démarrage de la session
utilisateur.

Une activité qui engage l’une des plus importantes, sinon la plus importante, charge de responsabilité au
sein de la fonction initiale du SCM (SvcCtrlMain) est d’orchestrer le lancement des services et des pilotes dont
les paramètres de configuration (valeur Start sous la clé idoine) stipulent que le démarrage est automatique.
En interne, SvcCtrlMain sollicite pour ce genre d’opération la fonction SCM ScAutoStartServices.

L’algorithme de ScAutoStartServices procède par phases, chaque phase correspondant à un groupe


et les phases se déroulant selon une chronologie définie par la valeur de registre HKLM\SYSTEM
\CurrentControlSet\Control\ServiceGroupOrder\List. La valeur List inclut les noms des groupes dans l’ordre
où le SCM doit les démarrer.

Certains pilotes et services exigent que des conditions, connues sous le nom de dépendances, soient
satisfaites, comme spécifiées par la présence des entrées DependOnGroup, pour ce qui concerne les
dépendances relatives à des groupes, et DependOnService, pour ce qui est des dépendances de service,
dans la clé associée au service. Dans l’éventualité où une dépendance de niveau groupe est constatée, il faut
que le groupe dont dépend le service ait déjà été initialisé et qu’au moins un service parmi ce groupe ait eu
l’occasion de démarrer. Si le service dépend d’un groupe qui démarre après le groupe auquel appartient le
service dans l’ordre de démarrage des groupes, le SCM enregistre une erreur de type dépendance circulaire
pour le service.

Le SCM prend en charge le démarrage d’un service Windows ou d’un pilote par le biais de la fonction
ScStartService, laquelle se comporte différemment selon qu’elle a affaire à l’une ou à l’autre sorte. Quand
ScStartService démarre un service, elle commence par déterminer le nom du fichier qui exécute le processus
du service en examinant la valeur ImagePath de la clé de registre associée. Elle consulte ensuite la valeur
Type, toujours sous le même emplacement, et, si cela correspond à un service destiné à intégrer un processus
qui en héberge plusieurs (SERVICE_WIN32_SHARE_PROCESS), vérifie alors que le processus dans lequel
fonctionne le service, s’il a déjà démarré, est exécuté sous le même compte que celui spécifié pour le service
à démarrer, comme indiquée par la valeur de registre ObjectName. Un service sans ObjectName est exécuté
sous le compte système local.

Si le composant dont il entreprend le démarrage a une entrée de registre valant SERVICE_KERNEL_DRIVER


ou SERVICE_FILE_SYSTEM_DRIVER, c’est que le SCM est en réalité confronté non à un service mais à
un pilote ; auquel cas ScStartService appelle ScLoadDriver pour charger le pilote. ScLoadDriver active le
privilège de sécurité SeLoadDriverPrivilege pour le processus SCM, puis passe le relais au service noyau
NtLoadDriver.

Acceptation de l’amorçage
Outre lui confier la prise en charge des services, Windows place le SCM au centre de la gestion des
configurations de démarrage, et tout particulièrement de la dernière bonne connue (last known good config).
Particulièrement utile dans dans les cas où des modifications apportées au système l’empêchent de démarrer
correctement, la dernière bonne configuration connue est en interne constituée par les paramètres de
registre correspondant au dernier démarrage réussi de l’ordinateur. Par défaut, un tel succès se compose
de deux critères : un démarrage réussi des services automatiques, et une ouverture de session utilisateur

144
Mécanismes de gestion

réussie. Il y a échec de démarrage si le système se bloque parce qu’un pilote de périphérique fait s’effondrer
le système lors de l’amorçage ou si un service automatique ayant une valeur ErrorControl définie à SERVICE_
ERROR_SEVERE ou SERVICE_ERROR_CRITICAL fait état d’une erreur lors de son démarrage.

Les configurations de démarrage enregistrées sous HKLM\SYSTEM ont des noms de la forme
ControlSet_nnn_, où nnn est un numéro du genre 001 ou 002. La clé HKLM\SYSTEM\Select contient
des valeurs qui identifient le rôle de chaque configuration (voir figure ci-après). La Valeur Current sous
Select se rapporte au jeu de contrôle actuellement utilisé. Par exemple, si CurrentControlSet pointe vers
ControlSet001, la valeur vaut 1. La Valeur LastKnownGood sous Select contient le numéro de la dernière
bonne configuration connue, laquelle fait en l’occurence tremplin vers le dernier jeu de contrôle ayant donné
lieu à un démarrage réussi. La valeur Default renvoie au jeu de contrôle à utiliser par défaut si aucun autre
n’est désigné. Autre valeur que la clé Select est susceptible de renfermer : Failed, qui pointe vers la dernière
configuration pour laquelle le démarrage a échoué.

Clé de sélection de configuration de démarrage. 


HKEY_LOCAL_MACHINE\System\Select
Current REG_DWORD 0x1
Default REG_DWORD 0x1
Failed REG_DWORD 0x0
LastKnownGood REG_DWORD 0x1

Comme nous l’avons déjà dit, que le SCM ai été en mesure de traiter correctement l’ensemble des
services automatiques ne représente qu’un des facteurs requis pour tirer un bilan positif de la phase
d’amorçage du système, dans la mesure où reste dans ce contexte à s’assurer du bon fonctionnement
des mécanismes participant à l’ouverture de session utilisateur. Aussi, quand un utilisateur ouvre une
session, Winlogon appelle la fonction NotifyBootConfigStatus, laquelle informe le SCM du succès de
l’opération. Après démarrage réussi des services automatiques ou réception du message émanant de
NotifyBootConfigStatus (de ces deux événements, c’est celui arrivé en dernier qui compte), le SCM appelle
la fonction NtInitializeRegistry pour enregistrer la configuration courante en tant que dernière bonne connue.

SCM (Service Control Manager)


Le gestionnaire de contrôle de service (SCM, Service Control Manager) est un processus système spécial
responsable du démarrage, de l’arrêt et de l’interaction la gestion des processus de service. Lancé dès
l’amorçage du système et exécutant l’image \Windows\System32\Services.exe, le SCM est implémenté sous
forme d’un serveur RPC, de sorte que à pouvoir manipuler des services sur des machines distantes.

Le SCM entretient une base de données d’informations concernant les services installés dans le système.

Objectifs de conception des services Windows


Voici quelques-uns des objectifs et règles de fonctionnement auxquels les services Windows doivent se plier.

■ Démarrage immédiat Les services lancés lorsque l’ordinateur est mis sous tension ou redémarré (services
à démarrage automatique, qui sont pour la plupart essentiels à la prise en charge de l’environnement) ne
devraient pas interférer de manière significative sur les performances du système.

■ Fermeture immédiate Arrêter des services en cours d’exécution devrait n’avoir qu’une incidence mineure
sur la capacité du système d’exploitation à s’éteindre rapidement.

■ Consommation des ressources Chaque service devrait être optimisé dans le but de consommer le moins
de mémoire et de ressources processeur. Dans la mesure du possible, chaque service devrait éviter d’être
un fardeau supplémentaire sur les performances, la fiabilité, la stabilité et la robustesse du système.

■ Chemin de performance Chaque service devrait viser un chemin de performance idéal, ce qui signifie être
respectueux des conditions dans lesquelles le système d’exploitation et les autres services s’exécutent.

145
Mécanismes de gestion

Empêcher le système d’entrer dans un des états d’économie d’énergie, monopoliser une ressource, ou au
contraire en abandonner une sans l’avoir libéré (un mutex) sont des exemples de situations préjudiciables
pour tous les acteurs du système.

■ Exécution avec le compte à moindres privilèges Chaque service ne devrait posséder que les privilèges
et ne réclamer que les ressources nécessaires à son exécution. Sur le plan de la sécurité, les services
ayant besoin d’être exécutés avec les données d’identification d’un compte utilisateur devraient choisir
celui avec le moins de capacités, autrement dit le moins susceptible d’augmenter la surface d’attaque de
l’ensemble du système.

Les règles mentionnés ci-dessus guide la démarche d’une bonne gestion des services. Les sections suivantes
décrivent pour la plupart comment les services peuvent les respecter.

Services Windows et tâches planifiées


Pour l’essentiel, la différence entre services Windows et tâches planifiées tient au fait de quand les uns et
les autres peuvent agir, et pour quelle longévité.

Les services Windows mettent en œuvre une fonctionnalité particulière du système d’exploitation,
généralement pour le compte d’autres processus, et à un assez bas niveau. De telles applications
n’interagissent pas avec l’utilisateur et ne nécessitent pas qu’un utilisateur ait ouvert une session pour
s’exécuter.

Les tâches planifiées n’effectuent généralement pas non plus d’interaction utilisateur, mais nécessitent qu’un
utilisateur ait ouvert une session. Les tâches planifiées sont déclenchées en fonction d’un calendrier ou
par des conditions système, et sont gérées par le Planificateur de tâches. Les services ont un cycle de vie
orchestré par le Gestionnaire de contrôle des services.

Comptes de services
Le contexte de sécurité d’un service, dans la mesure où c’est par son intermédiaire que sont définies les
ressources auxquelles le processus peut accéder, tient lieu de sujet important tant pour les concepteurs
de logiciels que pour les administrateurs. Dans la configuration par défaut, chaque service exécuté sous
Windows peut l’être en fonction de l’une ou l’autre de trois identités : Système local, Service réseau et Service
local. Les permissions de chacun de ces comptes sont ajustées précisément afin de leur octroyer uniquement
les permissions nécessaires sur le système, ceci dans le but de limiter l’exposition du système d’exploitation
en cas de faille de sécurité ou d’utilisation non autorisée.
Tableau 4.14. Privilège des comptes de service

Privilège Système local Service réseau Service local


SeAssignPrimaryTokenPrivilege
SeAuditPrivilege
SeBackupPrivilege    
SeChangeNotifyPrivilege
SeCreateGlobalPrivilege
SeCreatePagefilePrivilege    
SeCreatePermanentPrivilege    
SeCreateTokenPrivilege    
SeDebugPrivilege    
SeEnableDelegationPrivilege
     
SeImpersonatePrivilege

146
Mécanismes de gestion

Privilège Système local Service réseau Service local


SeIncreaseBasePriorityPrivilege    
SeIncreaseQuotaPrivilege
SeLoadDriverPrivilege    
SeLockMemoryPrivilege    
SeMachineAccountPrivilege
     
SeManageVolumePrivilege    
SeProfileSingleProcessPrivilege    
SeRemoteShutdownPrivilege
     
SeRestorePrivilege    
SeSecurityPrivilege    
SeShutdownPrivilege
SeSyncAgentPrivilege      
SeSystemEnvironmentPrivilege    
SeSystemProfilePrivilege      
SeSystemTimePrivilege
SeTakeOwnershipPrivilege    
SeTcbPrivilege    
SeUndockPrivilege

Compte système local


Plus haut gradé de la hiérarchie des comptes de services Windows, le compte système local représente
auprès des autorités concernés l’identité, par extension le profil de sécurité, du système d’exploitation.
Possédant de manière intrinsèque toutes les autorisations et tous les droits requis pour un accès complet à
l’ordinateur, le compte système local est ainsi par nature extrêmement puissant, plus puissant que n’importe
quel compte local ou domanial quand il s’agit de privilèges de sécurité locaux. Peu de surprise, donc,
à ce que ce soit sur cette identité que s’appuie la plupart des services, y compris ceux représentant
des composants clé : gestionnaire de sessions (Smss.exe), sous-système d’authentification de sécurité
locale (Lsass.exe), processus d’ouverture de session (Winlogon.exe), sous-système Windows (Csrss.exe), et
quelques autres encore.

Le compte Système Local peut être utilisé pour exécuter un service lorsque celui-ci requiert des permissions
locales élevées, comme par exemple pour écrire dans les quelques sous-ensembles du système (système de
fichiers ou base de registre) où seul ce compte a le droit de le faire.

Les caractéristiques principales du compte Système Local sont les suivantes :

■ Il a pour véritable nom NT AUTHORITY\System.

■ Il est membre du groupe Administrateurs locaux. Le tableau x indique les groupes auxquels appartient
le compte système local.

■ Il a le droit d’activer presque tous les privilèges (même ceux qui ne sont pas en principe accordés au
compte administrateur local, par exemple la création de jetons de sécurité). Voir tableau x pour la liste
des privilèges attribués au compte système local.

■ Il possède plus de droits que le compte administrateur, pour lequel certaines parties du système
d’exploitation demeurent dans tous les cas invisibles. Par exemple, alors que la ruche de sécurité

147
Mécanismes de gestion

HKEY_LOCAL_MACHINE\SECURITE est interdite à l’administrateur (puisque réservée à un rôle particulier),


elle est autorisée pour le compte système.

■ Les processus exécutés sous le compte système local le sont avec le profil utilisateur par défaut (HKU
\.DEFAULT). Ils ne peuvent par conséquent pas accéder aux données de configuration stockées dans les
profils utilisateur d’autres comptes.

Compte service réseau


Autre compte duquel une instance peut se réclamer, Service réseau est utilisé par des services ayant besoin
d’accéder à des ressources sur le réseau sans pour autant nécessiter de privilèges particulièrement élevés.

Représentant également le système d’exploitation, Service Réseau possède cependant moins de


permissions sur le système que Système Local. En premier lieu, son profil de sécurité englobe une étendue
de moindre ampleur - en termes plus techniques, le jeton d’accès attribué à Service Réseau possède moins
de privilèges que celui distribué pour son confrère Système Local. D’autre part, les listes de contrôles d’accès
(ACL) de nombreux objets du système sont plus restrictives pour Service Réseau qu’elles ne le sont envers
Système Local, cela avec comme conséquence de donner moins de latitude aux processus exécutés sous
ce compte. Ainsi, ces processus ne peuvent pas par exemple, charger de pilotes dans le système d’E/S, ou
ouvrir arbitrairement d’autres processus.

Le compte Service réseau bénéficie du même niveau d’accès aux ressources et aux objets que les membres
du groupe Utilisateurs. Les services qui s’exécutent sous le compte Service réseau s’identifient auprès des
machines présentes sur le réseau à l’aide des informations d’identification du compte d’ordinateur.

Les processus exécutés sous le compte service réseau utilisent le profil du compte service réseau, chargé
dans le registre sous HKU\S-1-5-20, "AUTORITE NT\SERVICE RÉSEAU" en tant que service réseau. (Vous
aurez compris que S-1-5-20 est une valeur sous forme de SID).

Le compte Service réseau dispose de privilèges minimaux sur l’ordinateur local. Cela empêche quiconque
d’utiliser le compte pour accéder à des ressources protégées du système. Aucun mot de passe n’est associé
à ce compte.

Compte service local


Le compte service local est quasiment identique au compte service réseau, à cette différence majeure près
qu’il ne peut accéder qu’aux ressources réseau autorisant l’accès anonyme (session nulle).

Tout comme le compte service réseau, dont il se rapproche de bien des manières du point de vue de la
sécurité, service local dispose de permissions réduites sur le système d’exploitation, équivalentes à celles
d’un utilisateur standard non-administrateur. Ledit compte est par conséquent majoritairement employé
parallèlement à des processus qui se satisfont facilement d’un cadre étroit en ce qui concerne les droits et
les privilèges qui leur sont accordés, ou qui n’ont tout simplement pas besoin d’accéder au réseau.

Les processus exécutés sous le compte service local le sont par l’intermédiaire du profil se trouvant sous
HKU\S-1-5-19, lequel est chargé au niveau du système de fichiers depuis %SystemRoot%\ServiceProfiles
\LocalService.

Exemples de services que Windows exécute sous le compte service local : Registre à distance (service
RemoteRegistry), qui permet d’accéder à distance à la base de registre du poste ; LmHosts, qui effectue la
résolution de noms NetBIOS.

Exécution de service sous un compte suppléant


Compte tenu des restrictions précédemment mentionnées, certains service ont besoin de fonctionner sous
un compte de connexion suppléant, compte dont les données d’identification viendront alors alimenter le
contexte de sécurité dudit service. Vous pouvez configurer un service pour qu’il soit soit exécuté sous un

148
Mécanismes de gestion

compte de remplacement, soit lors de la création du service soit en spécifiant un compte et un mot de passe
dans l’outil d’administration Services. Pour ce faire, ouvrez la console Services (Services.msc), cliquez avec le
bouton droit de la souris sur un service, sélectionnez Propriétés, allez dans l’onglet Connexion, puis cochez
l’option Ce compte.

Démarrage automatique différé


Jusqu’à Windows Vista, la gestion des services ne reconnaissait que deux modes de démarrage: manuel
et automatique. Du fait qu’un service à démarrage manuel exige l’intervention de l’utilisateur, l’alternative
habituelle était le mode automatique, lorsque le service devait démarrer lors du démarrage du système, avant
même l’ouverture d’une quelconque session utilisateur. Quel que soit le soin porté à leur optimisation, les
services à démarrage automatique ont une incidence non négligeable sur les performances de démarrage du
système. Pour complexifier encore ce paysage, il faut aussi noter que les utilisateurs sous Windows tendent
généralement à employer la machine immédiatement après l’avoir démarré et ouvert une session, ce qu’ils
estiment être antérieur à la fin des préparatifs nécessaires pour une expérience complète du système. Les
services à démarrage automatique, qui dans ce contexte effectuent leur initialisation en même temps que
l’utilisateur entame diverses activités, contredisent par nature ce schéma.

Pour remédier à ce problème, Microsoft avait incorporé à son système d’exploitation un mécanisme nouveau,
appelé démarrage différé, dont le principe consiste en l’introduction d’une courte pour la mise en route des
services concernés. Cela permet à l’utilisateur de commencer à interagir avec ses applications sans ressentir
l’impact des dits services lors de l’ouverture d’une session.

Un certain nombre de services distribués avec Windows sont automatiquement mis en œuvre avec un départ
retardé par rapport aux autres services. Parmi ceux-ci figurent Windows Update, le partage réseau Media
Player, Windows Defender, etc.

Les concepteurs de logiciel ont la possibilité pour marquer un service comme à démarrage automatique
différé d’employer l’API de contrôle de service ChangeServiceConfig2, accompagnée de la structure
SERVICE_DELAYED_AUTO_START_INFO.

Soulignons, pour en terminer à leur sujet, que les services à démarrage automatique, s’ils constituent
une amélioration notable, ne règlent pas tout les problèmes liées aux performances de démarrage des
composants s’exécutant en marge du système d’exploitation. Il n’existe, par exemple, aucune garantie quant
au moment où sera démarré un service, ni quand aura lieu la commande de contrôle émise dans ce but
par le SCM. (Notez que ces limitations, loin d’être imputable à une mauvaise conception des services,
découlent du fait que Windows ne soit pas un système d’exploitation temps réel.) De plus, et encore une fois
du fait qu’ils n’obéissent pas à une temporalité bien définie, les services à démarrage automatique différé
sont difficilement conciliables, voire incompatibles, avec les règles communes en matière de dépendances
et d’ordre de démarrage des services Windows. De tels services ne peuvent en conséquence rejoindre
aucune des hiérarchies prévues pour gérer les enchaînements de démarrage de services, conçues pour
donner le départ à des services ayant besoin entre eux de respecter un ordre donné. Un service à
démarrage automatique peut par contre dépendre d’un service service à démarrage automatique différé,
cela établissant néanmoins le problème du lien qui unit entre les deux services. Ainsi, comme un service ne
peut démarrer que lorsque les services dont il dépend ont eux même démarrés, le SCM lancera le service à
démarrage automatique différé lors de la séquence d’initialisation du système, avec comme effet de réduire
à néant tous les avantages que comptait procurer le dit service.

Gérer les services


Windows propose quatre outils principaux avec lesquels gérer des services :

■ L’outil d’administration S