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 boot process is simply just a progression of small programs running in the correct order. Each will do its job and then start the next one in the sequence. Typically there will be 4 or 5 of them with the last one having the job of kick-starting the operating system – be that Windows, Linux or whatever. Many boot problems are the result of one program not being able to find the next one in the chain, so a knowledge of where each program is and the order in which they need to run can be extremely useful when you are configuring a dual or multiboot machine.

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 BIOS (basic input/output system) is the first program to run. It is located in a small chip on your computer's motherboard and is hard wired to be the first thing loaded when the machine is turned on. After it does its main job of bringing your computer to life it then has to hand over to the next program in the boot sequence. The BIOS is clever enough to look in various places for that next program and so typically you do not have to get involved, but you do have the option if required to set the BIOS search order so that it will look first in the place you want it to, be that a hard drive, CD/DVD, USB device or network. There will also be an option in most modern machines to manually halt the boot process and call up a bios boot-menu from where you can select which device you wish the BIOS to pass control to. The BIOS is the only one of our boot programs that is always completely OS independent and will start any Initial Program Loader it finds in the MBR of a hard drive.

---

The second program in the boot chain will usually be located on the first sector of the device that holds the operating system. The BIOS will only look on the first sector and load any program that it finds there. On a device like a hard drive this program is the IPL (Initial Program Loader) and it is just one part of what is called the MBR (master boot record) for that device. The other part of the MBR will be the PT (partition table), which the IPL may use to locate partitions and so the location of the next program in a boot sequence. The Microsoft IPL is a small affair who’s primary task is finding that next program, it only has to decide which is the boot partition on a drive and then it looks for and starts any boot program it finds on the first sector of that partition.

Active Partition.
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.

---

The third little program in our boot chain is at the very beginning of a partition. This one is commonly called the PBR (partition boot record) or even the VBR (volume boot record). The PBR has a few functions but all we need to know is that the boot program part of it will continue our boot sequence by finding and starting the next program in the chain. That next program will be specific to the operating system we have installed and so this means that the PBR will itself be OS specific because it needs to know the name and the location of the boot file it has to start. In our graphics above you can see that the PBR of an XP based OS will have to find and start ntldr, and the PBR of later Windows operating systems will be looking for bootmgr.

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.

---

The next program in the boot sequence is typically located in the root of the partition, which simply means it is not inside any other folders or directories. In legacy Windows this next file is ntldr and in new Windows it is bootmgr and both are bootmanagers that are capable of targeting and starting operating systems other than the one that may be on the partition they themselves are inside. These Windows bootmanagers will start the bootloader, which is the last program in the sequence and is the one that does the actual job of firing up the operating system by starting and loading its main boot and system files.

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.

---

The BCD (boot configuration data) store and the boot.ini file are not programs and so are not a part of the active boot sequence. They are however crucial because they are the data files that hold the information and directions for the Windows bootmanagers to do their job. If you look again at the graphics above you will see that both ntldr and bootmgr will consult their respective data files to be told the identity and the location of the bootloader or system files they should target. In the above examples there hardly seems a need for directions because the target files are right there at hand, but this is not always the case as you will see in other guides in this series, there are often situations where the target is on a different partition or even a different hard drive to the bootmanager. Both ntldr and bootmgr cannot make a move until they are told both the target and its location.

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.

 

---