WIMBOOT and the WinPE boot process

WIMBOOT is part of the iPXE project and works by loading one of the images inside the boot.wim file into RAM and then E2B will use it to inject the file winpeshl.ini and a batch file (e.g. startupe2b.bat) into the image. WinPE will then run the batch file via winpeshl.ini which will then load the ISO file as a virtual DVD and then run Setup.exe.

WIMBOOT will only be run by E2B if:

• the ISO contains a install.wim or install.esd file. (the boot.wim image must contain \Windows\Boot\PXE\bootmgr.exe).
• you do not press a key when prompted to skip wimboot (see screenshot above).

WIMBOOT will be skipped if set NOHELPER=1 is set in MyE2B.cfg and  there is less than 800MB/1.5GB of RAM present.

If the ISO file is under one of the \_ISO\WINDOWS\ folders and the filename contains ‘NoWimboot‘ (not case sensitive) then WIMBOOT will not be used – this means the E2B drive must be of the Removable type (unless Win10) or you must add a WinHelper USB Flash drive (unless Win10) – e.g. \_ISO\WINDOWS\WIN10\Win10 Home and Pro x64 1809 Oct English International (NoWimboot).iso.

Add the characters WIMBOOT to the filename if you do not want to be prompted with the ‘use WIMBOOT’ question and always use WIMBOOT (E2B v2.16+).

If the Microsoft Windows Install ISO is of the dual-architecture ‘both’ type  (32-bit + 64-bit) then E2B will ask you to choose ‘x86’ or ‘x64’.
If the CPU is detected by E2B as a 32-bit CPU, E2B will automatically use the x86 boot.wim file. 

Because WIMBOOT must load the large boot.wim image into memory, it may be slower than the normal non-wimboot boot process. WIMBOOT requires that the boot.wim image that is loaded includes the file \Windows\Boot\PXE\bootmgr.exe unless another bootmgr file is specified. This file is usually present in all Windows Install WinPEs, however many other WinPE boot.wim files do not include this file. WIMBOOT does not require bootmgr to be present on the E2B USB drive.
WIMBOOT also requires more RAM than the normal E2B boot method – you may see error messages from Setup or it may not run correctly if the system does not have sufficient RAM, skip WIMBOOT if the system has <2GB of RAM and does not seem to work correctly. 
Unlike the standard E2B method, WIMBOOT does not require special RunSynchronous lines to be added to the XML file. E2B will remove any RunSynchronous ‘LOADISO’ strings that may be present in the \AutoUnattend.XML file so that the LOADISO.cmd or LOADISONP.cmd batch files are not executed twice. 
E2B WIMBOOT only uses the LOADISO.CMD\LOADISONP.CMD, etc. files in \_ISO\e2b\firadisk.
If you have used a ‘special’ WindowsPE RunSynchronous .CMD file in your XML file then it may not work when using WIMBOOT (try Ventoy). 
WIMBOOT will also attempt to run startnet.cmd which is usually inside the boot.wim file – this may launch a custom interface, if a special custom ISO is used (e.g. Murphy’s All-In-One ISOs should work OK). 

If a Windows Install ISO is placed in a standard E2B menu folder (e.g. \_ISO\MAINMENU or \_ISO\WIN) then QRUN.g4b will try to execute the ISO using WIMBOOT and will run startnet.cmd and then Setup.exe (without any XML file specified – so for Win8/8.1 you will need to enter a generic install Product Key using the keyboard). If using WIMBOOT does not give the correct result then press a key when prompted to skip it, or convert the ISO to a .imgPTN file or try agFM or Ventoy.

WIMBOOT may not work if the boot.wim file has been made using non-standard compression tools. 

Description of the Microsoft WinPE boot process

The Microsoft WinPE boot process can be controlled by the presence of an X:\Windows\System32\Winpeshl.ini file or the presence of a X:\setup.exe file. Here is my best guess after experimenting with a Win10 boot.wim #2 images (#2 is the image used for installs)… 

The boot sector on the particular media is loaded. Control is passed to Bootmgr.

Bootmgr extracts basic boot information from the Boot Configuration Data (BCD) and passes control to winload.exe that is contained in Boot.wim.
Winload.exe then loads the appropriate Hardware Abstraction Layer (HAL), and loads the System registry hive and necessary boot drivers. After it finishes loading, it prepares the environment to execute the kernel, Ntoskrnl.exe.

Ntoskrnl.exe is executed and finishes the environment setup. Control is passed to the Session Manager (SMSS).
SMSS loads the rest of the registry, configures the environment to run the Win32 subsystem (Win32k.sys) and its various processes. SMSS loads the Winlogon process to create the user session, and then starts the services and the rest of the non-essential device drivers and the security subsystem (LSASS).

WinLogon.exe reads the registry entry path at HKLM\System\Setup\CmdLine which points to Winpeshl.exe by default…

1. Winpeshl.exe is run (Windows PE Shell – a required file – must not be deleted) – if winpeshl.ini exists any 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.
2. 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.
3. If no winpeshl.ini file is found and no X:\Setup.exe is found then cmd /k X:\Windows\system32\startnet.cmd is run.
4. Usually, Windows PE’s boot.wim install images contain the X:\Windows\system32\Startnet.cmd file which just contains the command Wpeinit. 
5. Wpeinit.exe loads network resources and coordinates with networking components like DHCP.
   It also loads a X:\Unattend.xml file (if it exists) to process settings such as firewall, network and display settings.
6. When Wpeinit.exe completes, the Command Prompt window is displayed.
7. The boot process of Windows PE is complete.

Note: E2B and Ventoy work by injecting a winpeshl.ini file which runs a batch file. Ventoy works in a better way, it replaces the winpeshl.exe file with a file of the same name but which loads the ISO as a virtual DVD – it then runs the original copy of winpeshl.exe. This means that the start-up files are not altered at all (winpeshl.ini is not changed).

Some flow charts (not 100% correct – see above for true picture!):

https://slightlyovercomplicated.com/2016/11/07/windows-pe-startup-sequence-explained/
https://www.it-connect.fr/presentation-de-winpe/#ALe_processus_damorcage_de_WinPE

Wimboot and UEFI

agFM and Ventoy both use wimboot (grub2). In particular, Ventoy uses a faster and cleaner method of booting WinPE. When it works, it works nicely, but you may discover compatibility issues on some systems.