Microsoft Windows Embedded Standard 2009 Developer Resource Kit Componentizing Windows xp professional for embedded systems developers

A walk-through of the windows boot process

1. 
   BIOS performs its Power On Self Test (POST).
   
2. 
   BIOS loads the Master Boot Record (MBR) into memory, and launches the code contained within (in real mode)
   
3. 
   The MBR boot code effectively results in the loading and launching of NTDETECT.COM and NTLDR. NTLDR loads and executes all of the critical boot devices. During this time the screen is blank.
   
4. 
   During the boot, Windows mounts and assigns drive letters according to following order:
   

• 
  First it uses letters for volumes that have reserved positions saved within entries in HKLM\System\MountedDevices\\DosDevices
  
• 
  Then it tries to find new volumes that don't have matching ID in both Volume, and DosDevice key groups. If the volume that matches this criteria is found, Standard 2009 assigns the first available letter and creates both Volume and DosDevice keys for it.
  
• 
  Next, Windows XP loads the rest of the operating system while the progress bar appears. Note that if you add the /NOGUIBOOT option to the boot.ini file, you will get a black screen instead of the Windows Embedded GUI with progress bar, until the shell loads, or until the user logon prompt appears.
  Example: In your boot.ini your ARC path would look something like this-
  
  multi(0)disk(0)rdisk(1)partition(1)\WINDOWS="Windows XP Embedded" /fastdetect /noguiboot
  
  See also the /bootlogo option discussed here:
  

The order of deployment of kernel mode and user mode objects frequently depends on the Plug and Play boot order and hence the exact load order varies.

You can inspect the setupapi.log found in the windows folder, for more information about Plug & Play activity.

During this window of time, the Windows XP Prefetcher can improve the overall boot time loading.

5. 
   The prefetcher uses adaptive algorithms which progressively improve boot time performance. For a Standard 2009 runtime, it is recommended that you boot the runtime, run the applications associated with the runtime, and then shutdown the system. Repeat this several times, until the boot time has stabilized to a minimum. Then mass deploy the runtime.
   
6. 
   The Windows XP prefetcher self optimizes based on idle time delays and other events such as:
   

• 
  has an optimization ever happened,
  
• 
  is there anything to do,
  
• 
  has it been done in the past 3 days. 
  

7. 
   If you clean install a machine, never let it idle and time the first or second boot, it will seem slow.  However, if you take that same machine and let it sit idle after a couple boots, it will self optimize based on idle time timeouts.  The optimize feature in bootvis simply triggers the same idle time events to happen without waiting for the timeout so that in a lab environment a solid repro can be built of a fully optimized system.  There is nothing special about the optimization triggered by bootvis vs. what happens based on idle time.  Further it is important to note that Windows XP is always self optimizing, it is not a onetime event to do based on a utility. 
   
8. 
   If you are using the Enhanced Write Filter (EWF) RAM-based overlay to protect your system volume, be sure EWF is disabled throughout this procedure, otherwise your reboots will have no effect on the prefetcher’s progressive performance because all information is lost each time the system is shut down.
   
9. 
   Once all of the above has completed, the shell is launched.
   

• 
  Minlogon: a minimum command shell is launched, along with LSASS and the Service Control Manager (SCM).
  
• 
  Windows Logon: the Windows shell is launched which is a superset of Minlogon.
  
• 
  Custom: a developer-specified customer shell is launched.