Windows 10: Windows Boot Manager issue with Dual Boot on different Hard Drives

At the very beginning of GPT partition table, there is Protective MBR which is used to prevent disk tools not supporting GPT disks from identifying the disk by mistake and damaging the disk data.

 

I unplugged all my drives and only plugged my SSD (GPT UEFI) with Win7 64 and booted on my Win7 install USB stick.

I didn't know if I had to execute the commands right on x: (probably the USB stick) or c: so I ran them on both:





I don't know why it says 0 Win install when it finds my Win7 system right after selecting the Windows Recovery tools...

 

Execute below commands:

Code: Bootrec /ScanOS Bootrec /FixBcd[/quote] Please post a screenshot of the commands outputs.

 

No need FreeBooter, I just checked the UEFI BIOS and I now have 2 Windows Boot Managers, 1 for each system. I can now plug/unplug and switch back and forth from my Win7 SSD to my Win10 HD and vice versa.

One of the 3 commands brought back the Windows Boot Manager for my Win7 system. I don't know why it got dumped in the first place after installing Win10 .... separately on another drive.

Thanks a lot FreeBooter!

 

My issue is not resolved. I just know I need 2 Windows Boot Managers in my UEFI BIOS for Win7 and Win10 to boot.

Yesterday, after running the commands via the Windows Repair Tools, I saw a 2nd WBM was added and was able to boot my Win7 system. I then shut down the computer, remove the SATA cable to plug my Win10 drive and I also was able to boot without having to do anything special. I then shut down the computer and left it at that.

This morning I booted on Win10 but checked the UEFI BIOS just to see if there were still 2 WBM... but I had only one left. I could boot normally on Win10 so I thought that if I were to plug my Win7 drive back, I wouldn't be able to boot again. That's what I did, and that's what happened.

So, again, I plugged my Win7 installer USB stick, selected the Windows Repair Tools to run the commands. The WRT looked for my Win7 system and found it. Then I ran Bootrec /FixMbr through the commands but got this time an error message! I decided to just reboot the computer and.... my second WBM was there! So I was able to boot on my Win7 system.

My guess is that it's not the commands that are bringing back the WBM but the automatic Windows scanning from the WRT because it's the only thing I did to bring it back.
My other guess is that each time I'll boot on Win10, it will remove my other WBM (for Win7) although this drive is disconnected... How come?

 

Windows 10 Boot Manager can also boot Windows 7 OS so i don't understand how come you have two Windows Boot Manager within BIOS setup utility. The Bootrec /FixMbr repairs master boot record (MBR). The UEFI firmware does not use Protective MBR on GPT disk to boot Windows 7.

We should repair boot files for Windows 7.

Please execute below commands.


Code: Diskpart List Volume[/quote] Please post a screenshot of the above commands outputs.

 

Sorry, my Win7 system is in French.
Disk 0 is my SSD with Win7 64
Disk 1 is my Toshiba 4TB
Disk 2 is my Seagate 2TB

 

You have not post the screenshot for List Volume command.

 

Sorry about that (old habits)

 

You will have to use Diskpart command to find out the System Reserved partition drive letter.
The output of the below commands may display the name of the System Reserved partition as only System or EFI.

Type diskpart and press Enter.
Type list volume and press Enter.

Under the label (Info) row, find the label System Reserved and note its corresponding Volume number.

Now type select Volume=N and press Enter, where N is the Volume number you noted earlier.
Now type assign letter=w and press Enter.
Type exit and press Enter.
Type bcdboot C:\Windows /s w: /f ALL and press Enter.


Please replace partition letter C: with Windows installed partition letter. When computer boots into Windows Recovery Environment (WinRE) environment the drive letter assign to Windows partition may not be C: drive letter because Windows 7, 8 , 8.1 and 10 creates a separate system partition when it's installed from scratch. The system partition contains boot files WinRE assigns the system partition the C: drive letter and the Windows installed partition will be assign any other drive letter usually D: drive letter is assign to Windows installed partition. The Bcdedit /enum | find "osdevice" command can be use to find out the drive letter of the Windows installed partition the output of the Bcdedit command is similar to this osdevice partition=D:. The drive letter after partition= is the drive letter of the Windows partition.

 

There are some misleading information in this thread.

• Unlike Legacy MBR BIOS. When running Windows using GPT style partition, The UEFI firmware will update the boot configuration accordingly.
• For each Windows using GPT with separate EFI System partition, You will have a separate "Windows Boot Manager" ie. you will have one for Windows 7 and one for Windows 10.
  NOTE: You must first connect the SSD/HD then restart or turn off the PC then turn on the PC for UEFI firmware to update the boot configuration.

There is nothing wrong with your Windows 7/10 booting. You just need to set your UEFI firmware to point to the correct "Windows Boot manager" and and set the SSD/HD to be the first boot device. Or using the Boot Menu for a one time boot.

It is hard to visualize how it works. So here's some screen shot from my PC.
From Disk Management: I have 2 Windows installed, 1 on disk 0 (Connect to Sata 0) and the other on disk 3 (Connect to Sata 5). On disk 2, I have 2 WinPE's (WinPE does not have Windows Boot Manager)



For one time boot from boot menu, I just have to select which one to boot from. Note that the 2 "Windows Boot Manager" associated to 2 different SSD ID's. #1 is for Windows on Disk 0, #2 is for Windows on Disk 3. #3 &#4 are for 2 WinPE's



For normal boot. On the next 3 screens, you'd have to select which "Windows Boot Manager" to boot from and also the appropriate SSD/HD.










NOTE: The GUI on my MB looks different from your MB but all options are there. In addition, If you disconnect your HD (Windows 10) then you would have to go back and reset the boot order again.

 

The following diagram illustrates some of the key portions of the process that the Boot Manager follows after it is launched by the UEFI environment.




Important thing to understand: many UEFI firmwares implement some kind of BIOS compatibility mode, sometimes referred to as a CSM. Many UEFI firmwares can boot a system just like a BIOS firmware would – they can look for an MBR on a disk, and execute the boot loader from that MBR, and leave everything subsequently up to that bootloader.

Unlike BIOS, UEFI certainly does understand, to varying degrees, the concepts of ‘disk partitions’ and ‘bootloaders’ and ‘operating systems’. Instead of the firmware only knowing about disks and one ‘magic’ location per disk where bootloader code might reside, UEFI has much more infrastructure at the firmware layer for handling boot loading.

The UEFI spec defines an executable format and requires all UEFI firmwares be capable of executing code in this format. When you write a bootloader for native UEFI, you write in this format.

An ‘EFI system partition’ is really just any partition formatted with one of the UEFI spec-defined variants of FAT and given a specific GPT partition type to help the firmware find it. . Instead of having to write bootloader code to the ‘magic’ space at the start of an MBR disk, operating systems and so on can just create, format and mount partitions in a widely understood format and put bootloader code and anything else that they might want the firmware to read there.So if you are writing an OS or something else that you want to run on any UEFI compliant firmware, this is why the EFI system partition concept is so important: it gives you (at least in theory) 100% confidence that you can put an EFI executable on a partition formatted with the UEFI FAT implementation and the correct GPT partition type, and the system firmware will be able to read it. This is the thing you can take to the bank, like ‘the firmware will be able to execute some bootloader code I put in the MBR space’ was in the BIOS world.


The firmware will look through each EFI system partition on the disk in the order they exist on the disk. Within the ESP, it will look for a file with a specific name and location. On an x86-64 PC, it will look for the file \EFI\BOOT\BOOTx64.EFI. What it actually looks for is \EFI\BOOT\BOOT{machine type short-name}.EFI – ‘x64’ is the “machine type short-name” for x86-64 PCs. The other possibilities are BOOTIA32.EFI (x86-32), BOOTIA64.EFI (Itanium), BOOTARM.EFI (AArch32 – that is, 32-bit ARM) and BOOTAA64.EFI (AArch64 – that is, 64-bit ARM). It will then execute the first qualifying file it finds (obviously, the file needs to be in the executable format defined in the UEFI specification).

 

Hey Freebooter! Nice diagram and explanation. Can you please provide a link to its source? Thanks,
--Ed--