Session Manager Subsystem (sous-système gestionnaire de session smss.exe) est un composant de Windows.
Il est exécuté dès le processus de démarrage de Windows. Durant cette phase, il lance autochk.exe pour vérifier le ou les différent(s) système(s) de fichiers, puis après cette vérification, il crée les variables d'environnement et démarre
S'il y a plus d'une session ouverte (c'est-à-dire plusieurs utilisateurs connectés en même temps), smss.exe lance à chaque fois le nouveau processus winlogon.exe pour l'utilisateur correspondant.
Sur Windows XP (pack 2 ou non), si le processus lsass.exe (système de sécurité) ou winlogon.exe ou services.exe s'arrête, alors smss.exe provoque le reboot de l'ordinateur. Cela permet de garantir la sécurité.
NB : Si le processus csrss.exe s'arrête, cela provoque un reboot direct, sans passer par smss.exe. La raison en est que csrss.exe est le seul processus qui a le bit processus critique positionné dans la structure EPROCESS
Voir Processus de démarrage de Windows NT#Gestionnaire de session (smss.exe)
Certaines variables d'environnement sont dans HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment
%SystemRoot% ne fait pas partie de ces variables, mais elle est utilisée pour en définir d'autres.
Nom de la variable | Valeur par défaut (Windows 7) | Remarque |
---|---|---|
ComSpec | C:\Windows\system32\cmd.exe | Chemin du fichier cmd.exe |
FP_NO_HOST_CHECK | No | Sans objet |
NUMBER_OF_PROCESSORS | Sans objet | Cette variable compte le nombre de cœurs de processeurs et non pas le nombre de processeurs ; en 2011, sur un ordinateur grand public, une valeur de 8 n'a rien d'extraordinaire |
OS : | Windows_NT | La valeur est Windows_NT (sauf sur d'anciennes versions de Windows, datant d'avant l'année 2000) |
PATH | C:\Program Files\Common Files\Microsoft Shared\Windows Live ; C:\Program Files (x86)\Common Files\Microsoft Shared\Windows Live ; %SystemRoot%\system32 ; %SystemRoot%;%SystemRoot%\System32\Wbem ; %SYSTEMROOT%\System32\WindowsPowerShell\v1.0\ ; C:\Program Files (x86)\Windows Live\Shared | Si un exécutable n'est pas à l'emplacement[1] par défaut, cette variable d'environnement indique dans quels répertoires le chercher |
PATHEXT | .COM ; .EXE ; .BAT ; .CMD ; .VBS;.VBE ; .JS ; .JSE ; .WSF;.WSH ; .MSC | Indique[2] quels extensions de fichiers sont des exécutables en ligne de commande |
PROCESSOR_ARCHITECTURE | Sans objet | Les valeurs peuvent être par exemple x86 et AMD64 |
PROCESSOR_IDENTIFIER | Sans objet | Exemple de valeur : x86 Family 15 Model 31 Stepping 0, AuthenticAMD |
PROCESSOR_LEVEL | Sans objet | Exemple de valeur : 15 |
PROCESSOR_REVISION | Sans objet | Exemple de valeur : 1f00 |
PSModulePath | C:\Windows\system32\WindowsPowerShell\v1.0\Modules\ | Emplacement des modules de Powershell |
TEMP | C:\users\dupont\AppData\Local\Temp | Répertoire de fichiers temporaires (le lien entre le contenu du registre et la valeur de la variable d'environnement est INDIRECT) |
TMP | Même valeur que pour %TEMP% | Même remarque que pour %TEMP% |
USERNAME | Sans objet | Contient le nom de l'utilisateur courant ; exemple Dupont |
windir | C:\Windows |
Le paramétrage pour la vérification des systèmes de fichiers (autochk) est fait à 2 endroits :
Il est possible de modifier ces paramètres via un outil en ligne de commande : chkntfs.exe.
Les paramètres concernant la gestion de la mémoire sont stockés dans HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management
La valeur de registre ClearPageFileAtShutdown permet d'effacer le fichier d'échange avant chaque arrêt, ce qui permet partiellement de préserver la confidentialité de certaines informations.
Attention ! Mettre cette valeur ClearPageFileAtShutdown à '"1" rallonge le temps de fermeture de Windows (par exemple, sur certains PC, il peut passer de moins de 5 secondes à 30 secondes ou plus...). Ceci ne se produira qu'à partir du deuxième boot après la modification du registre.
Les valeurs de registre suivantes permettent d'adapter d'améliorer (ou de diminuer ...) les performances d'un ordinateur :
C:\pageFile.sys 1536 3072
Il est aussi possible de paramétrer des switch de boot dans la phase d'amorçage (3GB, userva et autres) : voir boot.ini
Si Exchange est installé, le paramétrage de Exchange peut désactiver le paramétrage mémoire dans le gestionnaire de session (valeur ParametersSystem dans l'arborescence HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem)
Pour la Contrat de licence utilisateur final, les informations sur l'activation (WPA : Windows Product Activation) sont stockés dans HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\WPA.
Il y a un PID (Product ID) généré pour l'installation de Windows.
Sur les anciennes versions de Windows, il existait des ports LPT1, LPT2, … (ports parallèle pour imprimante par exemple) et COM1, COM2, … (ports série pour modem par exemple). La compatibilité des anciens programmes est assurée en partie par le gestionnaire de session.
Ces informations de configuration sont stockés sous l'arborescence HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\DOS devices.
Pour la compatibilité POSIX de la gestion des sessions, les informations de configuration sont stockées dans HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\subSystems\Posix
Pour csrss.exe, les informations de configuration sont stockés dans HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\subSystems\CSRSS
Les autres informations de configuration sont :
Les DLL connus sont stockés dans HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLS, cela va de advapi32.dll (Interface de programmation avancée) à wS2_32.dll (socket) en passant par kernel32.dll (bibliothèque de performance) et user32.dll (bibliothèque de sécurité).
Unix utilise une partition de swap alors que Windows utilise un (ou des) fichier(s) de swap (pagefile.sys).
fsck est l'utilitaire de base sous Unix/linux pour la vérification de tout type de système de fichiers.
Sur la distribution debian (version Sarge) de linux, la vérification initiale des systèmes de fichiers est faite via 2 scripts checkroot.fs et checkfs.sh qui sont appelés via des liens symboliques dans /etc/rcS.d. Ces 2 scripts utilisent fsck.