A simple note on how to repair bootstructures.

Date : 05/05/2018
Version: 0.5. Almost done.
By: Albert van der Sel
Remarks: It's a simple note on how you might repair primary bootstructures on Windows.

Please refresh the page to see any updates.

How can you repair bootstructures, possibly corrupted by "malware", or by some other failure?

In this small note we will see some very "lightweight" pointers, on how to repair this.
This note is geared towards "physical machines", with one or more Windows versions installed,
like on a laptop, or on a PC (and it's not about repairing virtual machines).

There exists a lot of "rescue" type of software, which you can get as DVD, or download and
burn it yourself, like "Hirens", "Kaspersky", "Knoppix", "Ultimate Boot DVD", "GParted", and many others.
They are indeed fantastic tools. You really should consider to obtain a selection of those.
They allow you to boot, after an unrecoverable crash, and rescue data, or even repair bootstructures.

So, a few of these tools must be discussed in this note too (in a lightweight fashion). See chapter 8.

However, the main focus of this note is to understand those bootstructures in the first place,
and use Windows standard commands plus tools, which can affect the bootprocess, and perform repairs.

IMPORTANT:

(1): If you like to perform tests, do it on a test machine. This sounds absurdly trivial ofcourse.
Indeed, certain actions might indeed be risky. Never do something with bootstructures
on an important (production) machine, unless you have no choice.

(2): If you suspect, or found clues, that points to a rootkit (bootkit) malware, which is responsible for the crash,
then check your AntiVirus manufacturer too, for (possible) procedures or "tips".

(3): Any tip or command, listed in this, or any other note, must be crosschecked with other sources.

(4): If you have a multiboot machine (physical host), which can also boot to a NON-Windows Operating System, like Linux,
then be VERY CAREFUL with information of this note. This note focusses purely on Windows, or multi-boot Windows systems.

Maybe the upper seems a bit exaggerated, but it's really not.
Indeed, this note is just a bunch of simple pointers, and not a "crisp and clean" handbook to perform repairs.

Main Contents:

Chapter 1. Birds eye view on the Boot sequence of Windows.
Chapter 2. How to check if your system uses BIOS/MBR/VBR or EFI/GPT.
Chapter 3. Bootmgr and BCD.
Chapter 4. Special partitions (Like "Recovery").
Chapter 5. Creating Bootable media (Repair DVD, USB with Windows PE).
Chapter 6. UEFI and BIOS/MBR.
Chapter 7. Recovery using standard Windows tools and Well know error messages.
Chapter 8. Popular (Third party, or Opensource) Boot/Rescue Software.

Appendix.

Chapter 1. Birds eye view on the Boot sequence of Windows

Typically, for the (pratically obsolete) systems as XP or Win2K3, was to use a BIOS/MBR bootstrap method.
Indeed, the older partition styled disks, are often called "MBR" disks.
Most of those older Operating Systems did not yet supported the newer (UEFI) GPT diskformat for booting.

UEFI (or EFI) needs the newer GPT style of diskformat (or actually "disk metadata").
As of Vista, Windows (64) supports UEFI, and for systems like Win10, or Win2K12, Win2k16, the use
of UEFI (or EFI as more often called) as the primary bootstrap, is reasonably common.

However, even with modern systems, it still might be true that you must use the former MBR type of diskmetadata,
for some reason. Or maybe your machine is simply a BIOS machine only.

Most modern hardware can be configured to use either EFI, or a slightly adapted BIOS (with certain extensions),
whereas the latter enables you to use the older style MBR format, for installing the Operating System.

A birds eye view on the several possible bootsequences of various types of Windows (older versions and newer versions),
is shown in the figure below.

Fig 1: Just some simple illustrations of Windows bootsequences.

The sequences are ofcourse much more involved then what is shown above.
The figure then only serves to provide an impression.
However, a basic understanding of the Windows boot is important, also if you want to attempt repairs
of the bootprocess.

For the UEFI based boot, and modern systems, stuff goes "roughly" like this:

UEFI firware activates, and it goes through a number of stages, like a PEI, DXE phases etc..,
which are not of interest to us.
When UEFI is "up", it goes to the BDS module (Boot Device Selection), while a EFI System Partition (ESP)
is mounted too. The BDS comes from NVRAM. The ESP contains possibly various subfolders, with
pre-boot loaders for optionally various Operating Systems.
So, there might be a \EFI\RedHat\ and a \EFI\Microsoft\ folders present, and optionally others as well.
In case of Windows, we have the "\EFI\Microsoft\Boot\bootmgfw.efi" bootloader on the ESP.
The BDS module might present a "boot menu", or is configured for an "autoboot", and it's
possible too to evoke the "EFI shell" fs(0)> prompt.
Microsoft calls "bootmgfw.efi", the "firmware boot manager" or "Windows boot manager".
Next, the "Bootmgr.efi" is called, which manages the socalled BCD store, and enummerates
all possible bootoptions (post EFI).
Next, "Winload.efi" is called, which is finally responsible for loading and activating the
Windows kernel and other critical components.
API's and services are putting "alive", like ntdll, SMSS, CSRSS

So, in short:

=> For the UEFI boot, and modern Windows systems, stuff goes "roughly" like this:

UEFI phases -> BDS/EFI System Partition (menu, autoboot, shell) -> \EFI\Microsoft\Boot\bootmgfw.efi ->
Bootmgr BCD store + enummerations, optional bootmenu ->
OS loader \Windows\system32\winload.efi -> NTOSKRNL -> Services + API's.

=> For the MBR/BIOS boot, and modern systems, stuff goes "roughly" like this:

BIOS -> MBR -> Volume Boot Record -> Bootmgr BCD store + enummerations, optional bootmenu ->
OS loader \Windows\system32\winload.exe -> NTOSKRNL -> Services + API's.

=> For older systems, it holds that BIOS/MBR is (mostly) used (XP, Win2K3, and earlier). Stuff goes "roughly" like this:

BIOS -> MBR -> Volume Boot Record -> NTLDR (boot.ini to present bootmenu) -> NTOSKRNL -> Services + API's.

IMPORTANT:

As we will see later in more detail, UEFI uses a seperate "EFI System Partition" (ESP). But this can coexist with an MBR/VBR structure
as it was in the older boottype.
If the UEFI pre-boot is in effect, it fully ignores any MBR/VBR bootsructures, and simply follows the path
as shown in figure 8 below. At a certain moment UEFI is up, and uses it's ESP and Bootmanager (possibly with an autoboot to Windows).

In fact, on many (Intel or Intel-like) UEFI systems, a user can switch to a BIOS-CSM (emulation), so that the traditional BIOS/MBR/VBR
initial boot, is in effect again. If the BIOS-CSM (emulation) allows it, you can switch back and forth again.

Note: On certain platforms, like Itanium, even Win2K3 could use an EFI boot. So, the distinction presented above,
is not entirely "black and white": it is less rigid than the text above might suggest.

Done...

Chapter 2. How to check if your system uses BIOS/MBR/VBR, or EFI/GPT

First, It's important to know what type of Windows boot environment is used by your system(s).
Remember that in general, we have several types of machine environments.

1. Physical computer: using the legacy BIOS/MBR/VBR sequence.
2. Physical computer: using the newer EFI boot sequence.
3. Virtual Machine: often using a virtualized "Manufacturer emulated" BIOS/MBR/VBR sequence.

The question if a machine supports EFI, is not only an Operating System issue. For example, the type of CPU and mainboard, is
often a more decisive factor.
In practice however, nowadays, most new machines are implemented with EFI.

- Note that for older systems, like XP, or Win2K3 Server, usually the BIOS/MBR is implemented.
- Newer systems like Win10, Win2K12, Win2K16 might use either EFI or BIOS/MBR but usually it's an EFI implementation

As we will see later, UEFI uses a seperate "EFI System Partition" (ESP). But this can coexist with an MBR/VBR structure
as it was in the older boottype.

In fact, on many UEFI systems, a user can fallback to a BIOS-CSM (emulation), so that the traditional BIOS/MBR/VBR
initial boot, is in effect again.

2.1 So, how do you know what type of boot your machine uses?

From the modern Windows versions, you can even check this within the GUI, from the 'Settings' menu.
From there, you can walk on to "Advanced Options" (in my view, it's not always very obvious how to get there).
Basically, on a UEFI system, figure 4 below (right side) would (likely) show an additional option to boot to UEFI firmware.

Here are several other methods, that can be used as of Vista/Win7 up to Win10/Win2K16.

Method 1:

From a (elevated) command prompt, run:

C:\> bcdedit /enum

-If you get back records like:

path..................\EFI\Microsoft\Boot\bootmgfw.efi (note this line)
path..................\Windows\system32\winload.efi (note this line)

Then your system uses EFI.

-If instead you see:
path..................\Windows\system32\winload.exe (note this line)

Then the machine uses BIOS/MBR.

Method 2:

You might check to contents of the "C:\Windows\Panther" directory (if present on your system).
Ofcourse, Windows might be installed in another partition, like D:\Windows. Obviously, then use that path.
The "panther" folder stores setup logfiles. But it's not garanteed that it's indeed present.

C:\>cd windows
C:\windows>cd panther
C:\windows\panther> dir setupact.log

This should indeed show the setupact.log logfile. But, it can be quite large. Often, it's unpractical to use notepad.
In that case, simply use a command like:

C:\Windows\Panther> type setupact.log | find /I "Detected boot environment"

But you might also try (if the log is not too large):

C:\Windows\Panther> notepad setupact.log

and then search for "Detected boot environment".

If you find something like this:

2018-01-20 17:28:07, Info IBS Callback_BootEnvironmentDetect:FirmwareType 1.
2018-01-20 17:28:07, Info IBS Callback_BootEnvironmentDetect: Detected boot environment: BIOS

Then your system uses the legacy BIOS. Otherwise the "Detected boot environment" will be shown as "UEFI".

Method 3:

This time, using graphical stuff only, goto "Administrative Tools", then "Computer Management", then "Disk Management".
An EFI partition is typically 100MB, or 300MB (or something in that order), and it should be the first partition
listed on "Disk 0". However, it is possible that the Computer Manufacturer has placed a "Recovery Partition" as well,
which might show as the "first" partition.
The Disk Manager should display "EFI Partition" for that first partition. However, depending on your system,
this is not always true. Maybe you only see a (manufacturer provided) "Recovery Partition".
Then, revert to "method 1" or "method 2" above.

Method 4:

This is close to Method 3.
If Windows "itself" (%SYSTEMROOT%), is installed on a GPT disk (partition), you have UEFI.

Method 5:

Almost immediately after "power on" of a PC or laptop (or other device), for a very brief moment, there might
be a message "Press xx key to enter Setup" or similar message. This might be the F2 key, or F10, or some other key.
Usually, this will bring you to the BIOS setup program. In some cases, this setup program might show you to eiher to
"enable UEFI boot" or stay at the "(legacy) BIOS boot".
If (in such menu system), do do not see any reference to UEFI, then it's safe to say that your device uses legacy BIOS.

Be aware, that if already an Operating System is installed, then do not change the boot behaviour with respect
to UEFI or BIOS. Leave the settings as they are now. Use this method (for now) only for investigation purposes.

Boot to UEFI Firmware Settings from inside Win10:

If your system indeed would have UEFI, then the "shutdown" command (on Win10) has an option to reboot to the UEFI firmware User Interface.
If you have legacy BIOS, that option would not be available. It simply returns an error message. In the latter case, you might try:

(from an elevated CMD prompt session:)

C:\> shutdown /r /fw /t 0

Booting to firmware UI is not supported on this system.

Unfortunately, the "/fw" firmware switch, seems to be available only on Win10 / Win2K16,

Note: By using the prompt command "shutdown", you can reboot, or shutdown, your system.
"shutdown -r" will reboot, and "shutdown -s" will shutdown. The parameter "t 0" means: "now".
Using "t x" means a delay of "x" seconds. And ofcourse, "/fw" means: go to firmware menu (on Win10).
By the way, you can either use "/" or "-", as parameter indicator.

2.2 Other tools

We can also use the low-level utility "diskpart". This powerful tool can do a lot of stuff.
See section 2.3.

=> "msinfo32", "systeminfo", "dxdiag", "wmic" prompt commands.

None of these commands are especially geared towards bootinfo. However, each of them
provides partial information on disks and BIOS, which you can use to collect information
of your system.

For example, msinfo32 would usually show you "BIOS mode: UEFI", or "BIOS mode: Legacy", among lots of other info.
However, it is not garanteed that msinfo32 gives the same info on different Windows versions.

For example, using "wmic", you can collect lots of system info like in:

C:\TEMP> wmic bios get biosversion

Now, ofcourse, Powershell comes to mind too! Maybe you like to search for some
informative Powershell CmdLet's, or scripts, which gives to UEFI and/or BIOS info.

=> "diskmgmt.msc".

You can also take a look at all disks and partitions (and check their labels en see if driveletters are assigned),
by using the Graphical utility %SYSTEMROOT%\system32\diskmgmt.msc (like C:\Windows\System32\diskmgmt.msc).
This graphical tool shows you all disks, and partitions that your system may have.

If you rightclick a disk (not a partition), and see it's properties, you should be able to see whether
it uses MBR metadata, or GPT (GUID Partition Table) metadata.

MBR and GPT will be explained in Chapter 6.

2.3 A DISKPART session.

Suppose you see some smaller partition, (and it's not the common C:, and others as D: etc..), you might wonder
if it's an EFI System Partition. Usually, it has no drive letter assigned, but you still might take a look over there.
If you indeed would use the procedure below, then it is ofcourse understood that you will not make any alterations:
That is: We are only going "to take a look" in that partition.

If you feel uncomfortable using "diskpart", then skip the subsection below. Simply just read it.
Maybe you system "looks" a bit like the example below. You can just try the same steps below.

(start an elevated command prompt session, having Admin rights)

C:\TEMP> diskpart

DISKPART> list disk
DISKPART> select disk 0
DISKPART> list partition

(suppose the output is like this:)

DISKPART> list partition

Partition.. ###..Type..........Size
Partition.. 1....Recovery......400 MB
Partition.. 2....System........300 MB
Partition.. 3....Reserved......128 MB
Partition.. 4....Primary.......237 GB
Partition.. 5....Primary.......206 GB
Partition.. 6....Recovery......21 GB

Partition 2 is 300MB in size, which is what to be expected (more or less) from an EFI System Partition.
So, mybe that's the one we are looking for. Let's go on:

DISKPART> select partition 2
DISKPART> assign

DiskPart successfully assigned the drive letter or mount point.
DISKPART>exit

Now, we have a driveletter assigned to Partition 2. In my case, it turns out to be "F:".
Let's take a look over there:

C:\TEMP>F:
F:\>dir

03/14/2013 04:27 PM DIR EFI

F:\>cd EFI

F:\EFI>dir

03/14/2013 07:45 PM DIR Microsoft
03/14/2013 07:45 PM DIR Boot
03/14/2013 07:45 PM DIR OEM

F:\EFI>cd Microsoft

F:\EFI\Microsoft>dir

03/14/2013 07:45 PM DIR Boot

F:\EFI\Microsoft>cd Boot

F:\EFI\Microsoft\Boot>dir

06/26/2012 06:05 PM.........4,186 boot.stl
04/29/2018 01:36 PM........32,768 BCD
07/25/2012 10:12 PM.....1,354,480 bootmgfw.efi
07/25/2012 10:12 PM.....1,350,896 bootmgr.efi
07/25/2012 10:12 PM.....1,263,856 memtest.efi

Take notice of the BCD directory, and the Bootmanager "bootmgr.efi" for UEFI systems.

Done...

Chapter 3. bootmgr and BCD.

3.1 The BCD store.

What is the BCD store?:

Indeed, since Vista, we are dealing with "BOOTMGR" and the BCD store.
BCD stands for "Boot Configuration Data".

=> In the old XP/Win2K3 period, and earlier versions before those versions, we had NTLDR as the loader
of the Operating System.
But you could have 2 or more Windows versions installed on your machine, and using "boot.ini",
(a simple flat ascii file which listed all versions including their paths), made it possible that
NTLDR presented you a bootmenu first, from which you could choose which instance to start.

=> In more modern versions of Windows (such as Win7, Win10 etc..), the BDC store has a similar role.
It's a registry of all installed Windows versions, including some properties as their systempaths.
However, this time the BCD store is somewhat more complex, and it's a binary file, instead of
just a simple ascii file (as boot.ini was in the XP/Win2K3 days, and earlier versions of Windows).
It's probably reasonable to say that the BCD store is a "namespace container for BCD objects" which
holds startup data for Windows systems. In a way, this file makes the Windows boot more independable
from EFI firmware, and strict UEFI specifics.

You are supposed to use some specific interfaces to the BCD store, as for example the prompt command "bcdedit".

Where is it located?:

=> BIOS/MBR:

-If you do not have, or not use, UEFI, but instead use the BIOS/MBR bootstrap, then the BCD store
is located in the systempartition, in the "\boot" folder. For example "C:\boot".
This latter location is likely to be true if you would have only one disk. Key point is, that
the "\boot" folder is stored on the "system partition", while the Windows directory itself might
be located on for example D:, or E: etc.. (such as E:\Windows etc...)

=> UEFI:

-If you use UEFI (also abbreviated by EFI), then the the BCD store is located in \EFI\Microsoft\Boot,

In all cases, the BCD store closely resembles more the format of a "Registry Hive", including the hierarchical
structure with Objects and Elements.

On UEFI, BOOTMGR "must" actually use EFI services to open and read this object, and get knowledge of the objects
registered in this repository.

3.2 Example contents BCD.

you can compare the structure of BCD, with a root container (object), containing other containers (objects), very similar
as to a directory structure, having a root directory with subdirectories.
Or, if you like, it's very similar to a registry key (folder), having subkeys (folders) with values.

-If you have only one modern OS installed, BOOTMGR will not display a bootmenu. But there will be a certain
(small) time interval (timeout) before control is passes to the default (and only) WINLOADER.

-If you have 2 or more modern Windows (Vista or higher) versions installed, then BOOTMGR will
(per default) show you a bootmenu from which you can start the desired Windows instance.

- If your machine initially used XP or earlier, then (in case of BIOS/MBR), the BOOTMGR will still
enable you to go into the "legacy" boot of XP (using NTLDR and boot.ini etc..).
(Ofcourse, I know that XP is "antique" by modern standards, but I want to show how BCD works).

So, suppose you have 2 modern Windows versions stalled, and one older (legacy) system like XP.
Then the BCD store has a structure similar as to:

Fig 2: Just a very simple illustrations of the BCD store (2 modern OS, 1 legacy OS).

3.3 Displaying the contents of the BCD Store.

Commandline:

There are a few "native" prompt commands in Windows systems (as of Vista), which let you view
and manage the content of the BCD store. For example the "bcdedit" command, which should be
present on any modern Client- or Server system.

So if you would use the "bcdedit" command, do not expect to see the hierarchical output as shown in figure 2.
You get "serlalized", and grouped, output of the Boot Manager object, the Operating system object(s),
and all "elements" grouped together belonging to such object.

From an elevated (Admin rights) prompt, try the following three commands:

C:\TEMP>bcdedit
C:\TEMP>bcdedit /enum all
C:\TEMP>bcdedit /v

The "/v" and "/enum all" options (switches/parameters), show more output, then just the bcdedit command by itself.
It should be noted that "bcdedit" knows a large number os switches, mainly to manage (alter) the BCD store.

GUI (third party):

However, there also exist Third Party graphical tools to view and manage the content of the BCD store.
Their "look and feel", is often much like the Registry Editor, which shows you "keys" (folders) and values.
For example "Visual BCD", and several other tools are available. Most of them are often not "free".

Here, I will not go into those (non-standard) graphical tools. But it's important to know, that such tools exist.
I agree that such a tool might give you quite some "extra's". If interested, do an extensive Web search,
also to find out if such tool is tested thorougly on EFI too, and if it's trusted enough, for you to use it.

Fig 3: Simple illustrations of Visual BCD.

Done...

Chapter 4. Special partitions (Like "Recovery", "OEM" etc..).

4.1 Recovery Partition (WinRE partition):

Many "new" Laptops or PC's, from major Manufacturers, will already have a Windows version pre-installed.
At least, in the US and many countries in Europe, this is often true.

Ofcourse, you can also buy a true "bare metal" machine, with no software installed at all.
Having Windows installation media, then you can install the OS yourself (or another OS ofcourse).
Booting from install media, then sets you off into the installation.

Whatever your situation may be, it might be true dat you have a "recovery" partition on your
disk, which often is labeled "Recovery". It might only be around 15G in size, or even much smaller.
In other cases, you may see a label as "WinRE" or "WinRE tools".

This Partition contains Windows RE (WinRE), based on Windows PE, in a packed format, which can be
initiated and run from a RAM disk.
Windows PE is a very thin OS, only containing the basic bootobjects, kernel, API's, and tools.
The purpose is that it can repair common causes of unbootable operating systems.

If Windows is installed (e.g. by Manufacturer) using the scoalled "media created from Windows Imaging and
Configuration Designer (ICD)", a WinRE partition will be created on both UEFI and BIOS-based devices.

If during the regular boot of your machine, a fatal error is detected, the bootmgr may
start Windows RE, and present you a menu with recovery options (depending on the Windows version).

Fig 4: Simple illustration of the bootmenu of WinRE.

The Recovery menu will appear, under various circumstances. One is, if a critical component
of the regular Windows installation is damaged or missing. Or, after 2 (or 3) consecutive failed attempts
to start Windows. There are also many "manual" interactive ways to enter the WinRE Recovery menu.

One other thing to note is, one of standard entries in the BCD store. One points namely to WinRE
and it's recovery menu.
On your system, you might again try the "bcdedit /enum all" command. In that case, you should be able
to see all BCD objects and elements (see Chapter 3).

If I perform it on a Windows 10 machine, one part of the output is shown below:

C:\TEMP>bcdedit /enum all

..
(just an example)
(Lots of Output...)
..
identifier...... {876fd0f0-fdfe-11e7-9c09-a495dd0890af}
device.......... ramdisk=[G:]\Recovery\WindowsRE\Winre.wim,{876fd0f1-fdfe-11e7-9c09-a495dd0890af}
path............ \windows\system32\winload.exe
description..... Windows Recovery Environment
displaymessage.. Recovery
osdevice........ ramdisk=[G:]\Recovery\WindowsRE\Winre.wim,{876fd0f1-fdfe-11e7-9c09-a495dd0890af}

Do you notice the 'Description: Windows Recovery Environment" in the output above?
As you may notice too, the "Winre.wim" will be unpacked and executed from a initiated RAM drive,
while it was loaded from the Recovery partition.

Chapter 5. Creating bootable media: Repair DVD, and a USB with Windows PE.

In this section, we are going to see:

How to create a "Repair" or "Recovery" DVD, using standard facilities of Windows.
Next, we will create a bootable USB drive, on which we will install a "mini" Windows, namelijk WinPE.
Lastly, we will make a bootable Linux DVD (Live DVD). Modern Linux distro's, today have an excellent
GUI which you can use to easily use to transfer files from a good harddisk partition, to (for example) a USB disk.

With (1) and (2), you will have the standard "repair" options, and for example also a command prompt which you can use to copy
files to other media (like USB or DVD etc..).
With (3), you have (at least) the option to salvage files from your harddisk (partitions), to other media.

In my view, (1) and (2) are the most interesting ones, since it allows us to try a Graphically "initiated" repair,
or start a command prompt, to enter rather advanced commands to repair bootstructures (like bcdboot).
This will be the subject of chapter 7.

4.1 A note on creating a Recovery (Repair) DVD:

Sure, USB is taking over (or already did) from portable Disk media, like DVD.
In 4.2, we will see how to create a bootable USB with Windows PE.

But, having a bootable DVD with repair options is great too.

In modern Windows systems, you can create a Recovery (Repair) DVD, from which you can boot
in case of problems, and which gives you most repair options as shown in the former section.

Depending on the version, in Control Panel, or System Management, you should be able
to locate the Backup/restore applet. It also provides the option to create a bootable Recovery DVD.
Just take an empty DVD (e.g. DVD-R), and follow the simple instructions. See figure 5.

If someone is indeed reading this note, then please create this DVD, because of an excercise
in Chapter 7.

Win10 example for creating a Recovery (Repair) DVD:

In Win10, you should be able to find such an option rather quickly from a Backup/restore applet
in Control Panel. See figure below.

Fig 5: How to create a Recovery DVD in Win10.

Win7 / Win8 example for creating a Recovery (Repair) DVD:

You might have to look around a bit on your system, but in this Win7 example, I found the option
to create a system repair disk (or Recovery Repair DVD) in the applet "Windows 7 file recovery". See the figure below.

Fig 6: How to create a Recovery DVD in Win7 / Win8.

The reward of having such DVD is illustrated in figure 4. For example, you can choose for "Startup Repair",
in which case the code on the DVD will inspect the bootstructures, and (hopefully) is able to repair it.

As another option, you can choose for the "Command Prompt". This is very valuable, since using
the simple prompt interface, you can save files, or use some special commands to repair bootstructures.
This is a sunbject in Chapter 7, and there we will see some simple examples to copy your valuable datafiles
to another storage object like an USB disk.

4.2 A note on creating a a bootable USB with Windows PE:

In this subsection, we will create a bootable USB with Windows PE. This example is based on Windows 10.

Windows PE (or WinPE, and a similar OS called WinRE), is a "Thin OS", with basic functionality, like
having a kernel, NTFS/FAT drivers, mass-storage drivers, networking functionality, and some API's.
What's more, after the PE boot, it runs from a RAM disk in memory. So, you could even change the USB,
for another USB stick.

In case your machine seems completely lost, you might boot using this USB stick, and access
Disk partitions which are still good, to save data.

Step 1:

Make sure you have a (reasonably modern) USB stick of sufficient size, like 6GB or 8GB.

You do not need to use DISPART to create partitions, or do anything else with this USB.

Step 2:

Download the Windows 10 "Deployment tools and Windows Preinstallation Environment".

For Windows 10, you might try (I hope that this link remains valid...):

Download and install the Windows ADK.

You can select what to download, but in fact the Windows Preinstallation Environment is good enough.

Step 3:

We are next going to use a few commandline scripts. The first one ("copype") will create a directory on your harddisk
and copy/unpack the neccessary files to that directory.
The second one ("MakeWinPEMedia"), formats the USB stick, writes a bootrecord on the USB, and copy the neccessary files
(from that directory which "copype" used) on that USB drive. That's all, actually.

Remember, this example is for Win10. For Win8, Win7, it's quite similar, but not entirely the same procedure.

From the "Start menu", run "Deployment and Imaging Environment" icon.
Basically, it starts a CMD prompt, but some essential environment variable are set too.

From this location (in my example, it can be slightly different in yours):

C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment>

Run:

copype x86 c:\winpe

In my case I have x64 machines, but in the mindset of "copype", x86 and x64 is all collected in the parameter "x86".
Also, on the commandline I told "copype", to place the objects in "c:\winpe".

After "copype" is ready, next run:

MakeWinPEMedia /UFD c:\winpe H:

where (in my case) H: is the drive letter associated with the USB drive.

In the "MakeWinPEMedia" session, we will see:

WARNING, ALL DATA ON DISK DRIVE H: WILL BE LOST!
Proceed with Format [Y,N]?Y
Formatting H:...

Setting the boot code on H:...

Copying files to H:...

Success

So, we managed to create a bootable (Win10 based) "Windows PE" environment, which will boot
into a graphical "mini" Windows, which per default will also start a cmd window.
It's pretty cool to have a bootable USB, with full disksupport.

In case you have a BIOS machine, (or BIOS/UEFI machine), in setup, you can change the order
of bootable devices. For testing purposes, you can put USB as the first bootable candidate.

4.3 A Linux bootable (Live) DVD:

Nowadays, it's easy to download a Linux ".iso" file, which you can burn to a DVD.
This DVD then (most often) is bootable, and you can start a Linux distro from DVD.
Such downloads are also often called: an .iso file for creating "Live DVD".

Most distro's today have such an easy GUI, with filemanagers, which can readily access your
FAT/NTFS harddisk partitions (like C:, D: etc..). This way, you can always copy files from your harddisk
to other media, in case of "misery".

Today, there exists a dazzling amount of Linux distro's. However, as I see it, it looks like many folks
are rather fond of Ubuntu. So, let's use that Linux distro as an example.

But in fact you can use any Linux distro, as long as you can create a bootable Live DVD, or Live USB
from which you can start that Operating System.

Often that means:

-Downlaod the .iso file.
-Once downloaded, burn it to a DVD. You can use "burning" software, but most windows versions
can burn a DVD for you too. From explorer, simply rightclick the .iso file and see if a "burning" option is listed.
-Boot the device from the DVD (possibly you need to adjust the bootorder in BIOS, or UEFI-CSM (see chapter 6)).
-Now you can test if you can indeed boot from that DVD, and if Linux starts, and if you can access files on the harddisk.

You can try to download the desktop version of Ubuntu, using (for example) this link.

-Simply download the .iso.
-Burn the DVD.
-Boot from DVD.
-It's possible that the software shows a screen asking if you want to install, or just want to work.

Ofcourse, do not install Linux, but simply start the software.
Try if you can indeed copy datafiles from your harddisk, to, for example a USB drive.

Note: software like "Rufus".

There exists free utilities, like "Rufus" which can create a bootable USB drive too,
. for example based on Windows. You then only need a .iso file, like for example the Win7 .iso file.
Rufus is quite simple to use, and might be a great help too.
You are strongly encouraged to do a Websearch on Rufus (or similar tool), to widen your toolkit
for creating bootable media, and to make you stronger in case you need to perform repairs or salvage data.

Done...

Chapter 6. UEFI boot and BIOS/MBR boot.

Associated with UEFI, are GPT disks, or GUID Partition disks.

The GPT metadata on such disks, is much "larger" and more flexible, than the MBR based disks.
One enhancement of GPT for example, is breaking the 2 TerraByte (TB) limit, so partitions on such GPT disks
can be much larger than 2TB.

So, UEFI uses GPT disk(s). However, since the GPT metadata makes GPT disks completely "selfdescribing", also
the older BIOS/MBR machines can also use GPT disks, but not for booting the initial Operating System.
For such older systems, we simply need the traditional MBR/VBR initial sequence.

Let's take a closer look at both systems (UEFI boot and BIOS/MBR boot). Let's start with the older one.

6.1 The traditional BIOS/MBR initial boot.

Please take a look at the simplistic picture below.

Fig 7: Jip and Janneke illustration of the initial BIOS/MBR/VBR boot.

After POWER ON, the device will perform some "self checks". Then, the BIOS will determine
the order of "bootable devices". As you may know, in the traditional BIOS setup, you can specify
the order of bootable devices. That's just a simple listing like
DVD, USB, Harddisk0, network etc.. Usually, the first harddisk is chosen, and listed as the
first device which the BIOS will check for the "initial bootcode".

In that case, the BIOS will load the very first sector (MBR) of that disk in memory, and transfer
control to the "initial bootcode" in that sector (which is the MBR).

This code is very small, and has as a main purpose to read the "Partition Table", which is also
stored inside the MBR.
The traditional "Partition Table" has 4 records, each containing various fields.
One of the fields is the "Boot Indicator" field, which marks, or "flags", a certain Partition as bootable.

So, the "initial bootcode" now has knowledge of which Partition is bootable, and it "jumps"
to the very first sector in that Partition. In effect, it transfer control to the code
stored in the very first sector in that Partition.
Actually, this "Partition Boot Sector", or also called "Volume Boot record" (VBR) is quite complex.

It's multiple sectors wide, and various parts has certain dedicated functionality, like e.g. storing
all sorts of metadata of the filesystem on that Partition.
The exact layout of "Partition Boot Sector" is dependent on the type of Operating System.

Anyway, the first sector of the "Partition Boot Sector" is special, since it will locate the
"true" OS loader. This OS loader will be BOOTMGR/WINLOAD on Vista/Win7/Win8/Win10 machines
and ofcourse also with the corresponding Windows Server variants (as Win2K8, Win2K12 etc..).

When we would study the boosequence of older Windows machines (XP/Win2K3 and earlier), then
the code of the "Partition Boot Sector" would locate the "true" OS loader of those sort of systems,
which would be NTLDR.

Anyway, basically, the above describes the BIOS/MBR/VBR boot in a very lightweight fashion.

The MBR (or Master Boot Record), is simply an intermediate structure. If, for example,
a bootable device is not Partitioned (like a antique Floppy), then the BIOS transfers control
directly to the first sector of that bootable device (same sort of code as the first sector of the "Partition Boot Sector"
of a partition on a harddisk.

In figure 4 above, I labelled the various phases as Stage 1 up to Stage 4. What happens after Stage 4, is the
loading of the Full Operating System, like loading the Kernel NTOSKRNL, reading the Registry, loading
primary drivers/services, loading API's like NTDLL, CSRSS, SMSS etc..
You might refer to figure 1 for that.

My apologies for this very simplistic description. However, I consider this to be sufficient for understanding
various error messages of a BIOS/MBR machine would not boot correctly anymore.

For example, the MBR and VBR (or "Partition Boot Sector"), have various locations reserved for basic error messages.

So, if you see the message "Missing NTLDR" on XP, then the VBR cannot locate that File, or the VBR is faulty.
Similarly, if you see the message "Missing BOOTMGR" on Win7 (or later version), the same story applies.
Ofcourse, that holds for BIOS/MBR/VBR machines. But we know that we probably do not need to fix the MBR,
but instead, we must repair the "Partition Boot Sector" (or also called the "Volume Boot record).

Notes:

Note 1:

-Some folks name Stage 1 + Stage 2 + Stage 3, all together, the "IPL" or Initial Program Load.
-Some folks name the bootcode in the VBR, the "bootstrap" code.
-Some folks name the "initial bootcode" in the MBR, the "bootstrap" code (seems most folks choose this one).
-Some folks name the "initial bootcode" in the MBR, plus the bootcode in the VBR, the "bootstrap" code.

Note 2: About the Max Partition size in BIOS/MBR systems.

A 16 byte Partition Entry, in the MBR, has the following structure:

Lengt (bytes):	Content:
1	Boot Indicator (80h=active):
3	Starting CSH
1	Partition Type Descriptor
3	Ending CSH
4	Starting Sector
4	Partition size (Sectors)

The last 2 fields express the problem. For example, the "partition size" (in no of sectors), is 4 bytes (32 bits) long, so it
can have as a maximum value "FF FF FF FF" in hex, which is "4294967295" in decimal. So, when using 512byte sectorsize,
this amounts to about 4294967295 x 512=2.199.023.255.040 bytes, or a maximum partition size of about 2.2 TB (2 TB).

6.2 The UEFI initial boot.

Modern systems are usually equipped with UEFI. Windows Operating systems, 64 bit, as of Vista SP1,
supports UEFI.

However, if needed, a fallback to BIOS is often still possible, due to certain extensions,
which are called the Compatiblity Support Module (CSM). This partly emulates a traditional BIOS system.

Using keys like F1, or F11, F12 or other key (specific to your system), you can enter this legacy BIOS setup,
and it's often possible to "enable/disable" UEFI (partly), meaning that you fallback on BIOS, for booting.

Important: If already an OS was installed using UEFI, and UEFI then afterwards gets disabled in favor of the legacy boot,
then that OS will not boot, unless you enable UEFI again. Also, after this, installing a legacy OS on such enabled BIOS system
is rather "tricky", because a serious risk exist that your system will be modified due to that legacy OS install.
In particular, you should not (let) "destroy" the EFI System Partition (ESP).

UEFI is a more complex "startup method" or interface, compared to the traditional BIOS.
However, there are certainly improvements in using UEFI, like in using a larger bootdisk (> 2TB),
and better security features during the startup phases, and in general, the startup is a bit faster.

In this note, it is not neccessary to go into depth. However, a reasonably "good" birdseye view is vital.

The following is very important:

As we will see below, UEFI uses a seperate "EFI System Partition" (ESP). But this can coexist with an MBR/VBR structure
as it was in the older boottype.

In fact, on many UEFI systems, a user can fallback to a BIOS-CSM (emulation), so that the traditional BIOS/MBR/VBR
initial boot, is in effect again.

Fig 8: Jip and Janneke illustration of the initial UEFI startup.

In one sentence: EFI is often defined as an interface between an operating system, and platform firmware.
It's best to view EFI as a modular structure, consisting of "certain parts", like a firmware interface, a bootmanager,
an EFI systempartition, and support for a drivermodel using EFI Byte Code (EBC).

The hardware must be suitable for using EFI, so, really old x86 systems are not usable, but x86 is not excluded.
However, if the hardware is supported, it is still possible (if you would insist) to run legacy BIOS Operating Systems,
"thanks" to compatibility modules like CSM. However, UEFI is targeted for BIOS free systems.

After a system is powered on, very globally, the following happes:

First, some system dependent routines are activated, like for example "IMM" initialization on a IBM System X,
where at the last stage, UEFI code is called. So, each architecture uses it's own very specific non-UEFI initial routines.

Next, the Security (SEC) phase, Pre-EFI Initialization (PEI) phase, and then the Driver Execution Environment (DXE) phase
are executed in sequence.
In reality, those phases are really pretty complex, but for our purposes, it not neccessary to go into the details.

During the DXE phase, EFI Byte Code drivers might be loaded from any firmware flash, or could come
from UEFI-compliant adapters. A device tree is build, for OS'ses that can use it.
This is important, since modern OS'ses uses that device tree.

After UEFI is fully up, the UEFI Bootmanager is called (part of BDS). Note that on an UEFI system, actually 2 Boot managers
are present. The UEFI Bootmanager, and if Windows is booted later on, the Bootmanager BOOTMGR of Windows.
But, most often, an auto-boot (configured in NVRAM) is set, so that UEFI transfer control to the Windows BOOTMGR.

During the "Boot Device Selection" (BDS) or Bootmanager, it might happen that:

might be configured for "autoboot"to some OS (parameter in NVRAM).
Or, the system might enter a "bootmenu"
Or possibly enter the EFI "Shell", which is a command prompt.

With respect to the autoboot: just like with Open boot or Open firmware, NVRAM can store several variables,
like whether "autoboot" to some selected OS should take place.

Certain tools exist, with which you can view and edit the boot options in EFI NVRAM. See Chapter 7.

I hope that you can (sort of) "match" the text above, with the illustrations in figure 8.

If you have indeed read all the stuff above, up to here, we are ready to investigate Recovery options
in case there is a problem with the startup of Windows.

Done...

Chapter 7. Recovery using standard tools. Including PE

To repair bootstructures, there are (at least) five standard ways (thus immediately provided by Windows itself)
to achieve this. Other approaches exist too, like using "Third Party" tools, or (free/open) "Public domain" tools.

Specialized "forensic" tools exists too, but are a bit harder to get.

Those five standard ways are:

Using the Recovery DVD, which enables you to initiate repair options (graphically), or to go
to a prompt in order to enter repair commands. Or you can use the commandline to copy data from good partitions.
Using a bootable USB disk, which gives you the same options as (1).
Using a "system image recovery", which can restore the whole environment (if you have such image backup created previously).
And, if Windows is damaged in some way, it might automatically boot into a recovery menu, such as shown in figure 4.
And, if you have the original install media (like DVD), you can indeed boot from that media, and go into a recovery menu,
such as shown in figure 4, or go to the commandline.

6. A sixth option is to use any suitable linux Live (bootable) DVD or USB.
It gives you at least options to copy data (using a graphical filemanager, or commandline).

7. And, "Third Party" tools, or (free/open) "Public domain" tools, gives a wealth of other options too.

This is certainly not a complete listing of options, to get out of a miserable situation. There are countless
of clever boys and girls who have blogs and sites, providing valuable methods and tips.
It is strongly advised to take some time and thorougly search the Net for such extra methods and tips.

But always crosscheck some found tip/method with other sources. This applies for stuff written by me, too.

7.1 Recommended First Step.

If some serious error had occurred, then the following is my recommendation.
Nothing is "perfect", and that applies for recovery commands and other repair options too.

What I advice is: Before performing any repairs, first see if you can copy your data to external media.

If you have recent data backups, then this section is not important. The same is true if you
store data in cloudservices. However, if you have valuable data on your local harddisk(s), then
I advice to do this step first.

Use (1) or (2), or (6) to copy your data (word docs, excel files, photo's etc.. etc..), to other media
like a portable USB disk or other media.
For example, options (1) and (2) enables you to start a prompt, from which you can
easily "copy" or "xcopy" datafiles to other (external) media. Indeed, (6) also provides for command line,
and a graphical filemanager too. Also, from multiple options above: once a "mini" Windows is "up",
you can use your favourite tools too from USB or DVD.

Thus, if for some reason, any repair fails, then you still have your data, since you have previously copied it to a safe place.

Yes, I am a bit paranoid when it comes to data. Most of the time, I work as a DBA or SysAdmin, and to be able
to restore (for example) production databases perfectly, 100% garanteed, is the main duty.

Secondly, here we have "some" Albert, writing a silly note as he usually does. Suppose, in case of some error,
you immediately start using some powerful repair command. Suppose it messes up your system further (nothing is perfect),
before you tried to save data first. Then we have a really unpleasant situation.
Thus: Albert says: if needed, backup the data first.

If your data is stored in the "cloud", then this section is not so important. Also, if you already have recent backups,
you can ignore this step too. Even if PC/Laptop data is in the cloud, I advise to have some local backups too.
In effect, you must be 100% sure your data is safe.

Note: Your data is the most valuable asset ofcourse. However, some folks have invested an enormous amount
of time and effort to configure all sorts of difficult applications to work with windows.
Saving application configuration files, for example all sorts of .cnf, or .xml files etc.., might be worth wile too.

7.2 Repair using commandline tools.

First a few important remarks. Please read them carefully:

Remark 1:

As we know, UEFI uses a seperate "EFI System Partition" (ESP). But this can coexist with an MBR/VBR structure "elsewhere",
as it was in the older boottype.

-If the UEFI pre-boot is in effect, it fully ignores any MBR/VBR bootsructures, and simply follows the path
as shown in figure 8 above. At a certain moment UEFI is up, and uses it's ESP and Bootmanager (possibly with an autoboot to Windows).

In fact, on many UEFI systems, a user can fallback to a BIOS-CSM (emulation), so that the traditional BIOS/MBR/VBR
initial boot, is in effect again.

-If BIOS-CSM is in effect, the EFI preboot will run, but stops just before the "Boot Device Selection" (BDS) or Bootmanager phase.
Control is passed to emulated BIOS. The usual BIOS/MBR/VBR sequence will run.

It's thus possible to switch between UEFI and BIOS-CSM, using some initial setup (if the device allows it).
In fact, you can switch forth and back again. Only an initially installed OS, that was setup for UEFI or MBR,
might not boot if you switch between UEFI and BIOS-CSM. If you want it to boot, you must switch back again.

Remark 2:

Please be advised that some errors may seem to suggest that a certain important file (like "winload")
is missing or corrupt, but in many cases, there might be something wrong with the BCD store.

This can happen, for example, in a multi-boot configuration having multiple Windows versions. The BCD store might
miss an entry that points incorrectly to one of those Windows versions (the one that does not boot).
Ofcourse, you should "somehow logically" be able to explain it, for example, the effect occurred after a second install.

However, files can indeed be missing or have been corrupted.

Remark 3:

It's important that you have created Bootable media (Repair/Recovery DVD, USB with Windows PE, Linux Live DVD/USB),
as described in Chapter 5, or other procedure. You should also have tested that you can indeed "boot" from those media.

Remark 4 (paranoia):

If you simply like to test commands or procedures, then use a test machine, and not any device
where the current configuration, and/or data, is considered to be valuable.

The following commandline "commands" (or tools), are of interest:

Tool	Environment:
bootsect	BIOS/MBR/VBR
bcdboot	UEFI or BIOS/MBR/VBR
bootrec	UEFI or BIOS/MBR/VBR
bcdedit	UEFI or BIOS/MBR/VBR
sfc	Just a filechecker.

And, then some attention will be given to: "mbrfix", "fixboot", and the Linux "dd" command.