you're reading...

Windows PE startup sequence explained

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!


13 thoughts on “Windows PE startup sequence explained

  1. thanks thats good info, I was wondering why the startnet.cmd was not doing anything in my sccm boot image.


    Posted by seb | 2018-01-12, 17:36
  2. I 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.


    Posted by SteveSi | 2019-01-08, 19:00
    • Not 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.


      Posted by Mietek Rogala | 2019-01-09, 11:14
      • The 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?


        Posted by steveSi | 2019-01-09, 11:29
    • Maybe 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)…


      Posted by HawkFest | 2021-08-03, 13:00
    • If 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…


      Posted by HawkFest | 2021-08-03, 13:04
  3. P.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.


    Posted by steveSi | 2019-01-09, 12:01
  4. P.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.

    Liked by 1 person

    Posted by steveSi | 2019-01-09, 13:08


  1. Pingback: Fix instant reboot in PE 10.0.15063.0 – stolpestad.net - 2017-09-19

  2. Pingback: Wireless Imaging (Task Sequence) in SCCM 2107. – Molloy Rocks - 2021-09-30

  3. Pingback: Resolved: Disable Network connection in Windows PE - Resolved Problem - 2022-04-01

  4. Pingback: Unfinished Document – Building a ConfigMgr Boot Image with Wi-Fi Support (Windows 10 ADK 1703) – jonkadmin - 2023-05-17

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s


%d bloggers like this: