Clone bootable 2TB MBR 3 partition to a 4TB GPT bootable 3 partition

Okay, I was completely confused about your setup. You kept mentioning SSDs and HDDs and never mentioned a 250GB SSD specifically, and weren't clear about what drives did what. I thought it was just the PARTITION that was small for your boot drive, not the actual drive, and thought it was on the 2TB drive. I never realized you had an SSD for boot and the 2TB drive was a mechanical drive just for data, and you kept mentioning the backup of the boot partition and I was never clear about that. Why in the world do you want to boot to a mechanical drive and run your OS on that? Even an old SSD like the BX100 will be faster.

What's listed in Hard Drive BBS Priorities? What happens if you set Storage Boot Option Control to UEFI first? I don't really think either of those matter, just throwing things at the issue because it's really odd. No idea why the SSD isn't listed as a boot option.

The only thing I can think of is that the BCD on the 4TB drive isn't configured properly, or the boot files didn't get copied properly to the EFI partition, so when you try to boot to that with both drives connected it doesn't look at the correct location. The 0xc0000025 error is related to missing boot files. Perhaps it is set to look for a partition on the SSD that doesn't exist because it's MBR, but it falls back to the HDD if the SSD isn't connected. Unplug the SSD and boot to a Windows installer, and go through the repair functions with bootrec and copying the boot files with bcdboot, and rebuilding the bcd. May need to completely blow away the BCD and recreate it, and/or remove the EFI partition and recreate it and copy the files.

Which drive did you clone onto the 4TB? It should have been the SSD being cloned to it, so you would be getting your current OS configuration, then converted to GPT and your other partitions created.

Okay now I understand a lot better. I've never run into anyone that used a "backup" OS like that, but also nobody that ran nearly everything as a portable app. I still was thinking it was just a "backup" in the usual sense. But now I understand why you'd need to keep both legacy and UEFI enabled.

I am kind of stumped. I could probably fix it if I was sitting in front of the machine where I could run commands and look at the results directly, but it would take a lot of trial and error. (It always seems to be that way even when I'm just restoring a backup of my own system without any sort of conversion. Restores even from official backup apps onto the same type of drive never seem to work instantly, though clones do. But any sort of modifications stuff everything up.)

When the cloning and conversion to GPT was done, and the build of the BCD for the second drive, was the SSD disconnected? I can only think of one possible reason for the issue when you try to boot to UEFI with both drives connected. The BCD works by pointing to a path to the boot files, such as device partition=\Device\HarddiskVolume2 (for the boot manager) and device partition=C: (for the boot loader).

If the BCD was configured when there was only one drive, then it basically says "look on the first drive for the files, at this path". Then you plug in the SSD, which becomes the first drive, but it doesn't have those files because it's an MBR disk with no EFI partition. Even though you are pointing to the 4TB disk when you select the boot options, the actual boot process still considers it the second drive.

An easy fix may be to simply swap the ports, however this may result in the system always booting to the 4TB HDD by default, since you haven't been able to configure the boot order in the BIOS with the SSD as the first drive. Maybe swapping them will change those options. But you could at least test it by hitting the boot selection key to manually select it and see if both drives now work. This might just result in making the problem happen in reverse since the BCD on the SSD thinks it should be the first drive.

The true fix I think would be to rebuild the BCD from scratch on the 4TB drive, using a Windows installer flash drive, while both drives are plugged in. This will let you select the Windows installation to use and configure the BCD with the correct path. Or keep the UEFI drive as the primary (as it's the more advanced format, and reconfigure the BCD on the SSD. You should absolutely take a full backup of the SSD beforehand, just to be sure the you can recover if the BCDs get borked.

Or, maybe the easiest thing of all would be to just keep the 2TB plugged in as the "backup" OS drive, and just make the 4TB drive a pure data volume? Wipe it so there are no boot files at all and just move the data over. The system will work fine if you have both boot drives as MBR and the 4TB drive as GPT. (Maybe even get another small SSD to use as the backup OS instead. It would reduce the power used and heat produced, rather than having an additional mechanical drive spinning, even though that drive ought to sleep most of the time.)

I mean, if it's basically silent and the space would be empty otherwise, especially if you make it an SSD, it's hardly an issue. Heck, make it an external SSD (cheap, small SSD in a cheap, small enclosure and it's only connected when needed or to update it, and a current USB enclosure on a USB3 port is just as fast as an internal SATA SSD other than some extra latency). Honestly that would be the absolute best way for your system to be set up and just make that 4TB drive a GPT data volume until you finally move on with a full reinstall of Windows in UEFI/GPT. The cloned MBR drive to a USB drive ought to boot just fine.

I'm sorry, but this is so entertaining. I've never read someone dual boot setup with same Windows version. I have to wonder if the old hard drive is even AHCI enabled. If I follow correctly now both SSD and hard drive can boot separately if the other is disconnected. Doesn't that mean each drive have a hidden partition with their own separate BCD? OP, you might want to search sevenforums.com to start untangling this mess.

I'm almost certain it's because Windows isn't able to work out the fact that you're dual-booting, particularly with different boot types, and gets confused about the paths and locations of the partitions where it should look for the OS files after the boot manager has loaded. (When it has started in UEFI-mode, the MBR drive can't be bootable, and BIOS mode can't boot to GPT.) Windows has never been designed for dual-boot really, even though the BCD makes it look like it ought to be able to manage it. When dual-booting with Linux, Windows must always be installed first, so that Linux can put its boot manager in place and properly handle it. If done the other way, Windows will just replace the boot manager and ignore the fact that another OS is installed. Perhaps if you were to do a clean install of Windows to the second drive, in UEFI mode, with both drives connected, it could properly identify the partitions and configure the BCD to point to the right paths (though if you later unplugged the MBR drive, the BCD might get confused again). Or it might just disable the MBR boot capability entirely. Rebuilding the BCD SHOULD fix it, because it will scan all the drives for existing OSes and make them both available, but when fixing issues with the BCD it always takes me many tries before the scan will even detect Windows on the only drive in a system.

No, EFI partition is where your "BIOS" resides. Next is the 500 MB (at least when I set them up, IIRC Microsoft recommend 100 MB) System Reserved where the BCD boot (windows bootloader) resides. Then your Windows partition (C). Then your WinRe recovery partition. Then your data partition.
You can look it up at this Microsoft recommended layout.

Edit: ignore the emoji, somehow it convert : \ into an emoji

It's the same ever since Windows 8, with introduction of Windows Recovery Partition. The hidden MSR partition scheme start with Windows 7. Start with only your main OS drive connected, and go to diskpart and look for partition list. If there is an EFI and MSR hidden active partition, then the BCD boot resides in the MSR partition. If there isn't any MSR partition, then the BCD boot files resides in your Windows (C ?) partition. That would mean your C partition is marked Active and Boot-able, and for dual booting it will always load C first. That's not a good thing .

You need to move that BCD boot to that MSR partition so windows bootloader is free from your current Windows partition. Search sevenforums or tenforums how to do that. After your BCD is on that MSR hidden partition, you can connect the other Windows disk, and get your other Windows be recognized and booted.

Edit: note Windows only want 1 partition marked active in their whole system. That's where they put their bootloader. You can have more than 1 partition marked as boot-able, however. The bootloader will sort it out.

CluelessOne said:

EFI partition is where your "BIOS" resides.

Click to expand...

The EFI partition is not where your BIOS is. The motherboard has a UEFI firmware chip no matter what OS you have installed. That is what you access with the F10 key or whatever when you turn on the PC. The partition on the disk is the EFI System Partition (ESP). The EFI on the motherboard reads the files in the ESP to determine how to load the operating system (all EFI-compatible OSes, like Linux and Windows). For Windows, that means reading the BCD to locate the actual Windows operating system's partition. (Technically you should be able to configure the BCD, manually, to point to a Linux partition to boot. Linux gives you dual-booting options when you install to a machine with Windows on it, basically adding Windows do the Linux version of the BCD. Microsoft COULD do that if you installed Windows to a machine with Linux already on it, but they refuse to make it easy to use anything except Windows. The motherboard's UEFI just looks for whatever boot manager is installed in the ESP, whether it's the BCD, Grub, whatever.)

The "Microsoft Reserved Partition" is an empty partition (sometimes 100MB, sometimes 128Mb, sometimes 16MB) that Windows creates which Microsoft never really used for anything. Windows actually works fine without it but it's supposed to be there to assist with partitioning data or remapping bad sectors, and possibly dual-booting related to partitioning. Windows's Disk Management won't even show that it exists; you have to use diskpart or third-party tools.

The MSR partition only exists on GPT disks (both boot drives and data-only). MBR disks don't require it. The ESP is only present on a GPT boot disk, because it's only used by UEFI.

I guarantee this is not a motherboard issue. It's an issue with the partitioning and the fact that your system is trying to manage two different styles of booting, with two different bootable disks with different partitioning types, which are all incompatible with each other without manual intervention. Your motherboard isn't "dual boot" with anything related to the OS (motherboards don't care what software is on a drive as long as it's compatible with BIOS or EFI boot). It's got "DualBIOS", which just means it has a second BIOS chip, or at least a second section of one chip, built in so that if the primary one fails (such as with a bad update flash) the backup chip can kick in and then you can try to flash the primary again.

@CluelessOne please stop advising OP to do things when you don't know what you're talking about.

Oh well, I am glad to know that all five of my fresh install MBR drive Windows 7 PCs are not boot-able, due to a wrong partitioning scheme. Last one was decomissioned at 2021. Glad to know it's not bootable for 12 years.

If there is nothing you need on the MBR SSD, you can do a dispart /clean process on it to fully erase it (removing all boot files), then reformat it in Disk Management.
Sounds like UEFI boots fine, until the bios sees the MBR drive and gets confused, throwing the error.

CluelessOne said:

Oh well, I am glad to know that all five of my fresh install MBR drive Windows 7 PCs are not boot-able, due to a wrong partitioning scheme. Last one was decomissioned at 2021. Glad to know it's not bootable for 12 years.

Click to expand...

Because fresh installs using MBR are totally relevant to this discussion.