I have been trying to come up with an easier way of installing Windows and Linux dual booting on my laptop, not necessarily in that order. What we generally have to do is install Windows first, and then install linux and allow GRUB to handle Windows.

So what I'm trying to achive is to find a way to bypass that pesky installation process (windows) and just use an image to directly copy into my drive. This would also allow me to retain my boot manager (GRUB). (not that I cannot restore it afterwards, but it is Microsoft policy to monopolize, in this case denying the existence of other boot managers in the system).

I first obtained a legal copy of Windows 8.1, then proceeded to install it on a virtual machine using VirtualBox. Then, I created an NTFS partition on my GPT partitioned hard drive and copied the contents of the Windows partition from the .vdi image to the newly created partition.

Of course, it doesn't work yet. I don't know how to replace bootmgr. It gives

File: \Boot\BCD
Status: 0xc000000e
Info: The Boot Configuration Data for your PC is missing or contains errors.

because it can't find that file from the other partition which is used for booting, system recovery, etc.

Now, I've read that bootmgr eventually executes winload.exe to boot Windows up. I have no clue what to do next.

I reckon it should work theoretically because I have all the files required to run Windows. I also think that I should not be the only one who has thought of this, and hence I may be missing something very basic here. Maybe it is already done?

I have little idea how booting works. What I managed to understand is that when you dual-boot Windows and Linux, you chain the windows bootloader to linux's. So what I am trying to achieve is to somehow get rid of the Windows bootloader.


I have been looking at the binary files bootmgr and \Boot\BCD. bootmgr reads the BCD file and lists your options, among which you can select to boot into.

So information like executing winload.exe resides in the BCD file. Now, I think bootmgr itself is executed by syslinux using the chain.c32 module. What I am trying to do is somehow execute the windows bootloader, i.e. winload.exe directly from syslinux (if possible), or modify bootmgr so that it executes winload.exe itself (whose path will be directly in the bootmgr executable) without looking for BCD or anything else.

Hibernation (which requires a different procedure) is of no concern to me at this step.

Edit your question to tell us the firmware type, and (if EFI) whether you have enabled the Compatibility Support Module in the firmware's setup

My firmware is EFI (with CSM enabled), and I normally boot into Arch Linux using GRUB. I have discovered that bootmgr executes System32\winload.exe on legacy systems, and System32\winload.efi on EFI.

I have 0.0 idea on what to do from here. For the last 10 days, I have been trying to make changes to BCD and I think I am about to reach success. But that is irrelevant, because what I really want to do is to bypass the Windows Boot Manager altogether.

If you have any idea whether there is a way to execute that winload.efi from the EFI shell (just a guess), or some other modification to GRUB so that it will boot Windows in EFI mode without the chainloader.

Any advices are welcome.


Following forum posts might provide some useful insight:



The grub4dos right now can chainload a bootloader (like NTLDR or BOOTMGR) because it can act as a replacement of the code contained in a "normal" bootsector (i.e. something like 300 bytes of machine code).

This code simply sets a few parameters and then calls the loader.

Even that is (was) not easy at all to understand and replicate with different code.

A NT system loader like BOOTMGR has more or less in a single .exe a "real mode" operating system (not entirely unlike DOS) and facilities/tools to parse both plain text and Registry hives, it is not something that can be re-written from scratch easily.

The good guys @ReactOS are working on writing the FREELDR (which aims to be a replacement for the much simpler NTLDR) since YEARS (and believe me there are among the ReactOS programmers some really good and good at it guys).

It seems (but it is not documented clearly) that they managed to boot experimentally a Server 2003 with NTLDR.


With the introduction of support for (U)EFI, BootMgr helps to abstract the difference between BIOS and (U)EFI. For example, here are two sequences:

BIOS (PCAT) -> BootMgr { BootMgr stub -> embedded BootMgr.exe } -> WinLoad.exe -> Windows
64-bit (U)EFI -> BootMgFw.efi -> BootMgr.efi -> WinLoad.efi -> Windows

WinLoad expects a certain environment (including API) to be present. BootMgr takes care of this, so [almost] the same WinLoad program will work in either environment.

In fact, (U)EFI defines a method for storing and fetching boot parameters, so BootMgr's BCD covers that same purpose, regardless of BIOS/(U)EFI.

But beyond BIOS and (U)EFI differences, BootMgr lets you make a "boot choice," whereas WinLoad boots a particular operating system that it knows how to boot.

Depending on how much of an environment WinLoad expects to be present, it might be possible to invoke WinLoad directly. Michael Brown's wimboot invokes the BootMgr PE[1] directly, so it could invoke WinLoad directly, except that WinLoad probably wants more of an environment. You could try it!

[1] Not to be confused with the BootMgr which GRUB4DOS and Syslinux' chain.c32 can invoke. That BootMgr includes a stub which knows how to invoke the embedded BootMgr PE.

  • 1
    You haven't provided enough information yet. Edit your question to tell answerers whether this machine has EFI firmware or old PC/AT-style firmware. At the moment you're talking about MBR bootstrap programs on EFI partitioned discs, which is (unless one is using one of my programs or H. Peter Anvin's) nonsense and likely not the way that your machine bootstraps.
    – JdeBP
    Commented Mar 15, 2014 at 1:09
  • The policy you describe does not exit Microsoft does prevent anyone from dual booting systems
    – Ramhound
    Commented Mar 15, 2014 at 1:11
  • @JdeBP You are right. At some point, I was actually using both. I was using syslinux with the pc\at method. Then I installed GRUB to an EFI partition. So my laptop supports both, but I had the same result each time. I will try to inform myself in the meantime. On the other hand, do you understand what I am trying achieve? Forgetting what I have described before, maybe you can give me advice whether it is doable or not.
    – osolmaz
    Commented Mar 15, 2014 at 7:50
  • I didn't ask for the firmware type idly. That's a vital datum, which you must provide. Without it, people cannot even start a proper answer. Edit your question to tell us the firmware type, and (if EFI) whether you have enabled the Compatibility Support Module in the firmware's setup utility.
    – JdeBP
    Commented Mar 15, 2014 at 10:57
  • @JdeBP I have edited the question.
    – osolmaz
    Commented Mar 15, 2014 at 11:24

3 Answers 3


To answer your original question, no. Windows cannot be loaded without going through it's own bootloader (in the case of UEFI installs, bootmgfw.efi). This is because Windows expects that bootmanager to be there AND to call winload.efi. If that does not happen, then Windows will crash until you fix the problem. There are many reasons to this (practical and ignorant). Mostly, it is because Microsoft wrote the bootmanager to handle all things (loading the OS, loading the recovery environment, pseudo pre-os environment, and etc). The only way to currently achieve any semblance of sanity is to chain load using Grub-efi.

  • Before I accept this as the answer, I must ask: Is it that the task would be tediously hard to achieve, mostly due to the amount of low level hacking required to deceive whatever program involved in the process; the deception being that Windows would still think it has been booted with its own bootmanager, while in reality it was something else... And I am guessing every version of Windows would require separate effort. But this doesn't render the task impossible, just really hard right?
    – osolmaz
    Commented Mar 30, 2014 at 10:05
  • 3
    I would not say it is entirely impossible(in programming), but you would have to reverse engineer the calls that the bootmgfw.efi makes to the the windows OS. The amount of low level hacking involved in conjuction with needing to reverse engineer low level boot protocol calls to an OS loader is prohibitively expensive in regards to time. You would need to not only fool Windows into believing that bootmgfw.efi was there, but also that the BCD exists and that it was created by its own tools and so on.
    – ChrisR.
    Commented Mar 30, 2014 at 10:38

You need to add the Windows EFI bootloader to the list of boot options in the UEFI firmware. That way, you will be able to choose whether:

  1. GRUB2 should be loaded or
  2. the Windows Bootloader should be loaded

Additional options such as the DVD drive, external harddrives or network boot should also be visible at that point. The UEFI bootloader usually resides on the \EFI (/boot/efi/) partition. As you have just copied the Windows harddrive image without properly installing Windows, the EFI partition of your current machine might not contain the proper bootloader. Thus it is necessary to

  1. Copy the bootloader to the EFI partition
  2. Add Windows as a boot option alongside GRUB2

You should then be able to choose which OS is booted by simply changing the boot order in the BIOS. On my laptop, pressing F12 brings up a menu for selecting which bootloader to load.

For these steps, I will use efibootmgr and follow the steps from this tutorial:

You will need to copy the corresponding file bootmgfw.efi to the EFI partition at \EFI\Microsoft\Boot\bootmgfw.efi, or /boot/efi/Microsoft/Boot/bootmgfw.efi when using Linux:

# mkdir -p /boot/efi/EFI/Microsoft
# cp -r Microsoft /boot/efi/EFI/Microsoft

where Microsoft is a folder containing the original EFI files for your Windows version.

Then you need to add the .efi file to the UEFI boot entries using:

# efibootmgr -c -d /dev/sda -p 1 -l \\EFI\\Microsoft\\Boot\\bootmgfw.efi -L "Windows Boot Manager"

where of course you need to change /dev/sda and -p 1 to the correct values for your disk device and partition number.

Note this if you have a Lenovo laptop:

Also note that at least one manufacturer (Lenovo) ships products with a known bug that causes the system to refuse to boot unless the boot loader's name is either "Windows Boot Manager" or "Red Hat Enterprise Linux".

Starting your PC should then show something like this (if you hold down the corresponding keys during the boot process):

Windows Boot Manager


and bcdedit on Windows shows this:

C:\WINDOWS\system32>bcdedit /enum firmware

Firmware Boot Manager
identifier              {fwbootmgr}
displayorder            {bootmgr}
timeout                 0

Windows Boot Manager
identifier              {bootmgr}
device                  partition=\Device\HarddiskVolume2
path                    \EFI\Microsoft\Boot\bootmgfw.efi
description             Windows Boot Manager
locale                  en-US
inherit                 {globalsettings}
integrityservices       Enable
default                 {current}
resumeobject            {ec215a09-8bc4-11e2-bf2b-0024d7eb75a4}
displayorder            {current}
toolsdisplayorder       {memdiag}
timeout                 2


Firmware Application (101fffff)
identifier              {bb086763-b111-11e2-bf8e-806e6f6e6963}
device                  partition=\Device\HarddiskVolume2
path                    \EFI\ubuntu\grubx64.efi
description             ubuntu
  • 1
    Very nicely explained, thank you. Few days ago, I have succeeded in doing the same thing, but still using a separate partition for the Windows EFI boot manager, and through chainloading with GRUB. Now I learned that I could also use my original EPS. Also, instead of using bcdedit, I used hivex to fix the BCD; I intend to write a collection of free tools to be able manipulate BCD files in linux. But what I am trying to achieve is something different. If bootmgfw.efi somehow executes winload.efi, why wouldn't I be able to execute winload.efi directly from GRUB?
    – osolmaz
    Commented Mar 30, 2014 at 9:19
  • Oh I see. So you want to skip loading the Windows Boot Manager (bootmgfw.efi) and load the Windows Bootloader (winload.efi) directly by reading out the BCD System Store? (Going by the definitions from here.) That is interesting, I have never heard of someone doing that. What is your motivation, why is it necessary to directly load winload.efi? Also, do you have a full copy of the \EFI\Boot\Microsoft folder for testing (there are a couple of files in there)?
    – jmiserez
    Commented Mar 30, 2014 at 9:29
  • Well if I were to achieve that, I wouldn't even need to read the BCD, I could just add an entry in GRUB for the partition. (I am excluding hibernation and system recovery here) My motivation is that, it would be much easier to install windows without worrying that you will have to fix it later. Useful for sysadmins, batch installations and so on (and for me ^^). As for why directly loading winload.efi: dealing with closed spec Windows registry files (binary) is much more tedious than dealing with plain text config files like GRUB's. It is just easier to eliminate the middle man.
    – osolmaz
    Commented Mar 30, 2014 at 9:39
  • 1
    I see what you mean, yes that would be very handy. I am wondering if 1) there are any variables bootmgfw.efi passes onto winload.efi when it is launched, and 2) if there could be an issue with secure boot and some sort of certificate chain needed. Have you found out what the inherit {bootloadersettings} in the BCD store actually means?
    – jmiserez
    Commented Mar 30, 2014 at 10:05
  • 1
    3) Since I used hivex, I can guess which object that corresponds to. There is a "global" settings object in the hive, and every other objects has a reference to it. What I can say is, only two objects are sufficient to boot into windows: 1: the Windows Boot Manager object with the constant uuid {9dea862c-5cdd-4e70-acc1-f32b344d4795} 2: the object that contains the partition info and bootloader path for your actual Windows root. The hardest part was to understand the binary data structure which specified the partition. This was mostly done by wodny: bitbucket.org/wodny/libbcd/src.
    – osolmaz
    Commented Mar 30, 2014 at 10:18

You can do installations in any order i.e. Installing GNU/Linux and then Windows or vice-verse.

Just do the following after you have installed all of your operating systems.

  1. Get the "Boot Repair Disk" from here. http://sourceforge.net/projects/boot-repair-cd/

  2. Create a Live bootable USB Pen Drive of it (Instructions on pendrivelinux.com )

  3. Or burn the ISO file to a CD.

  4. Boot through this and follow the on screen instructions. You will have a reinstalled GRUB containing all of you installed operating systems.

All the best.

  • 1
    I am aware of that, what I want is something different. I am asking whether Windows can be booted directly without chainloading.
    – osolmaz
    Commented Mar 27, 2014 at 15:47

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .