A Deep Dive into USB Boot

  • Article

4/24/2012

Microsoft Corporation

July 2009

Summary

This technical article contains advanced information about using a USB flash drive to boot Windows Embedded Standard 2009.

Introduction

Pre-Boot Phase

Post-Boot Phase

Driver Changes

Conclusion

Introduction

The following sections describe in detail the pre-boot and post-boot phases of using a USB flash drive to boot Windows Embedded Standard 2009. They also identify the changes you must make to the relevant components to support USB boot.

Pre-Boot Phase

Use the UFDPREP utility to prepare your USB flash drive (UFD).

The UFDPREP utility:

  1. Writes a Master Boot Record (MBR) to the UFD.
  2. Partitions the UFD into one or more NTFS or FAT32 partitions.
  3. Writes a boot sector to the first partition and prepares it for use.

The following figure shows the UFD partition layout.

Ee428799.4720763a-f22c-406f-9241-28fb7a047bee(en-us,MSDN.10).gif

The MBR contains the boot code and partition table needed to start the boot process. The BIOS reads, loads, and runs this boot code, which reads the partition table to locate the boot sector at the start of the boot partition.

The code stored in the boot sector searches, loads, and runs the NTLDR found in the root directory of the boot partition. NTLDR runs NTDETECT.COM, which calls the BIOS INT 13h Function 15h (Get Disk Type) routine at 80h to identify the boot device. NTDETECT.COM is modified to enable booting from removable media. However, if the BIOS function fails or returns zero (drive not found), then the UFD will not boot.

To verify that the BIOS is compliant and your UFD is prepared correctly

  1. Run the UFDPREP utility on your UFD to create the MBR and boot partition.

  2. Copy NTLDR, and the modified NTDETECT.COM to the boot partition.

  3. Configure the BIOS to boot from the UFD.

    When the message "Can’t find NTOSKRNL" appears, NTLDR has successfully identified the UFD as the boot device and the parameters are passed back to NTLDR.

Post-Boot Phase

In the next phase of the USB boot process, the post-boot phase, NTLDR will load and run NTOSKRNL (NTOS Kernel).

The kernel:

  1. Reads the boot device parameters found by NTDETECT.COM.
  2. Builds a boot-critical USB storage stack.
  3. Identifies the UFD as the boot device that is using the boot device parameters from step 1.
  4. Marks the UFD as the boot partition.
  5. Continues loading the remainder of the operating system from the UFD.

For the kernel to build a USB boot-critical storage stack, you must add Critical Device Database (CDD) entries in the registry so that kernel-mode Plug and Play will correctly identify the UFD as the boot device during kernel initialization. In addition, you must change the USB stack service keys and .inf files to boot-critical (service start-type zero). Figure 2 shows the USB storage device stack.

Ee428799.564c3fd9-586d-4cfb-b24c-0a464eb1f168(en-us,MSDN.10).gif

The USB stack is initialized as follows:

  1. NTLDR
  2. NTDETECT.COM (USB boot version)
  3. NTOSKRNL
  4. PCI.SYS (Bottom of storage device stack)
  5. USBEHCI.SYS
    • USBPORT.SYS
    • USBD.SYS
  6. USBHUB.SYS (USB boot version)
  7. USBSTOR.SYS (USB boot version)
  8. DISK.SYS (Top of storage device stack)
  9. USBD.SYS
  10. USB.INF (USB boot version)
  11. USBPORT.INF (USB boot version)
  12. USBSTOR.INF (USB boot version)

The CDD entries are added to the registry so kernel-mode Plug and Play can build a USB boot-critical storage stack. The USB 2.0 enhanced controller is bridged to the PCI bus. The PCI bus driver (PCI.SYS) is added to the CDD, as shown in the following example.

[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\CriticalDeviceDatabase\*pnp0a03]
"Service"="pci"
"ClassGUID"="{4D36E97D-E325-11CE-BFC1-08002BE10318}"

CDD entries for the USB 2.0 enhanced controller driver (USBEHCI.SYS) are shown in the following example.

[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\CriticalDeviceDatabase\pci#cc_0c0320]
"Service"="usbehci"
"ClassGUID"="{36FC9E60-C465-11CF-8056-444553540000}"

CDD entries for the USB hub driver (USBHUB.SYS) are shown in the following example.

[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\CriticalDeviceDatabase\usb#root_hub20]
"Service"="USBHUB"
"ClassGUID"="{36FC9E60-C465-11CF-8056-444553540000}"

[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\CriticalDeviceDatabase\usb#class_09]
"ClassGUID"="{36FC9E60-C465-11CF-8056-444553540000}"
"Service"="USBHUB"

CDD entries for the USB storage driver (USBSTOR.SYS) are shown in the following example.

[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\CriticalDeviceDatabase\usb#class_08]
"ClassGUID"="{36FC9E60-C465-11CF-8056-444553540000}"
"Service"="USBSTOR"

CDD entries for the generic disk driver (DISK.SYS) are shown in the following example.

[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\CriticalDeviceDatabase\gendisk]
"ClassGUID"="{4D36E967-E325-11CE-BFC1-08002BE10318}"
"Service"="disk"
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services]

The output in the following section demonstrates how kernel-mode Plug and Play builds the device stack starting from PCI.SYS up to DISK.SYS.

1) Searching for HardwareID:
PCI#VEN_8086&DEV_27CC&SUBSYS_01AD1028&REV_01
PCI#VEN_8086&DEV_27CC&SUBSYS_01AD1028
Searching Compatible Entries
PCI#VEN_8086&DEV_27CC&CC_0C0320
PCI#VEN_8086&DEV_27CC&CC_0C03
PCI#VEN_8086&DEV_27CC&REV_01
PCI#VEN_8086&DEV_27CC
PCI#VEN_8086&CC_0C0320
PCI#VEN_8086&CC_0C03
PCI#VEN_8086
PCI#CC_0C0320 (Compatible ID for enhanced host controller) USBEHCI.SYS
Critical Device PCI#CC_0C0320: Matched to Device pci#cc_0c0320.
Using ServiceName usbehci.(enhanced host controller)
Using ClassGuid {36FC9E60-C465-11CF-8056-444553540000

2) Searching for HardwareID:
USB#ROOT_HUB20&VID8086&PID27CC&REV0001
USB#ROOT_HUB20&VID8086&PID27CC
USB#ROOT_HUB20 (Hardware ID for USB 2.0 Root hub) USBHUB.SYS
Critical Device USB#ROOT_HUB20: Matched to Device usb#root_hub20.
Using ServiceName usbhub.
Using ClassGuid {36FC9E60-C465-11CF-8056-444553540000}

3) Searching for HardwareID entry: USB#Vid_067b&Pid_2515&Rev_0100
Searching for HardwareID entry: USB#Vid_067b&Pid_2515
Processing CompatibleIDs entries
Searching for CompatibleIDs entry:
USB#Class_09&SubClass_00&Prot_00
USB#Class_09&SubClass_00
USB#Class_09 (Compatible ID for enhanced host controller USBHUB.SYS)
Critical Device USB#Class_09: Matched to Device usb#class_09.
Using ServiceName USBHUB.
Using ClassGuid {36FC9E60-C465-11CF-8056-444553540000}.

4) Searching for HardwareID
USB#Vid_067b&Pid_2517&Rev_0100
USB#Vid_067b&Pid_2517
USB#Class_08&SubClass_05&Prot_50
Searching for CompatibleIDs
USB#Class_08&SubClass_05
USB#Class_08 (Compatible ID For USB Storage Device USBSTOR.SYS)
Critical Device USB#Class_08: Matched to Device usb#class_08.
ServiceName USBSTOR.
ClassGuid {36FC9E60-C465-11CF-8056-444553540000}

5) Searching for HardwareID entry:
USBSTOR#DiskCorsair_Flash_Voyager___1.00USBSTOR#DiskCorsair_Flash_Vo
USBSTOR#DiskCorsair_
USBSTOR#Corsair_Flash_Voyager___1
Corsair_Flash_Voyager___1
USBSTOR#GenDisk (Hardware ID For USB Storage DISK.SYS)
Critical Device GenDisk: Matched to Device gendisk.
Using ServiceName disk.
Using ClassGuid {4D36E967-E325-11CE-BFC1-08002BE10318}.

After the kernel initializes the boot-critical USB storage stack, the kernel uses it to match drive parameters found by NTDETECT.COM to storage devices. The kernel then identifies UFD as the boot device and marks it as the boot partition. The kernel then boots the remainder of the operating system from the UFD by using the USB storage stack.

Driver Changes

During the post-boot phase, the USB hub driver (USBHUB.SYS) was modified to require (wait for) the UFD boot storage device to be initialized.

During the post-boot phase, you cannot boot from the removable media. The USB storage driver (USBSTOR.SYS) is modified so that the first enumerated UFD appears as fixed media. This is necessary so that the boot UFD appears as fixed media to the user. The user must not eject or safely remove this device.

A paging path flag is set by the USB storage driver to support standby. Hibernation cannot be supported without major modifications.

Conclusion

What you have learned

To support booting from a UFD, you must make changes in the pre-boot and post-boot phases. Most of this work is to prepare the media and correct CDD entries in the registry. Changes to NTDETECT.COM, USBHUB, and USBSTOR.SYS make the boot UFD appear as fixed media, so the operating system recognizes it as a boot device. Adding standby support to USBSTOR.SYS requires only a minor change.