UEFI under Windows startup process

Boot file
After UEFI installs the operating system, Windows uses at least two partitions, one called the ESP partition (EFI SYSTEM PARTITION) to hold the boot file, and the other is the normal system partition under the BIOS, unlike the BIOS boot file is winload.exe,uefi boot file type Winload.efi, both are Pecoff format, but uefi with a variety of firmware interface, and the BIOS is using interrupts. Sometimes there will be an MSR partition, but this partition is not important and the experiment can be deleted.
When the installation is complete, Windows also writes the information of its own boot manager to the firmware's priority boot entry so that the firmware will boot the Windows Boot Manager by default during the BDS phase. By default, the UEFI firmware loads the startup file type Efi\boot\bootx64.efi (Bootia32.efi), and the Windows force-write startup item loads efi\microsoft\boot\ Bootmgfw.efi, these two files are actually identical files.
Registry key
After the system installation is complete, the Setup program will save the boot information in the BCD file in ESP, the path to the EFI\MICROSOFT\BOOT\BCD,BCD file is a registry nest file, the registration table is the Local_machine under the BCD00000000, In general, Hivelist does not import this file, we can manually import this file in Regedit to view. It is now possible to understand this file together with Bootice and regedit. Under object are all startup entry, each entry identified with a GUID value.

Each entry under a description and elements, where description is the description of the entry, and elements is a series of key-value pairs, where the key is represented by a number, such as 12000004 is the boot name, And 1100001 is the boot location information, this key value pair in Bootice in the expression bit to the right of the column.


Guided positioning
Now after analyzing this 1100001, after selecting the operating system to start, the boot Manager is the key-value pair from which to determine which partition to load Winload.efi. Open Diskgenius, click the System partition, look at its partition GUID, you can see that the 16 bytes at 0x20 is the partition GUID, and the beginning of the 0x38 16 bytes is the hard disk GUID.
In a UEFI system, various devices are identified using the device path, such as the path to the partition, which may be Pcicontroller ()/pci (0,1)/sata (0,0,0)/HD (2, Partition GUID, start address, end address).

For Windows loader, it only needs a device path that satisfies this condition to boot from that device: the second-to-last device is installed with Efi_block_io_protocol so that it can read the disk GUID and compare it to the value at 0x38. While the penultimate device is a partition device (Msg_dp_type), loader will determine the boot partition with the GUID of the device and the comparison in the registry, both of which match, then Windows will load a small NTFS file system, Then try to load 12000002 from that partition device, which is the boot file specified in Bootice applicationpath.
startup process
The Boot Manager (BOOTXXX.EFI) loads the BCD file first, reads all startup items from the BCD, and if there are multiple startup items and there is no default startup item, a menu is displayed, and when the user selects one of the startup items, the boot manager reads the WINLOAD.EFI from the corresponding partition (through the partition GUID) , if the winload.efi is not found at this time, or Winload.efi signature verification fails, it will be blue screen 0xc000000e, that is, the boot file cannot be found, after loading Winload.efi, control is formally given to Winload.efi.
The first thing Winload.efi do is to construct the page table and PFN database with the physical memory information provided by Bootservice Getmemorymap, and then Ntoskrnl,hal and system\ All boot drivers under the service and their required import library reads are loaded into memory, because this is still protected mode, so the mapping information for these files needs to be established in the page table. (after Uefi is turned on in ia32e, the paging is enabled by default, but the virtual memory and physical memory are 1:1 mapped, so it is not possible to use the original address after entering the Windows kernel), the files will be signed and verified if the checksum fails. Then the blue screen inaccessible_boot_device, that is, the boot device is invalid. When this is done, Windows will further initialize the GDT and IDT, then allocate the kernel stack in the page table and initialize the SYSTEMPTE. Finally call Exitbootservice to exit the boot stage, call setvirtualaddress to map the EFI part of the firmware memory to the virtual memory, and then load the page table base address into the CR3 register, Turn on paging and jump to NTOSKRNL's kisytemstartup to enter the kernel.

UEFI under Windows startup process