massive boot delays caused by Asrock UEFI being confused by duplicate drives

[Volnaiskra]

After a major upgrade (including ASrock haswell Extreme9ac mobo), I had big troubles getting my new PC to boot properly. Sometimes it would boot, but it would pause for a long time just before Windows . Other times it would stall for ages at the Asrock logo screen.

I tried everything. I repaired Windows, went back a restore point, tried every different UEFI setting I thought might help, double- and triple-checked my boot order, checked and reinstalled all my drives, tried different sata ports, and replaced my sata cables. I had about 6 drives installed, so all this troubleshooting was very time consuming and a real pain in the arse. Finally, I isolated the problem.

I had two 'identical' SSDs on the system, one of which was my boot drive with Windows on it. Both SSDs were the OCZ-Agility3 128GB model (I also had an OCZ-Agility3 64GB installed - not sure if this added to the problem). It seems that the UEFI is too stupid to tell them apart properly, and this was causing the long delays during boot.

It also made setting up the boot order a tricky game of trial and error since UEFI doesn't distinguish between them and would give them the exact same name, even though programs like AIDA64 are able to tell them apart and reveal their unique names. Anyway, it would eventually boot to the correct SSD, but not before stalling and getting confused for a long time.

Once I unplugged the non-boot OCZ SSD, everything worked perfectly, and Windows booted in seconds. As soon as I plugged it back in, the problem came back. The drive itself is fine. I could unplug it before boot and plug it in while in Windows, and it worked perfectly. Also, this exact drive configuration worked flawlessly without any boot problems on my previous board, which was also an Asrock (Extreme 4 Ivy). My OS, both now and before the upgrade, was Win7 64 Home.

I've since resolved the issue by ditching the second OCZ and replacing it with a Samsung. The Samsung has a different name, so now UEFI doesn't get confused anymore, and everything's fine. Since I've resolved my problem, I don't need tech support for it. But I wanted to bring it to the attention of the tech support guys, and perhaps anyone else in my position.

[parsec]

Re: massive boot delays caused by Asrock UEFI being confused by duplicate drives

Interesting problem, but not without reason. What does the BIOS use for the "name" of a drive, it's official name programmed in the drive's data. So use the same drive several times in a PC, and what else do you get? You can change the name in Windows of course, but that doesn't help in the BIOS.

You should see what happens if you install Windows for a true UEFI booting PC. The boot drive entry in boot order is "Windows Boot Manager". That's it, nothing else about the drive. Are other drives with no OS on them listed at all? Nope, not in this configuration.

Then say you clone the UEFI booting OS installation from your Samsung SSD to an Intel SSD. What do you then see in the UEFI boot order? Two entries of "Windows Boot Manager". Two different makes of drives, same entry. They both boot fine, normal speed, but which one is which? There has got to be a BCDEDIT method to fix this.

In your case it sounds like you just migrated your old Windows installation to the new mobo, etc. That is a recipe for long boot times. Not to mention installing Windows previously with more than just the target OS drive installed. Then the MBR is put on another drive. If it's the same model drive as the "real" OS drive, you've got added confusion. Plus you probably fixed your first OS installation doing the repair, but who knows what really happened.

[Volnaiskra]

Re: massive boot delays caused by Asrock UEFI being confused by duplicate drives

Interesting problem, but not without reason. What does the BIOS use for the "name" of a drive, it's official name programmed in the drive's data. So use the same drive several times in a PC, and what else do you get? You can change the name in Windows of course, but that doesn't help in the BIOS.

You should see what happens if you install Windows for a true UEFI booting PC. The boot drive entry in boot order is "Windows Boot Manager". That's it, nothing else about the drive. Are other drives with no OS on them listed at all? Nope, not in this configuration.

Then say you clone the UEFI booting OS installation from your Samsung SSD to an Intel SSD. What do you then see in the UEFI boot order? Two entries of "Windows Boot Manager". Two different makes of drives, same entry. They both boot fine, normal speed, but which one is which? There has got to be a BCDEDIT method to fix this.

In your case it sounds like you just migrated your old Windows installation to the new mobo, etc. That is a recipe for long boot times. Not to mention installing Windows previously with more than just the target OS drive installed. Then the MBR is put on another drive. If it's the same model drive as the "real" OS drive, you've got added confusion. Plus you probably fixed your first OS installation doing the repair, but who knows what really happened.

I didn't really understand all of that.

But I didn't migrate the old Windows installation to the new mobo - not sure what gave you that idea. I deactivated Windows, unplugged every drive except for my target one, and did a format and fresh install from the Windows DVD. I only plugged in the other drives once Windows was fully installed and working.

I'm really surprised that UEFI would have such an obvious flaw. What happens in large organisations where they buy their storage in bulk and every one of their drives is likely to be the same model?

Like I said, Aida64 (and probably other software) is able to find a unique name for the drive. So, for example, while UEFI only sees WDC WD20EARX, Aida64 sees WDC WD20EARX-008FB0. It's a shame that UEFI isn't designed to also find this unique name.

[parsec]

Re: massive boot delays caused by Asrock UEFI being confused by duplicate drives

Well, now I understand your situation better.

"True UEFI booting" is hard to explain quickly. While modern boards have UEFI firmware (a BIOS is firmware too), by default the only aspect of it that is actually used is the ability to provide the GUI style interface to the settings we would call BIOS settings. An option called Compatibility Support Module (CSM) is enabled by default on all UEFI firmware equipped mother boards, that then use the UEFI firmware in a "BIOS emulated" mode, provided by the CSM.

The CSM option (if available, only seen as an option for about two years) can be disabled, which then allows the UEFI firmware to run as it should. But Windows must be installed in a certain way, with the CSM option disabled, in order for Windows to boot with the UEFI firmware. Simply disabling CSM with a standard Windows installation will result in a never ending BSOD during the boot process.

In this configuration, the boot drive(s) are identified in the (ASR) UEFI boot order as "Windows Boot Manager", and that's it. Very confusing for the first time user of this configuration, and when multiple OS installations are used. Other mobo's will still display "Windows Boot Manager", but I'm not sure if they add anything to it, like a "-1", "-2", etc.

Are you saying that other boards you used have a better display of the drive names than your ASR board?

[Volnaiskra]

Re: massive boot delays caused by Asrock UEFI being confused by duplicate drives

Thanks for the explanation - I undestand it better now.

Are you saying that other boards you used have a better display of the drive names than your ASR board?

No, I can't remember how the names looked on other boards. I can, however, say that I didn't have this boot delay problem with my Asrock Extreme4 Z77 board, even though I had the same SSDs and HDDs installed.

[parsec]

Re: massive boot delays caused by Asrock UEFI being confused by duplicate drives

I see, neither can I. BTW, this is why I thought you might have used the OS installation from your earlier board:

"I tried everything. I repaired Windows, went back a restore point, tried every different UEFI setting I thought might help, double- and triple-checked my boot order, checked and reinstalled all my drives, tried different sata ports, and replaced my sata cables. I had about 6 drives installed, so all this troubleshooting was very time consuming and a real pain in the arse. Finally, I isolated the problem."

Particularly the mention of using restore points had me thinking it was an old installation. But no big deal.

[10bpc]

Re: massive boot delays caused by Asrock UEFI being confused by duplicate drives

With a Z87E-ITX with latest BIOS/UEFI (2.30), I wound up with the same issue. I have 2 SSD, one from Kingston and one from Intel, both GPT with Windows 7 Pro. The Kingston is on SATA3_0 and the Intel on eSATA (data fed through SATA3_5), and an exact clone of the Kingston, so I renamed the Windows Boot Manager description to ensure UEFI points to the right resource.
As having CSM enabled all along, I set BBS with the Kingston first and then the Intel, and then point boot option #1 to the Kingston and boot option #2 to the Intel. It boots fast on the Kingston, as expected. Upon rebooting, I notice that the Intel is gone from UEFI alltogether. The browser tells me SATA3_5 (that's the data port shared with eSATA) is empty.
I then shut down, power-cycle the external eSATA dock and then I see both SSD poulated again as before. Then I swap BBS so that the Intel SSD has first priority and then I set the boot option #1 to the Intel SSD. I then get the Asrock screen with the function keys options on the lower right, and about 30 seconds later, it boots from the Kingston !
Then as Windows 7 is loaded, I can access the Intel, and check with diskpart that the 3 partitions (System , Reserved & Primary) are stiil there, and also look at the physical sectors to ensure nothing was changed. Everything is still equal to the other SSD.

As I read the thread above, and I have no legacy device, I disable CSM. The only progress I see is that it uses my screen native resolution (3840x2160), with the Asrock white logo much smaller than before. However, I got stuck at a dark gray screen. Then I reboot to see if the eSATA connected Intel SSD is detected during the DXE phase, but it does not appear. I then turn off the machine, turn off the Intel SSD and still get a dark gray screen upon booting.
I have tried a few times, but no progress. Then I turned CSM back on and was able to boot from the Kingston.

Also I tried to e-mail from UEFI while encountering the initial problem, but had a connect issue after transmitting 70% of the message, even though I had no attachment.

The main reason I started cloning drives is because my boot drive did not boot at some point, and then reappeared suddendly as MBR instead of GPT after a few girations trying to boot from USB-mounted Windows 7 DVD.

[parsec]

Re: massive boot delays caused by Asrock UEFI being confused by duplicate drives

What model of Intel SSD are you using?

Also, we have no idea what the rest of your PC system is, besides the mother board, and unknown Kingston and Intel SSDs.

Where/how did you "...renamed the Windows Boot Manager description to ensure UEFI points to the right resource."?

Your Win 7 installation was cloned from the Kingston to the Intel SSD, did you ever try booting from the Intel SSD with no other drives connected to the PC? In other words, did you verify that the clone to the Intel SSD was working correctly? What program did you use to clone the Kingston SSD?

It sounds like your SSDs, or at least the Kingston, might be configured for true UEFI booting Windows 7, but I have doubts about that. Your Windows 7 installation would need to be done with CSM disabled, and in most cases the Windows installation media must be fixed a bit before the installation will be EFI compatible. Did you format the SSDs as GPT yourself, or allowed Windows to do that during the installation? I'm guessing you did the formatting.

Given your result with CSM disabled, what is your video source, the Intel on-CPU graphics, or a video card? If it is the video card, the card's VBios must be "GOP" compatible, or you will get no video. My ASRock Z77 boards would display an error if the video card was not GOP compatible, so I'm surprised that did not happen with their Z87 boards.

[10bpc]

Re: massive boot delays caused by Asrock UEFI being confused by duplicate drives

Hello, parsec -

Actually I have been using an Intel SSD 311 series (SSDSA2VP020G2), and also an Intel SSD 530 Series (model SSDSC2BW240A4), both 2.5" drives and both GPT-patitioned, cloned from the Kingston SV300S37A60G.
I renamed the Windows Boot Manager on the primary partition of the Kingston, so as to differentiate it from Intel. I used bcdedit to do so.
I was able to boot the Intel SSD with no other drives in the system.
The Kingston is shown as GPT in diskpart :
DISKPART> list dis Disk ### Status Size Free Dyn Gpt
-------- ------------- ------- ------- --- ---
Disk 0 Online 55 GB 11 MB *
DISKPART> sel dis 0
Disk 0 is now the selected disk.
DISKPART> list par
Partition ### Type Size Offset
------------- ---------------- ------- -------
Partition 1 System 101 MB 8032 KB
Partition 2 Reserved 128 MB 109 MB
Partition 3 Primary 55 GB 243 MB

and this is the boot configuration data :W
Windows Boot Manager
--------------------
identifier {bootmgr}
description Kingston Windows Boot Manager
locale en-US
inherit {globalsettings}
default {current}
resumeobject {c6b40789-646b-11e3-b375-87b29ce8704d}
displayorder {current}
toolsdisplayorder {memdiag}
timeout 30Windows Boot Loader
-------------------
identifier {current}
device partition=C:
path \Windows\system32\winload.efi
description Kingston W7 Boot Manager
locale en-US
inherit {bootloadersettings}
recoverysequence {c6b4078b-646b-11e3-b375-87b29ce8704d}
recoveryenabled Yes
osdevice partition=C:
systemroot \Windows
resumeobject {c6b40789-646b-11e3-b375-87b29ce8704d}
nx OptIn
numproc 8
usefirmwarepcisettings No

I used Easus Partition Master 9.3.0 to clone the drive.

My graphics adapter is the Intel GFX 7.5 [Graphics 4600] on the processor itself. I am using onboard DisplayPort to go to my 4K screen.

Is there an EFI shell I could load to check the DXE to BDS transistion, or more specifically the Exposed Platform Interface to see why csm is involved ?
I have nothing else connected besides the Intel I217V Ethernet chipset.
Regards,
10bpc

[parsec]

Re: massive boot delays caused by Asrock UEFI being confused by duplicate drives

CSM is the switch that actually allows an EFI compatible Windows installation to boot. That is, by setting it to Disabled. The default value on all PC mother boards is Enabled, and has been since UEFI firmware was used with PC mother boards. That causes the CSM to "emulate BIOS booting", and among other things chooses the appropriate Windows boot loader.

Your bcdedit information looks like it was set to UEFI booting (path \Windows\system32\winload.efi), which is the same as my UEFI booting Windows 8 installation. OTOH, Windows always creates a MBR partition along with the GPT partition in a UEFI booting installation. That way you can boot in Legacy (BIOS) or EFI (UEFI) modes.

I did notice in your Windows Boot Manager data that a "path" attribute is missing, at least compared to my own bcdedit data. I don't know if that is just an omission on your part, the way bcdedit (version) works on Windows 7, or an indication that you are MBR/Legacy booting (no path setting, default to MBR.)

I've never found an EFI shell that would run from the option in the UEFI, or I don't know how to run it correctly.

I've had mixed luck cloning GPT formatted drives, EasUS (free version) does not support GPT. The Intel Acronis software for their SSDs worked great with GPT formatted disks.

[10bpc]

Re: massive boot delays caused by Asrock UEFI being confused by duplicate drives

Hello, Parsec -
Actually Windows 7 is not UEFI-compliant as some of its drivers, notably VGA, rely upon interrupts that have to be emulated via CSM. So I am really in "progressive UEFI". I just brought CSM because I was not sure whether DXE (or more precisely the EFI driver dispatcher) was intermittently unable to sense, thus relegating an int 13h to CSM for the eSATA drive before the BDS phase.
As it turns out, I connected the SATA drive directly to SATA3_1 and I was able to boot from either drive. You are right that some attributes are missing in the BCD store, but I'll rebuild them by hand at a later point to see whether UEFI relies upon this when the drive is connected via eSATA.
So now I have to figure the topology difference between eSATA and SATA3_5, to see whether UEFI makes a difference, based on the physical eSATA to SATA3_5 on the motherboard, as there might be some switch that deactivates the SATA3_5 when an eSATA drive is connected (or vice-versa), as mapped to the same SATA port. Then I would have to figure whether it's treated as removable or some of the hot-plug capability might be an impedement to UEFI DXE.
The main reason I am doing this is so that I don't have to open the machine whenever I have a booting issue with the primary drive. It's a small case (NUC form-factor), so I am not so anxious to drill in the back or front to pass a SATA cable through.

Indeed Easeus does not manipulate GPT partitions, but the disk cloning function replicates the physical sectors, and I verified that on my own, comparing physical sectors after cloning.

It would be great to have an ITX case with an opening where you can put 2 SATA (or PCIe) SSD, so you could clone when making major changes.

Cheers,

10bpc

[parsec]

Re: massive boot delays caused by Asrock UEFI being confused by duplicate drives

OMG, I forgot that a Windows 7 installation media needs a fix to work correctly for EFI booting. You are right that Win 7 is not as compatible with EFI booting as Windows 8 is (I've only done one Win 7 EFI booting installation and have used Win 8 only after that) but MSoft does say Win 7 is EFI compatible.

See this page for info on fixing Windows 7 media for EFI booting, I've done this and it works:

UEFI Bootable USB Flash Drive - Create in Windows

See section 11, "If Using 64bit Windows 7" for info on the fix. That site has good information on EFI booting, with one small exception, but not their fault. To enable UEFI booting, they tell you to enable Secure Boot. This works, but only because of the side affect this has of disabling the CSM option. I found that simply disabling CSM will enable UEFI booting, since CSM is really the switch between Legacy and UEFI booting. Some UEFI firmware (BIOS is firmware too) does not have the CSM option available to configure. Enabling Secure Boot will disable CSM in that type of UEFI. Since that guide cannot know if a particular UEFI firmware has the CSM option available, they use the Secure Boot method of enabling UEFI booting.

Your ASR board should have the CSM option in the UEFI, my Z87 board does, as well as my Z77 ASR board. IMO, ASR got the CSM settings right, in contrast to other mobo manufactures that make that a confusing mess.

Your eSATA issues should not be as bad as some other ASR boards, since your board is using an Intel SATA port for the eSATA connection, rather than the add on ASMedia SATA chipset. IMO, you must enable hot plugging in the UEFI for the eSATA port. Other users seem to have issues with the eSATA ports on ASR boards, I have never used them.

[10bpc]

Re: massive boot delays caused by Asrock UEFI being confused by duplicate drives

Hello, parsec -
Actually I had a USB key with just data inside my E350 enclosure, and I decided to use it fro Win PE 5.0, yet I came across your message and used RUFUS, loading the Windows 7 Pro OEM iso. Interestingly, I could now boot from anywhere, meaning that the eSATA docked SSD, the internal SATA3_0 SSD or the 4GB USB key could be used as boot device anytime.
One thing I noticed is that when booting the USB2 flash drive, diskpart only showed the internal SATA SSD (as C:) and then the USB key as D: , yet no eSATA SSD was found at that (preinstallation) stage. Also RUFUS only creates one GPT primary partition on the USB key, yet no MSR or ESP, confirming the unique partition on removables.
So the core issue about arbitration and eligibility of boot devices is not resolved, yet I achieved the functionality I needed.

As far as CSM, I was unable to boot when disabling it, getting that dark gray screen from the internal SATA SSD, externally docked eSATA SSD (hot-plug by design) or the USB key. Note that upon such screen I can reboot with ctrl-alt-delete.
Then I decided to use another SSD and try to install Windows 7 Pro OEM from an external USB DVD drive with CSM disabled, and it only went to the point before the 4 color dots merge to form a Window logo. I tried it about 10 times, freezing at the same point. Then I started this is safe mode, and it steadily froze after disk.sys was loaded.
I'll try some other versions of Windows DVD later this week.
I wonder whether a SATA DVD drive would do better, and also whether anyone has been able to boot any Windows 7 DVD on a Z87E-ITX with CSM disabled.
When I received the machine, the BIOS at the time did not even let me boot the DVD-ROM, so I prepared a USB key and installed from there.
I also suspect that commonalities of GUID resulting from cloning does not do too well when all the boot devices presented at once, yet why would UEFI care if there is a duplicate beyond the primary boot device. The instabilities I encountered just made me anxious to clone, and hoping to keep the clone available at all times, rather than having to open the case and remove it every time I clone.

So maybe this progress will hint at what might be peculiar.

Later,
10bpc

[parsec]

Re: massive boot delays caused by Asrock UEFI being confused by duplicate drives

GUIDs must be unique, that is one of their main requirements, and is one of the things that Secure Boot examines to provide security. Note that the uniqueness of GUIDs is not simply a requirement of Secure Boot, it is part of the definition of GUIDs.

My UEFI booting installations of Windows 8 (on two ASR Z77 boards, and one ASR Z87 board) were sourced from Windows 8 ISO files. My previous (and first) UEFI booting installation was also sourced from a Windows (7) ISO file. My Window 7 and 8 installation media are USB flash drives created using the guides available in the link I included above.

When installing Windows 7 or 8 for UEFI booting, you must use (AFAIK) the installation media as described above, with CSM Disabled in the UEFI/BIOS. The formatting of the Windows target drive is done by Windows in the step that provides that option. Windows will recognize the intent for a UEFI booting installation, and format the drive appropriately (GPT, with four partitions, Recovery, System, MSR, and Primary.) This configuration will also boot in Legacy/MBR mode if CSM is Enabled.

I don't know if your installation media and Windows drive were configured correctly, so I can't comment on the failure of your installation to boot with CSM disabled. I would be surprised if your board cannot boot a UEFI installation, since ASRock has had their UEFI/BIOS settings correct on their previous generation Z77 boards, or at least the ones I use.