A Trick to Fool NMVe Non fully compatible motherboard's BIOS/UEFI...

N

N. Bapegual

Member
Many motherboard BIOS/UEFI do not natively support NVMe-SSD drives mounted on adapter PCIe cards and can't detect these drives during boot.
On the other hand, Both Windows 10 and Windows 10 Installation medias have the drivers to access these drives.
As a consequence, it is technically possible to install Windows 10 on such drives... the problem remaining is, once the OS installed, how to tell the BIOS/UEFI to boot on a drive which it can't detect !

I thought of this tricky process to elude this obstacle :
-installing two drives in the hardware configuration : one NMVe-SSD mounted on this adapter PCIe card, and a classic SATA drive
-then installing Windows 10 on the SATA drive
-then, either installing Windows 10 also on the NVMe drive (technically possible, see above) or alternatively, clone the sata drive to the NVMe drive (Acronis bootable media)
-then (re)boot on the SATA drive (default boot) and start Windows 10
-install EasyBCD in this Windows 10 and add a second entry to the boot menu, pointing to the other W10 partition which is on the NVMe drive
-restart the machine

At that stage, the machine will boot (SATA drive is the default boot), will find and present the EasyBCD boot menu to the user, so he or she can choose which W10 to start, the one on the SATA drive, or the one on the NVMe drive. Naturally, the aim of all this is that the user will choose the W10 on the NVMe.
Will it do the trick ? Will this other Windows 10 start correctly ?

Yes or No, the answer is the same as answering this TECHNICAL question :
after the EasyBCD boot menu is presented to the user, and once the user has selected the OS on the NVMe drive, WHICH DEVICE WILL HANDLE THE INSTRUCTION to start the OS which is installed on the NVMe drive, i.e. on the other drive ? Will it be the SATA drive by "establishing" a direct communication with the NVMe drive ? Or will the instruction be handled by the BIOS/UEFI, meaning in this case, il will fail because it can't natively see the NVMe drive.

To be honest, I gave it a try. Doing all the steps including being presented the EasyBCD boot menu to choose the OS went fine.
But what happened after choosing the OS on the NVMe drive is the display of a 0xc000000e error stating that the "file \Windows\system32\winload.efi is missing or contains errors". But the file does exist. Consequently, it is difficult to make a conclusion: is it the whole drive which is "missing", or is it the winload.efi which contains errors ?

It could be very valuable for the community that others test this process as well, unless someone can answer the technical question above and tell us why he or she thinks this trick will ou will not work.

Thanks for all your contributions,
Nicolas
 
There is no "EasyBCD boot menu".
EasyBCD does not replace, override or circumvent the MS bootmgr, It's simply a tool for managing the contents of the MS bootmgr's BCD store from a running OS which will affect the contents of bootmgr's boot menu on all subsequent boots.
The device handling the boot is "system" in the Disk Management flags and it will be handed control by the UEFI/BIOS, so must be on a device which is recognized by it.

Disk Management flags have the following meanings

"boot" = "this is the system you're running"
"system" = "this is where I found the boot files for the currently running system"
"active" (on the first HDD in the BIOS boot sequence) = "this is where I started the search for the boot files"
"active" (on subsequent HDDs in the BIOS boot sequence) ="this is where I will look if I don't find something in the MBR on the first HDD"

The boot process is :-

1.After pressing the power button, the PC’s firmware initiates a Power-On Self Test (POST) and loads firmware settings. This pre-boot process ends when a valid system disk is detected.
2.Firmware reads the master boot record (MBR), and then starts Bootmgr.exe. Bootmgr.exe finds and starts the Windows loader (Winload.exe) on the Windows boot partition.
3.Essential drivers required to start the Windows kernel are loaded and the kernel starts to run, loading into memory the system registry hive and additional drivers that are marked as BOOT_START.
4.The kernel passes control to the session manager process (Smss.exe) which initializes the system session, and loads and starts the devices and drivers that are not marked BOOT_START.
5.Winlogon.exe starts, the user logon screen appears, the service control manager starts services, and any Group Policy scripts are run. When the user logs in, Windows creates a session for that user.
6.Explorer.exe starts, the system creates the desktop window manager (DWM) process, which initializes the desktop and displays it.
 
Thank you Terry for this comprehensive answer.
To make sure I got it right: Choosing, as I did, the operating system located on the NVMe disk during startup when prompted to choose, is DEEMED TO FAIL because the process was then handled back again by the pre-boot process which could not detect the NVMe disk.
Back to the beginning: the fact that my system can detect this NVMe PCIe disk when a OS is loaded from a SATA disk, means that my hardware is kind of compatible with NVMe PCIe disks, doesn't it. So one could think that the inability to detect this NVMe disk during pre-boot is just a question of compatible/uncompatible UEFI/BIOS. Is that right ? Is there any kind of "open-source UEFI/BIOS" available to users, compatible with the more common motherboards ?
 
Windows is capable of detecting the device, but your BIOS chipset is obviously not sufficiently up to date. The only thing I can suggest is a check with your mobo OEM's support website for a BIOS update flash with that level of support.
 
Back
Top