W10 boot and UEFI instead of BIOS
Posted: 16 Feb 2022, 13:56
This is deeply technical and of interest to WM and others. Geek level alert.
I'm slowly getting new devices and only have two bios boot devices left.
I've been coming across issues with the UEFI and the way Windows manages it. Essentially I've been used to occasionally adding a hard drive to a system, installing to that drive and then formatting the old drive once I've copied across all the data I want.
Twice now I've come across loss of boot when the first drive is formatted. Rather irritating so I set out to find out what went wrong.
The answer is both complicated and simple. When Windows first installs on a UEFI system, it creates a 100m Fat32 partition at the beginning of the first drive. It then creates the C drive partition and then installs the boot config in the 100m partition which it then designates as UEF and hides it from the system.
All fine, until you decide to add a new HDD And create a new install of windows. In this case Windows creates the C drive on the new drive and ADDS the boot info to the 100mb UEFI partition on the first drive. You then wind up with Two Windows boot options on your windows boot menu, one for the fist drive and one for the added drive.
So as per previous builds, remove the first drive, or, worse, clean and format it. Hey presto no boot. Because you just removed the UEFI boot partition even though you told Windows to install on the other drive.
There are ways around this such as removing the first drive before installing. Windows will then create all the correct partitions, but you have to configure it in the UEFI before booting to boot from that drive (it will list itself as a windows boot manager on the new drive in the UEFI interface). But what if you are adding a new, large, faster drive to a system with embedded ssd? Now you have a problem.
The fix is to either create a partition on the new drive before installing windows, 100mb, fat32. Or, if you are stuck without the partition, use a tool like MiniTool partition Wizard free and shrink the C drive then create a 100mb fat32 partition.
Boot from the install usb key or DVD, select to repair and go into command prompt. Use the BCDBoot command to re-create the boot files. You are back in business.
I had to do this to repair a SSD I took out of my netbook I'm giving away to charity. I cleaned and re-installed the onboard SSD, but the M.2 drive I took out only had the C drive and recovery partition on it. This process worked perfectly.
The command is bcdboot [C:]\Windows /s [S:] where [C:] is the drive with the Windows install on it and [S:] is the 100mb Fat32 partition. These drives are not necessarily C: and S: in the recovery environment.
You can use diskpart and use list volume to see which volumes are what. In my case the command was bcdboot D:\Windows /s C: because the recovery environment had mapped the drives in order on the disk.
Once BCDBoot is complete it will mark the boot partition as UEFI and it will vanish from Windows unless you want to find it and know how.
I then used WinToUSB to mark the Windows install on the M.2 drive as a Windows To Go system and it now boots from USB. Only 2.0 for now, I have to get some more drivers on it and sort them to start at boot before it will boot from USB3. However I gained what I want. Another Windows install under a key which cannot be transferred which remains of use to me.
Thought I'd share as this is not really clearly visible in all the support documents I see online.
I'm slowly getting new devices and only have two bios boot devices left.
I've been coming across issues with the UEFI and the way Windows manages it. Essentially I've been used to occasionally adding a hard drive to a system, installing to that drive and then formatting the old drive once I've copied across all the data I want.
Twice now I've come across loss of boot when the first drive is formatted. Rather irritating so I set out to find out what went wrong.
The answer is both complicated and simple. When Windows first installs on a UEFI system, it creates a 100m Fat32 partition at the beginning of the first drive. It then creates the C drive partition and then installs the boot config in the 100m partition which it then designates as UEF and hides it from the system.
All fine, until you decide to add a new HDD And create a new install of windows. In this case Windows creates the C drive on the new drive and ADDS the boot info to the 100mb UEFI partition on the first drive. You then wind up with Two Windows boot options on your windows boot menu, one for the fist drive and one for the added drive.
So as per previous builds, remove the first drive, or, worse, clean and format it. Hey presto no boot. Because you just removed the UEFI boot partition even though you told Windows to install on the other drive.
There are ways around this such as removing the first drive before installing. Windows will then create all the correct partitions, but you have to configure it in the UEFI before booting to boot from that drive (it will list itself as a windows boot manager on the new drive in the UEFI interface). But what if you are adding a new, large, faster drive to a system with embedded ssd? Now you have a problem.
The fix is to either create a partition on the new drive before installing windows, 100mb, fat32. Or, if you are stuck without the partition, use a tool like MiniTool partition Wizard free and shrink the C drive then create a 100mb fat32 partition.
Boot from the install usb key or DVD, select to repair and go into command prompt. Use the BCDBoot command to re-create the boot files. You are back in business.
I had to do this to repair a SSD I took out of my netbook I'm giving away to charity. I cleaned and re-installed the onboard SSD, but the M.2 drive I took out only had the C drive and recovery partition on it. This process worked perfectly.
The command is bcdboot [C:]\Windows /s [S:] where [C:] is the drive with the Windows install on it and [S:] is the 100mb Fat32 partition. These drives are not necessarily C: and S: in the recovery environment.
You can use diskpart and use list volume to see which volumes are what. In my case the command was bcdboot D:\Windows /s C: because the recovery environment had mapped the drives in order on the disk.
Once BCDBoot is complete it will mark the boot partition as UEFI and it will vanish from Windows unless you want to find it and know how.
I then used WinToUSB to mark the Windows install on the M.2 drive as a Windows To Go system and it now boots from USB. Only 2.0 for now, I have to get some more drivers on it and sort them to start at boot before it will boot from USB3. However I gained what I want. Another Windows install under a key which cannot be transferred which remains of use to me.
Thought I'd share as this is not really clearly visible in all the support documents I see online.