Good performance during Windows startup and shutdown is critical for a good user experience because many users consider the time that is required to boot a computer to be a primary benchmark of hardware and operating system performance.
The power-on process consists of four main phases, some of which can be broken down further into sub-phases.
The first phase is the pre-OS phase which powers on the hardware. This phase can be broken down into four sub-phases:
- TPM Initialization: A Trusted Platform Module (TPM) is a hardware component that uses its own internal firmware and logic circuits to add cryptographic functionality. It works with supporting software and firmware to prevent unauthorized access to a computer. The TPM contains a hardware engine to perform up to 2048-bit RSA encryption/decryption. The TPM uses its built-in RSA engine during digital signing and key wrapping operations.
- System BIOS: initializes hardware BIOS (Basic Input/Output System) and runs POST (Power-On-Self-Test). The POST checks the BIOS and the CMOS RAM. If no issues, then POST continues to check the CPU, hardware devices such as the Video Card, the secondary storage devices such as the Hard Drive and CD/DVD Drives.
- Load BIOS of other devices: Video cards, storage controllers, network interface cards may all have BIOS.
- BIOS searches for boot device: If no device found, system displays a boot device error.
The second phase is the Firmware-OS phase which transitions control to the Windows Boot Loader. This phase loads the Master Boot Record (MBR) from the boot device. If the MBR is not found or corrupt, the system displays a non-system disk error or disk boot failure. If the MBR is found, it will access the file system on the boot drive for boot configuration data and look for disk encryption information.
The Firmware-OS phase passes control to the boot loader – which could be either a Full-Disk Encryption boot loader (Bitlocker, Safeboot, etc.) or the Windows OS boot loader if FDE is not in use.
Full-Disk Encryption Process
Full-Disk Encryption implementations may take various forms, but for the purposes of this discussion it is sufficient to know that FDE sits between the Operating System and the hardware and encrypts and decrypts every bit of data being read from and written to the hard drive. This requires processing power and therefore, time.
Most popular software implementations of FDE encrypt a volume using a symmetric Advanced Encryption Standard (AES) algorithm with 128-bit or 256-bit keys. The keys are stored or protected by the Trusted Platform Module (TPM) which uses multiple criteria (PIN, Password, Biometrics, hardware configuration) to make the keys available to the FDE software. Alternate storage methods and recovery overrides are typically available.
Wndows Boot Process
The Windows loader (WINLOAD.EXE) loads and executes the Windows 7 Kernel which initializes the system by calling the HAL Initialize process – display driver, system debugger, and then launches SMSS.EXE – the session manager.
SMSS.EXE loads the rest of the registry and configures the environment to run all of the various Windows process and subsystems such as the security subsystem, additional device drivers and services and creates the user session by launching WINLOGON.EXE.
Windows Logon Process
This section is excerpted from Microsoft Technet: http://technet.microsoft.com/en-us/library/cc780332%28WS.10%29.aspx
The following figure shows the local logon process.
Local Logon Process: see http://i.technet.microsoft.com/dynimg/IC196890.gif
The GINA specifies the Negotiate authentication package when it calls into the LSA. Negotiate must then choose an authentication package to process the logon. Negotiate sends the credentials to Kerberos, the default authentication package in Windows Server 2003. However, the Kerberos authentication package cannot process local logons, so it returns an error to Negotiate. Negotiate then calls NTLM to authenticate the user by comparing the received credentials with those hashed in the SAM.
If the credentials are valid, the LSA generates an access token for the user based upon user rights assigned to the user’s account and LsaLogonUser returns the logon success and the user’s access token to Winlogon and the GINA. The GINA then activates the user’s shell and Winlogon switches to the default desktop. If the credentials are invalid, the LSA returns a logon failure, the GINA displays an error message and prompts the user to present valid credentials, and Winlogon remains in the Winlogon desktop.
Domain logons can only be performed from computers that are joined to a domain. Domain credentials consist of a user’s domain account user name, password, and the name of the domain. The local computer’s LSA chooses the appropriate authentication package to use based on the domain’s environment.
The following figure shows the process that occurs when the local computer can reach a domain controller to authenticate the user. If a domain controller is not available, a cached logon occurs.
Domain Logon Process: See http://i.technet.microsoft.com/dynimg/IC196891.gif
As with the local logon process, the Negotiate authentication package routes the authentication request to the default authentication package, Kerberos.
The domain client chooses Kerberos, and Kerberos validates the user’s credentials by contacting the domain controller. The LSA on the domain controller returns the logon success or failure to the local computer’s LSA. If the domain logon succeeds, the local LSA generates an access token for the user based upon user rights assigned to the user’s account, and LsaLogonUser returns the logon success and the user’s access token to Winlogon and the GINA. The GINA then activates the user’s shell, and Winlogon switches to the default desktop. If the credentials are invalid, the LSA returns a logon failure, the GINA displays an error message and prompts the user to present valid credentials, and Winlogon remains in the Winlogon desktop.
Windows Server 2003 supports cached logons. The cached credentials of the last 10 users who have successfully logged on to a domain account can be used to log a user on locally if the authenticating domain controller becomes unavailable.