Windows stops booting in UEFI mode after adding another hard drive

[shiin]

This week, I encountered the following strange problem for which I haven't found a final solution so far, though I have found some bandaids. But having a complete solution -or at least a reason why this problem occurs- would be great:


I have a working installation of Windows 7 Professional x64 in UEFI mode. The main disk, SSD #1, contains the following partitions (using GPT): ESP, MSR, system, data. An additional disk, HD #2, with a single data partition (using MBR) is also attached to the system. With this setup, everything works fine.
Now, after adding another disk, HD #3, to the system -my old system disk (bootable, using MBR, one active primary partition and an extend partition with three logical disks)- Windows will no longer boots completely: The boot process begins, the Windows logo is shown. Then, a message is shown in text mode "Windows is loading files" with a loading bar. After a while the boot process stops and I am dropped into the EFI shell. After removing the offending HD #3, Windows boots normally again.

I tried removing HD #2 and only attaching HD #3 together with SSD #1, but this yielded the same problem. Using SSD #1 by itself works fine though. Booting from a Linux live-cd works without problems. All disks and partitions are found and can be mounted. There, I erased the disk signature from the offending HD #3 and now Windows was able to boot and also found all disks and partitions correctly. But after a reboot the same problem reappeared.

My current assumption is that after removing the disk signature, Windows no longer regards HD #3 during the boot process and only setups the disk after booting has finished. But as soon as it has a disk signature again, Windows includes HD #3 in the boot process and probably the partition ordering gets mixed up compared to what Windows expects.

So my question is, why does this boot problem occur and how can I fix it permanently (and will it happen for any new disk I attach to my system)?

 

[Kaktussoft]

Has HD#3 any active partitions?
What happens if you boot with HD#3 attached only?
How did you erase the disk signature? As far as I know you can only update it

 

[Kaktussoft]

Mark active partition on HD#3 as inactive and boot again.

 

[Kaktussoft]

Has HD#3 any active partitions?
What happens if you boot with HD#3 attached only?
How did you erase the disk signature? As far as I know you can only update it

It has active partition ... I didn't read well
disk signature can't be a problem. Only a problem if you cloned from or to HD#3

 

[shiin]

Thanks for the advice. I will set the active partition to inactive and try again when I am back at home.

When I said that I erased the disk signature, I meant that I overwrote it with zeroes (using dd if=/dev/zero of=/dev/sdb bs=1 count=4 seek=440 conv=notrund). This prompts Windows to assign a new signature upon booting.

Booting with only HD #3 attached works (when I switch back to BIOS mode).

 

[Kaktussoft]

Thanks for the advice. I will set the active partition to inactive and try again when I am back at home.

When I said that I erased the disk signature, I meant that I overwrote it with zeroes (using dd if=/dev/zero of=/dev/sdb bs=1 count=4 seek=440 conv=notrund). This prompts Windows to assign a new signature upon booting.

Booting with only HD #3 attached works (when I switch back to BIOS mode).

Although I would reset disk signature in win7 pe, the command looks fine. Is HD#3 really sdb? If you change HD#3 disk signature... its bcd menu is invalid and points to the old disksignature so it can't boot or boots to wrong drive. Even if you fix that (by doing startup repair)... the win7 OS boots but can't find C because registry still points to old signature. Editing the MountedDevices Registry Key

It's not a disk signature problem I think

 

[Saltgrass]

Do you show a Windows Boot Manager, or a UEFI version of the UEFI install drive in the bios? If you set that first in boot order and save, it should just boot to the UEFI. To boot to a MBR install, it has to boot to the drive itself.

You might also try disabling that drive in the boot order list. And beyond that, some bioses can be set to boot only to UEFI....which is how mine is set up.

 

[shiin]

@Kaktussoft:
Removing the active flag from the boot partition of HD#3 didn't work. But in the EFI shell I saw that the second partition of SSD#1 (i.e. the MSR partition) was listed as blk8, meaning after all other partitions of all other hard drives. Maybe this is causes the problem?

@Saltgrass:
The correct boot loader is run (the one of Windows 7 residing in the ESP partition). But during the inital booting procedure, Windows has problems with the additionally attached drive.

 

[Saltgrass]

How about attaching a snipping tool picture of your disk management graphical presentation using the paperclip. Expand it to see at least some of the info on the partitions.

Any chance the additional Hard Drive is having problems and causing out of the normal behavior?

How are you even seeing the MSR partition? It is not visible in Disk Management. The EFI (100mb) is visible.

 

[shiin]

I did some additional tests with an empty hard disk instead of HD#3:
As soon as there is an extended partition on the disk, Windows was no longer able to boot correctly. Two primary partitions works fine, but one primary partition and one extended partition containing one logical disk didn't.

@Saltgrass:
The MSR partition can be seen using diskpart in a command prompt; in the EFI shell of the mainboard or when booting a linux DVD and using the appropriate commands or tools (e.g. gparted).

Using the additional hard disk on its own works fine. By attaching it to another PC that does not UEFI, I can boot without problems.

 

[gregrocker]

Make sure the Win7 on GPT remains set first to boot in BIOS setup during boot with Disk3 attached.

If so then move the data off first then wipe DISK3 with Diskpart Clean Command to remove any boot code that may be interfering.

Copy & Paste - in Windows Recovery Console
Diskpart Clean Command

 

[Saltgrass]

That is a good catch about the logical partition. I would not of thought about that, but I suppose some more testing might be in order.

But the EFI Shell concept interests me. ASUS boards will not normally install a EFI shell, and probably rightly so. But you can load one and access it from the bios. It appears your system actually lists the EFI shell as one of the boot options?

I have never tried playing with it and have just been able to change directories, but I now know what your mean by blk8, since I used the map command.

Where is your shellx64.efi file located, in the EFI partition?

Edit: I just confirmed your findings. With the MBR configured drive and logical partitions on it, the system immediately went into a Recovery environment and ended up with a Grub Rescue shell.

 

[Victor S]

Using the additional hard disk on its own works fine. By attaching it to another PC that does not UEFI, I can boot without problems.

Right. It's the UEFI code that can't handle the circimstances. Work around it.

 

[shiin]

Thank you for the tips so far. I was hoping that I could keep my partitions on HD#3 intact, but this does not seem to be possible.
So, I simply used the trick to replace the disk identifier with zeroes, boot Windows 7 once and copied everything I that needed copying before repartitioning HD#3.

 

[Saltgrass]

I don't even know about changing the Disk Identifier, but would have probably converted some of the logical to primary, after moving stuff around. If that would have even been possible.

I just tried the same thing in Ubuntu, and it seems to boot OK even with the logical partitions.

 

[shiin]

I stumbled upon these two articles:

"Boot failed" error when you start a UEFI-enabled computer from a 64-bit version of Windows 7 or Windows Server 2008 R2 installation DVD (Package 1)
"Boot failed" error message when you start a UEFI-enabled computer from the installation DVD of a 64-bit version of Windows 7 or Windows Server 2008 R2 (Package 2)

Apparently, Windows 7-64bit and Windows Server 2008-64bit have problems with recognizing extended partitions. The boot manager thinks the extended partition is an UEFI partition and thus, the boot process fails.

I haven't tried the proposed hotfixes as they have to be applied to the installation media.

 

[Saltgrass]

Well, I suppose the subject has come up before, but the condition on the link does not happen on my system. But it does seem to appear it is a Windows situation...

I went through an install with the offending drive connected. It worked fine until the first reboot, then the install failed...Perhaps some fixes have already been applied to updated systems.

I see a problem like this being very hard to diagnose, since how many posters would offer info about extended or logical partitions on secondary drives.

But at least we now know some of the symptoms, thanks to you.

Edit: I just tried the same thing in Windows 8. It went into a reboot loop and even after removing the drive, I had to go into the bios and reset the boot device and restart.

Edit 2: Just tested, and even if the errant drive is placed in an External Drive, it messes up the boot. In my case, a USB external enclosure.

 

[Saltgrass]

Thank you for the tips so far. I was hoping that I could keep my partitions on HD#3 intact

I have been thinking about this situation. On my systems, I can plug an offensive drive in after the system is booted. Either by using an external drive, or in my case, an HDD dock.

But if you want to maintain the same number of partitions you had on the old drive, just convert it to GPT (which will normally wipe it) and then add all the partitions you want.

 

[CaptSpot]

I have this exact problem....

Do I understand that I need to convert all partitions on all my discs to GPT and with all partitions being Primary?

 

[gregrocker]

You shouldn't need to have any but the OS HD as GPT.

But if another HD is interfering then I'd wipe it with Diskpart Clean Command as often stray boot code can interfere. Be sure to back up the data as this will wipe the HD.