Written by Claus Witjes and Arne Stremlau
This article about the Windows boot process is part of a continuing series on OS boot and user logon delays on Windows computers joined to Active Directory domains. Related articles describing
known issues and tools to troubleshoot slow boots and user logons can be found in the following links:
A question that Premier Field Engineers often get asked onsite is “Why do our users wait so long for Windows to boot that they sometimes have time to get a cup of coffee?”
The reality is that there are a myriad of reasons including hardware performance, network performance, the amount of the workloads added by administrators as well as inefficiencies in Microsoft
and ISV applications and OS components.
The goal of this article is to give readers an overview of the Windows boot process so that you can better troubleshoot a slow OS start or slow user logon that is caused by delays in the OS boot process. Related problems
about resuming from sleep, wake from hibernate, or OS shutdown processes are not covered in this article.
Table of Contents Boot Process OverviewBIOS InitializationOS LoaderOS InitializationThe PostBoot phaseThe ReadyBootPrefetcherAdditional references
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. 
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. 
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. 
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. 
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. 
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
graphs we found the profile service waiting about 25 seconds on the network.
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.
 Windows On/Off Transition Performance Analysis,
 Windows On/Off Transitions Solutions Guide,