The Boot Process explained

admin

Boot Process Overview

Fast OS startup performance is critical for a good user experience. The time required to boot the operating system on a given computer to the point where the user can start working is one of the most important benchmarks for Windows client performance. The Windows boot process consists of several phases which are explained in more detail by the picture and supporting text below.

The Windows Performance Toolkit (included in the Windows 7.1 SDK ) allows you to investigate most of the boot phases (except for BIOS Initialization and OS Loader).

---

BIOS Initialization

During the BIOS Initialization phase, the platform firmware identifies and initializes hardware devices, and then runs a power-on self-test (POST). The POST process ends when the BIOS detects a valid system disk, reads the master boot record (MBR), and starts Bootmgr.exe. Bootmgr.exe finds and starts Winload.exe on the Windows boot partition, which begins the OSLoader phase [1].

The BIOS version, the BIOS configuration and the firmware of the computer hardware components can have an impact on the overall boot performance. There is no way to trace this phase using the Windows Performance Toolkit. You need to manually measure the time. In order to optimize or troubleshoot this early phase in the overall computer startup process, make sure to update the BIOS version and firmware of all hardware components to the latest versions. In addition check the BIOS configuration (device boot order, PXE boot-enabled, Quick/Fast boot (POST check) enabled, AHCI settings, and so on).

Be careful changing the BIOS configuration or updating the firmware/UEFI/BIOS versions. Read the hardware vendor manuals carefully because misconfigurations and failed updates can cause complete system outages. Create a backup of your system and data beforehand.

---

OS Loader

During the OSLoader phase, the Windows loader binary (Winload.exe) loads essential system drivers that are required to read minimal data from the disk and initializes the system to the point where the Windows kernel can begin execution. When the kernel starts to run, the OSloader loads the system registry hive and additional drivers that are marked as BOOT_START into memory. [1]

This phase is mainly impacted by boot start drivers. While a delay caused by a dual boot menu would be easy to fix, make sure that all boot start drivers are signed and up-to-date.

To identify boot start drivers which are not signed:

• Create a boot trace using the Windows Performance Toolkit. For more information about how to create a trace, see slow boot and logon analysis articles for analysis.
• Runxperf –i <boottrace.etl> -o bootevents.txt –a dumper
• Findstr /C:”I-DCStart” bootevents.txt > bootevents.csv
• Open the bootevents.csv using Excel and runsigntool verify /v <driver> Signtool.exe is part of the Windows SDK .
• If you find a driver which is not signed, look for driver updates.
  

---

OS Initialization

During the OS Initialization phase, most of the operating system work occurs. This phase involves kernel initialization, Plug and Play activity, service start, logon, and Explorer (desktop) initialization. The OS Initialization can be divided into four subphases. Each subphase has unique characteristics and performance vulnerabilities. [1]

After you have taken a boot trace the different subphases are shown as follows in XPERFVIEW.EXE:

Sub phase 1 - PreSMSS: Kernel Initialization

The PreSMSS subphase begins when the kernel is invoked. During this subphase, the kernel initializes data structures and components. It also starts the PnP manager, which initializes the BOOT_START drivers that were loaded during the OSLoader phase. [1]

Sub phase 2 - SMSSInit : Session Initialization

The SMSSInit subphase begins when the kernel passes control to the session manager process (Smss.exe). During this subphase, the system initializes the registry, loads and starts the devices and drivers that are not marked BOOT_START, and starts the subsystem processes. SMSSInit ends when control is passed to Winlogon.exe. [1]

Sub phase 3 - WinLogonInit: Winlogon Initialization

The WinLogonInit subphase begins when SMSSInit completes and starts Winlogon.exe. During WinLogonInit, the user logon screen appears, the service control manager starts services, and Group Policy scripts run. WinLogonInit ends when the Explorer process starts. [1]

Sub phase 4 – ExplorerInit: Explorer Initialization

The ExplorerInit subphase begins when Explorer.exe starts. During ExplorerInit, the system creates the desktop window manager (DWM) process, which initializes the desktop and displays it for the first time. [1]

A detailed analysis of each phase would go far beyond the scope of this article. The analysis always starts with a boot analysis trace created with the Windows Performance Toolkit, which is described in the Windows On/Off Transition Performance Analysis Whitepaper . Common performance vulnerabilities are described in the whitepaper as well.

Still, it might require more tools (like parallel network traces and additional debug logs such as Gpsvc logging) to fully analyze a problem.

For now, begin your analysis on phases that consume the most time and compare traces with a fresh/clean-OS installation on same hardware.

To give you two examples:

If the WinLogonInit phase takes a long time, you can use the Winlogon graph for further analysis.  

In this example the Group Policy processing took around 160 seconds to complete, before the Windows desktop could be loaded. While the Winlogon graph does not explain why it took 160 seconds to complete GPO processing (which could be related to network issues, policy settings, GPO preferences, scripts, and so on), your can see where to investigate further.

In another example while analyzing the ReadyingProcess/ReadyingThreadId graphs we found the profile service waiting about 25 seconds on the network.

---

The PostBoot phase

The PostBoot phase includes all background activity that occurs after the desktop is ready. The user can interact with the desktop, but the system might still be starting services, tray icons, and application code in the background, potentially having an impact on how the user perceives system responsiveness. [1]

---

The ReadyBootPrefetcherDuring the Windows boot process a lot of data is read from disk and I/O pressure is one of the determining factors for boot performance. The Windows prefetcher (or ReadyBoot) helps to read data into memory before Windows needs it. In addition each reboot will allow the prefetcher to better predict what data is needed.

While ReadyBoot is usually turned on for classic harddisks, it is off for fast SSDs, of if WinSAT disk score is > 6.0.

One way to analyze the prefetcher activities is to run xperf.exe from the Windows Performance Toolkit.

Xperf –i  <boottrace.etl> - o prefetcher.txt –a bootprefetch – summary

To “train” a system, you can run the xbootmgr.exe with the –prepsystem command option.

The above should give you some insight into where to start looking for issues during the Windows boot phase, as it will help you identify the correction section to start troubleshooting.

A recommendation is to check the hardware platform thoroughly by updating the BIOS and checking hard drive performance with benchmarking tools prior to searching for the problem on the OS layer.