In Windows OSD there comes a time when you have to dive into startup process of Windows PE. Whether it is to troubleshoot boot up time issues, or to create a bespoke deployment solution, having a basic understanding of chain of events taking place when WinPE loads helps a great deal. In this article I am going to take you through the overall boot up process, as well as particular cases of images generated by WAIK/WADK, MDT and SCCM in their default configuration.
I am going to skip right to when Winlogon.exe takes over, leaving earlier stages of boot up (such us works of boot loader and kernel) perhaps for another day. Best way to illustrate this process is with a flowchart.
You can find more information on this topic in the following TechNet article: https://technet.microsoft.com/en-gb/library/cc721977.aspx.
In principle, you should not modify HKLM\SYSTEM\Setup\CmdLine, but let winpeshl.exe do all the leg work for you. When customizing boot up process of your WinPE image, you should primarily focus on modifying winpeshl.ini – with some exceptions. Microsoft’s reference on winpeshl.ini can be found here: https://technet.microsoft.com/en-GB/library/hh825046.aspx
Let’s take a closer look at each of exit points from the flow chart.
In first instance, Winpeshl.exe will try to run %SYSTEMDRIVE%\sources\setup.exe (if found). This is pretty much how native Windows installer gets executed.
“Plain” WinPE image generated with WAIK/WADK
If Winpeshl.ini does not specify any applications to be run, %SYSTEMROOT%\system32\startnet.cmd will be executed. In its default configuration, startnet.cmd contains a single line calling wpeinit.exe. It is a handy little executable located in %SYSTEMROOT%\system32 that initialises the environment and most importantly loads your network and storage drivers. You can modify startnet.cmd as you please, but make sure to leave wpeinit.exe in there (preferably as first thing that is executed, unless you have a very good reason to do otherwise). Once startnet.cmd has been processed, you will be left with a Command Prompt window open – close it, and WinPE will reboot.
WinPE image generated with MDT
Typical image generated with MDT will have winpeshl.ini pointing to run %SYSTEMROOT%\System32\bddrun.exe /bootstrap. This process will initialise WinPE (including loading drivers) and then parse Unattend.xml found on the root of the RAM drive. By default, Unattend.xml contains only one RunSynchronousCommand statement calling wscript.exe X:\Deploy\Scripts\LiteTouch.wsf. It is best to modify Unattend.xml instead of winpeshl.ini in MDT boot images, as the basic environment is already taken care of when processing Unattend.xml. You can find an example of such customisation in Changing MDT deployment share path (bootstrap.ini) on boot (on the fly).
WinPE image generated with SCCM
An image generated with SCCM will have winpeshl.ini pointing to run %SYSTEMDRIVE%\sms\bin\<arch>\TSBootShell.exe. This process will initialise WinPE and once completed, it will run TsmBootStrap.exe from appropriate architecture directory that parses configuration found in X:\SMS\data\ and presents user with Task Sequence Wizard. It is worth mentioning that when troubleshooting issues you can hit F8 to open a Command Prompt window (assuming support for it has been enabled), make changes and manually re-run the executable to see if they bring desired outcome.
This is, in a nutshell, how WinPE behaves in most common configurations. While there is so much more that can be said about each one of them, it should give you a good starting point to understand inner works of WinPE!