An Illustrated Guide to the Boot Sequence.
The location and function of operating system boot files.
When configuring a multiboot machine it can be useful to have at least a basic grasp of how the boot sequence progresses. We don’t have to learn anything particularly difficult or technical to understand enough of what is going on to help us in making informed decisions. The general flow of the boot sequence is what concerns us the most and that is not a difficult thing to understand if we don’t confuse the issue with extra details that are not essential to our cause. Learning just the basics can still be useful and allow us to more clearly see what we can, and perhaps more importantly, cannot do.
This page is an introduction to the steps of a Windows boot sequence and to all the little programs that are typically involved in getting from computer turn on to the operating system being started. You will need to be familiar with most of the boot programs that are described below to follow the other guides in this series, so start with this article and then select from the links at the bottom of the page the ones you think will be relevant to your own situation or intentions.
The names of some of these boot programs are well known but don’t be scared away even if you have in the past thought they were entirely the preserve of experienced computer pros. All we need to be able to do is make sure they are where they should be and if necessary be able to adjust a few simple parameters that will help them find the next program in the sequence. For the most part we don’t have to know or care about any of the other things they might be doing while bringing our computer to life. The 2 illustrations below show the boot sequence and the programs involved in starting up Windows XP and Windows-7 on a typical bios based PC with a traditional MBR partitioned hard drive. The XP example could be any WinNT based legacy Windows OS, and the Win-7 example could equally be any new generation Windows since Vista.
For Windows-7 the boot sequence is:- BIOS - IPL - PBR - bootmgr - winload.exe --> Win-7
These bar graphics are just a visual representation of the way data is organized on a drive, whether that be the circular platters of a mechanical hard drive or the flash chips of an SSD, (solid state drive). The first small section is known as the MBR (Master Boot Record) and this holds the drive’s partition table as well as one of the small boot programs, which is the IPL, (initial program loader). The rest of the drive in the above examples is one single partition holding the entire Windows operating system. It is another convention of most operating systems that they reserve a tiny area that is inside and at the very beginning of their partition to house another one of those boot programs, the one known as the PBR, (Partition Boot Record). Windows has historically always reserved the first 16 sectors of its partition for the PBR.
The way the Microsoft IPL determines the boot partition is by simply looking for a marker that has been placed in the partition table to tell the IPL which partition it should choose. This marker is commonly called the Active flag, so setting or changing the Active partition is no more than moving a pointer that tells the IPL which partition it should pick. If there is no partition or more than one partition marked as active then the Microsoft IPL will stall and return an error message saying that the operating system cannot be found.
The Microsoft IPL will start any Partition Boot Record it finds on the boot partition of a drive, which makes it OS independent and so it can be used to start Windows or Linux or any other OS or software or bootmanager that has placed a functioning PBR in the correct location at the start of a boot partition. The IPL of some other operating systems such as Linux and those of third-party bootmanagers may however not be programmed to look for a PBR at all, but for a different boot file that could be located elsewhere on the drive.
A PBR is typically only written to a partition as part of the process of formatting it with the file system that the OS requires, which for Windows will usually be NTFS. A Windows install will normally do its own formatting and will write a correct PBR, but there are situations where Windows can be installed or copied to a pre-formatted partition which then won't have the correct PBR. For example if you format a partition from XP you will have a PBR that is set to look for ntldr. If you then install or copy a later Windows OS to that partition without re-formatting in the process the PBR might not be changed to one that should be looking for bootmgr. Changing a partition boot record.
During a typical Windows install it will be only the Active partition that will have its PBR written or re-written to accommodate the requirements of the operating system being installed. If Windows is being installed in a situation where there are separate System and Boot partitions then Windows will be going to the non-active Boot partition, which if already formatted will retain its current PBR. Under native Windows circumstances this won't however pose a problem as both the ntldr and bootmgr skip over the PBRs of Boot partitions, as you will see in later pages of this guide.
So the bootmanager is the program that decides or is told which operating system we want to boot and then starts the bootloader for that OS. Typically the bootmanager has the job of locating the bootloader for a particular operating system, which is usually to be found on the same partition as the operating system, which can often be on a different partition or even a different hard drive to itself, so the bootmanager needs to have an accurate and up-to-date internal map of a machine's drive and partition layout for it to be able to do its job. Even tiny changes to a machine's configuration can blindspot a bootmanager and prevent it from finding its target, which is why the bootmanager is perhaps the most crucial and most error prone aspect of any multibooting project. Anyone who wants to be in full control of their multiboot system really needs to be in control of their bootmanager and know how to configure and even repair and reinstall it when required.
The ntldr (NT Loader)
The ntldr was always an unusual beast in that it is in fact a dual function affair that combines in one program the jobs of both bootmanager and bootloader. So instead therefore of having to locate a bootloader for a particular OS the bootmanager part of ntldr has the job of finding the system32 folder of the target Windows operating system so that the bootloader part of itself knows where to direct its attentions. There is very little functional difference in having to find a Windows folder as opposed to a bootloader, so in practice it really just means that each legacy OS in a Windows multiboot machine has to share the same multi-function bootloader that has to work with any WinNT version it may encounter.
To help with the workload the ntldr delegates a few tasks to a file called NTdetect.com and may for certain hardware require a scsi disk driver file called ntbootdd.sys, or if a Win9x operating system is present a bootsect.dos file. All we have to concern ourselves with is that NTdetect.com is there sitting next to ntldr and that the others are present if required.
The new bootmgr (bootmanager)
In new generation Windows the twin roles of ntldr have been split out into separate programs called bootmgr and winload.exe - who's names are really self explanatory. The bootmanager can still be found in the root of the Windows system partition, but the new Windows bootloader winload.exe has been moved inside the Windows/System32 folder, right next to the files of the Windows operating system it will be tasked with bringing to life, so there should never be any issues with the bootloader not being able to find its operating system. Every install of new generation Windows now has its own dedicated bootloader inside its own partition, which is a definite improvement from old school Windows which had to share a general purpose bootloader. The functions of most of the support files that ntldr require have been incorporated into winload.exe.
If you use a Windows bootmanager to handle a dual or multi-boot system then the information held in the BCD and the boot.ini will be what makes your bootmanager work. Having a working knowledge of the data these files keep and how you can edit it may be essential if you are going beyond just a simple Windows dualboot. An understanding also of how a Windows bootmanager finds its target from the information it is given will be extremely useful in helping you appreciate why you can and cannot do certain things and why a third-party bootmanager may be a better choice for your situation.