IBM PC-AT‎ > ‎Windows‎ > ‎Boot Process (detailed)‎ > ‎

Phase 8 - SMSS, Services & LSASS

With the "boot" and "system" device drivers started, the kernal is now ready to "really" start.  There are two pre-defined processes in the kernel.  The first is called IDLE and is the lowest-priority process (it runs when nothing else needs the CPU).  The second is the SYSTEM process which spawns threads for the kernel's use.  These processes are now started. 
 
The SYSTEM process begins by starting a new process, Session Manager Sub-System by running (loading and starting) SMSS.EXE.  It checks the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager ("Session Manager key") for the sub-key called SubSystems and starts the "operating sub-systems" listed in the "Required" entry.  Typically this contains only the value "Windows".  Other possiblities are "Posix", "Debug", and "OS2".  The session manager runs the executible specified by each entry named in the same registry key.  For example, "Windows" entry is in the SubSystems registry key (or better be!) and has the default value of %SystemRoot%\system32\csrss.exe ... (where the ... are parameters passed to CSRSS).
 
There several other sub-keys in the "Session Manager key".  In particular the "Environment" sub-key.  It enumerates values, like system paths "windir", "temp" and other constants like PATHEXT and ComSpec which can be seen at a CMD prompt by entering SET (no parameters).  I'm not sure if all sub-systems inherit these values, or if it is specific to the Windows sub-system.
 
In the Session Manager key (not the SubSystems sub-key) is an entry named "BootExecute" with a typical value of "autocheck autochk *" which presumably does a quick check of all drives (and may give an error report and perform extensive testing/repairs if things seem wrong on a file system).
 
Getting ahead of ourselves, SMSS will eventually start the Windows (sub)system by creating the CSRSS process, but before that (or perhaps concurrently) it launches another process called Winlogon (WINLOGON.EXE).  Strangely this seems to be a global / system process, and not Windows-specific (for example, I don't think there is a PosixLogon or OS2Logon).
 
Anyway, Winlogon starts two processes: SERVICE.EXE, the services manager which handles the Event Log (vital for trouble-shooting); and LSASS.EXE, the Local Security Authority Sub-System.  The SERVICE process again scans the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services for those "Start" entries that have a value of 0x00000002 indicating "automatic start-up."  These services are loaded and started.  Interesting items here include the Remote Procedure Call Sub-System (RPCSS, which is not optional... Windows will crash if it fails), the Security Accounts Manager Sub-System (which is in the previously mentioned LSASS.EXE).
 
LSASS, a.k.a. SamSS, is responsible for enforcing security for the system via Access Control Lists (ACLs) in the registry hives and NTFS file system.  It seems that LSASS first loads the Security registry hive (from %SystemRoot%\System32\config\security) which appears in the registry as HKLM\Security.  This contains a list of security policies (real registry keys) and a symbolic link (virtual registry key) to another registry hive that is loaded from %SystemRoot%\System32\config\sam.  This second registry hive appears as its own registry key under HKLM\SAM\SAM (that is not a typo).  The SAM hive contains a list of accounts (group names and user names) and hashes of their passwords (not the actual password).
 
The ACLs of both the Security and Sam hives are unusual.  Even administrators are denied access to registry keys in these hives (by default).  This makes investigation difficult even for experienced programmers / administrators or the casual hacker.  One way possible way to view them is "off-line" as raw data files, however that is not easy because the SYSTEM process (or one of its decendants, like SMSS or LSASS) maintains a file lock as long as Windows is running.  In other words you would need to dual-boot into another operating system on the same machine, or install the hard-drive onto a second computer.  Another way to view these keys is to run the Recovery Console of Windows Vista and later.  There you can run Regedit to view registry files in the context of the operating system (instead of as a normal user or administrator).  Of course you will typically need the Windows install disks to run the Recovery Console unless the OEM has installed it on the hard drive and you can access it.  Troublesome!  Probably the easiest way to view those registry keys is to use a Sysinternals utility called PsExec by Mark Russinovich.  It lets you run Regedit (or other software) in the context of the System account.  Not suprisingly, you need administrative priviledges to do this.
 
It has been reported that pre-XP-SP2 versions of Windows had a serious security bug: if the SAM hive was missing, then you could log on as anybody without a password.  I haven't been brave enough to try deleting the SAM file on my older systems to verify this.  However it is also reported that newer versions (Vista, etc.) will shutdown if the SAM hive can not be loaded.  I can verify this... and it shuts down without any warning!  No BSOD or error message... it just reboots.  So if the computer seems to be loading device drivers okay but then reboots without warning, it may be a corrupt or missing SAM file.
 
The SAM file can store the password hashes in multiple formats for different security "providers".  Older systems (before Vista) stored the LanMan hash which is appearantly easy to crack.  Note that at least with Windows 2000 (maybe NT4) a stronger hash function is available, but the LanMan hash was also generated by default.  It is possible to turn off the LanMan hash on the older systems, and I believe it also possible to turn on LanMan hashing on newer systems.  Anyway, if the LanMan hash has been disabled, a dummy value will still appear.  I believe the newer hash is a Kerberos 128-bit hash, but I'm not a security expert.
 
Anyway, unless the system registry key has been changed, SMSS will finally "officially" start Windows by running the Client-Server Run-time Sub-System (CSRSS.EXE) which starts Phase 9.  Windows will "crash" if this process ever terminates, which I find strange because SMSS should be able to do "something."

© H2Obsession, 2014, 2016
Comments