If your E2B USB drive is of the 'Removable' type (e.g. a USB flash drive), then Windows Setup will automatically detect and use the \AutoUnattend.xml file located on the E2B USB drive (this is updated by E2B first). The special XML file causes WinPE to load the ISO as a virtual DVD drive (usually Y:) and thus Setup can access the \Sources\Install.wim source file on drive Y: and extract the Windows files from it. A special 'RunSynchronous' entry is required to be in the XML file.
If the E2B USB drive is not of the 'Removable' type, you can add a WinHelper Removable USB flash drive to the system. E2B will copy the XML file to this USB flash drive and Windows Setup will find it and load the ISO as a virtual DVD.
However, with E2B v1.A8+ it will now try to use 'wimboot' to run the Windows Install ISO first instead of relying on Windows searching for a Removable flash drive.
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 (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).
If you do not press a key when prompted to skip wimboot.
WIMBOOT will be skipped if NOHELPER is set and there is less than 800MB/1.5GB of RAM (WIN7/WIN8-2019) 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 - the E2B drive must be of the Removable type or you must add a WinHelper USb Flash drive - e.g. \_ISO\WINDOWS\WIN10\Win10 Home and Pro x64 1809 Oct English International (NoWimboot).iso. (E2B v1.B1+).
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. This file is usually present in all Windows Install WinPEs, however many other WinPE boot.wim files do not include this file.
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 of 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.
WIMBOOT does not require bootmgr to be present on the E2B USB drive.
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. WIMBOOT may not work if the boot.wim file has been made using non-standard compression tools.
Microsoft WinPE boot process description
The 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 lot with a Win10 boot.wim image #2 (#2 is the image used for installs)...
Winpeshl.exe is run (required file - must not be deleted) - 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.
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.
When Wpeinit.exe completes, the Command Prompt window is displayed.