Is it possible to boot Windows 8.1 without its own bootmanager?

Question

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.

EDIT

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.

Addendum

Following forum posts might provide some useful insight:

http://reboot.pro/topic/19371-chainload-directly-to-winloadexe/

1.

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.

2.

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.

Solution 1

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.

Solution 2

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
ubuntu
USB CD
USB FDD
ATAPI CD
ATA HDD2

(etc.)

and bcdedit on Windows shows this:

C:\WINDOWS\system32>bcdedit /enum firmware

Firmware Boot Manager
---------------------
identifier              {fwbootmgr}
displayorder            {bootmgr}
                        {bb086763-b111-11e2-bf8e-806e6f6e6963}
                        {8e7fb978-8bc8-11e2-bf2f-806e6f6e6963}
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

Comments

[JdeBP]

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.

[Ramhound]

The policy you describe does not exit Microsoft does prevent anyone from dual booting systems

[osolmaz]

@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]

@JdeBP I have edited the question.

[harrymc]

Windows 8 on GPT uses a 100MB system partition which holds the boot files. So there are 2 partitions, and then another big head-ache : the disk-signature. See the Multibooters site for more info. It would really be much simpler to install Windows first to the computer and then Linux. The standard procedure is described here. Copying Windows files by itself will never work.

[harrymc]

If you have managed to get that working, then you have achieved something new. You should post a detailed answer for future readers.

[osolmaz]

@harrymc Yes, I will do it as soon as I can. I also intend to release a free tool for BCD manipulations.

[osolmaz]

I am aware of that, what I want is something different. I am asking whether Windows can be booted directly without chainloading.

[osolmaz]

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?

[jmiserez]

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)?

[osolmaz]

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]

... If it were possible

[osolmaz]

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?

[jmiserez]

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?

[osolmaz]

1) I am not very knowledgeable in that field, I wish to learn more. 2) With this current configuration using a modified BCD and a bootmanager from another Windows installation, I get the "SecureBoot isn't configured correctly" on my desktop. I presume it (secure boot) would be even harder to achieve in case I succeed in this. Also, is secure boot really necessary, and what is it good for?

[osolmaz]

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.

[jmiserez]

I think this might possibly give you some new information. In your case however, I would try replacing ntldr ($root)/bootmgr with ntlr ($root)/Windows/System32/winload.exe (not using winload.efi, but winload.exe) and see what happens. I'll try and see what it does on my machine.

[osolmaz]

And the data structure differs in case of MBR and GPT partition tables. For example in MBR, the data structure has the starting address of the partition+disk signature, whereas in GPT, it has the partition GUID+disk GUID.

[ChrisR.]

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.

[jmiserez]

I don't think it can be done with GRUB2. I've played around with it on my configuration but it doesn't work. Also I've stumbled upon this thread, also suggesting that GRUB is the wrong tool for the job to load winload.efi directly. Further interesting posts are here, while post 11 here suggests that some custom boot managers can do it.

[osolmaz]

Indeed, I was missing ntldr.mod in my /boot/grub/x86_64-efi/. This answer explains: unix.stackexchange.com/a/56886/63326 . Meanwhile I can try this on my MBR partitioned VirtualBox machine.

[osolmaz]

I read the posts, and they seem mostly discouraging. For one, they suggest that using ntldr on winload.exe would not work. Also: the fact that ReactOS guys trying to replicate ntldr behavior with very little success. So this has been tried before, did not yield any good results. I, for one, do not have the time, resources or knowledge to make such an attempt, so I am thinking of accepting the answer below that says it would be very hard. What do you think?

[osolmaz]

Besides, this will not prevent me from writing a tool to auto-generate BCD's, similar to grub-mkconfig. My question was purely out of curiosity, and it has been fulfilled.