Windows (using UEFI boot on GPT disk) will no longer boot after adding an MBR hard disk

Question

I have recently installed Windows 7 64 bit on a new SSD using UEFI boot and GPT. The system worked fine. After adding my old system HD to the system (that uses MBR), Windows will no longer boot correctly: When booting from the SSD, the normal boot screen appears and Windows tells me that it is loading files. Then the boot screen disappears and I am in an EFI shell, unable to boot. When I unplug the old HD, Windows boots again without complaints.

Can I somehow boot with this configuration without formating my old hard disk first?

I have an MSI Z77-G65A board. It is configured for UEFI boot, booting from the SSD. Both drives are set as independent HDs (no accidently activated RAID). The SSD is connected to a SATA-6G port and the old drive to a SATA-3G port.

Solution

Deleting the disk signature solved the problem. This can be done with the command

dd if=/dev/zero of=/dev/sdb bs=1 count=4 seek=440 conv=notrunc

in a linux shell with root rights.

Background:
Starting with Windows 2000, Microsoft writes a 4-byte value -the disk signature- into the MBR of each disk so that it can identify each disk. When two disks have the same identifier problems ensue. The afore mentioned command replaces this signature with zeroes which prompts Windows to assign new, unique values.

Note that before overwriting the disk signature, I also tried to replace the bootloader (bytes 0-439 in the MBR) with zeroes. By itself, this didn't help to solve my problem.

EDIT: This solution solved the problem for only one boot-up. When trying to boot a second time, the same issues reappeared. By overwriting the disk signature again, I was able to boot, but again only for one time.
Judging from the provided background above, it seems that Windows chooses an inappropriate disk signature so that the problem reappears...

EDIT 2: It seems that when booting in UEFI mode Windows 7 64bit cannot deal correctly with extended partitions on disks with MBR. The bug is explained here:

hotfix-1 hotfix-2

Apparantly an extended partition is wrongly recognized as an UEFI partition. These two hotfixes should solve the problem, but they have to be already integrated into the install media.

Comments

[Robert]

Have you tried to delete the MBR boot code from the HDD?

[shiin]

How can I do this? I read that I can use dd if=/dev/zero of=/dev/hda bs=440 count=1 on a linux machine to overwrite the boot code - if /dev/hda is my old HD. Is this the only option (and is it correct for that matter?)

[wds]

I ran into something very similar. I think the easiest way to solve it is by converting the second drive to GPT (with gdisk under linux, do back up the MBR with sfdisk or similar). Have to boot from the install media a few times and do the various boot repairs, after that I got it to boot.

[wds]

Another note: you should be able to change the identifier with diskpart (list disks, select disk #, uniqueid disk ...), so no need to zero it out manually. I only found this out after already converting to GPT.