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.
Windows PE startup process.
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.
Windows Setup
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!
Slightly Overcomplicated 
thanks thats good info, I was wondering why the startnet.cmd was not doing anything in my sccm boot image.
LikeLike
Posted by seb | 2018-01-12, 17:36I don’t think that the flow chart (or MS’s description) is correct – in standard Windows WinPEs %systemdrive%\sources\setup.exe exists (I assume by %systemdrive% they mean X: ???)
Therefore adding a winpeshl.ini or anything else should make no difference – setup should always run.
But if I add a winpeshl.ini then that runs.
LikeLike
Posted by SteveSi | 2019-01-08, 19:00Not exactly – %systemdrive% in this flow chart just describes the drive letter of the boot media (e.g. DVD), not the RAM drive (X:). But I agree this is confusing, as %systemdrive% variable will get assigned to X:, once WinPE is booted up.
LikeLike
Posted by Mietek Rogala | 2019-01-09, 11:14The flow chart says that if {[source-media]}\Sources\Setup.exe exists then winpeshl.exe will never, ever be run.
In other words you must delete \sources\setup in order to get winpeshl.ini to run – but that is incorrect.
If I add just a winpeshl.ini file, then that is run instead of setup.exe.
I think the flow chart should say if a winpeshl.ini exists then run it – else run setup?
LikeLike
Posted by steveSi | 2019-01-09, 11:29Maybe you’d have to create another partition where Windows setup stuff resides, and then have your customized PE point to it if you want to install Windows from it? I’m just asking, actually (I’m a noob with Windows PE)…
LikeLike
Posted by HawkFest | 2021-08-03, 13:00If you want your customized Windows PE to have a feature to install Windows, then maybe that you’d need to put Windows setup “stuff” onto another partition and have your Windows PE point to it, else if the setup files are present on the same partition as Windows PE then it will override your customized Windows PE? I don’t know I’m a noob with Windows PE but it would make sense out of that graph…
LikeLike
Posted by HawkFest | 2021-08-03, 13:04P.S. If I make a bootable USB drive from a standard Win10 Install ISO and delete \Setup.exe and \Sources\Setup.exe from the USB drive, then it still boots and runs Setup. The boot.wim #2 contains X:\Windows\System32\Winpeshl.exe but not winpeshl.ini. The startnet.cmd just contains wpeinit.exe command. Yet it still runs Setup.
If I delete \Setup.exe from inside boot.wim #2 image, then instead of setup running, startnet.cmd runs which runs wpeinit.exe and I get a command prompt.
LikeLike
Posted by steveSi | 2019-01-09, 12:01P.P.S. If \windows\system\winpeshl.exe is deleted, the system boots and then restarts.
Here is my best guess after experimenting with a Win10 boot.wim image #2 (#2 is the image used for installs)…
Winpeshl.exe is run (required file) – if winpeshl.ini exists the application(s) specified in X:\Windows\system32\winpeshl.ini are run.
If the winpeshl.ini file exists but is invalid, a cmd shell will be opened and the process will stop.
If winpeshl.ini does not exist then X:\Setup.exe is run, if it exists.
X:\Setup.exe allows the user to choose a language and then choose either Repair or Install – if you choose Install it runs X:\sources\setup.exe.
The \Sources\Setup.exe will look on all drives for a \Sources folder containing both the file “setup.exe” and a install.wim, install.swm or install.esd file in the same folder – if not found it will prompt you to install CD\DVD drivers. Windows can then be installed using the \Sources\install.* files.
If no winpeshl.ini file is found and no X:\Setup.exe is found then cmd /k X:\Windows\system32\startnet.cmd is run.
Usually, Windows PE’s boot.wim install images contain the X:\Windows\system32\Startnet.cmd file which just contains the command Wpeinit.exe.
Wpeinit.exe loads network resources and coordinates with networking components like DHCP. It also loads a wpeinit unattend XML file if it can find one at X:\Unattend.xml.
When Wpeinit.exe completes, the Command Prompt window is displayed.
The boot process of Windows PE is complete.
LikeLiked by 1 person
Posted by steveSi | 2019-01-09, 13:08Thanks for reporting your testing! And forget about my previous noobish reply that tried to make sense of the graph… :-)
LikeLike
Posted by HawkFest | 2021-08-03, 13:12Always wondered how Setup.exe (or maybe it’s the copied to destination Install.wim booting?) does several unattended reboots during the Win10 install process and picks back up where it left off? I’m guessing it records the current execution index before each reboot and on start it references that to move on(?)
LikeLike
Posted by Dgm44 | 2023-08-28, 00:17