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.
On a normal hard disk installation of most any EFI-based OS, you'll have, at a minimum, one FAT EFI System Partition (ESP) and one partition for the OS itself. The ESP holds a boot loader for the OS, possibly along with files to support the boot loader (fonts, configuration files, drivers, etc.), and possibly even the OS's kernel. The OS partition holds more-or-less the same OS files you'd find on a BIOS-based installation of the same OS. Depending on the OS, you might have additional partitions, too -- data partitions, a swap partition, etc.
There can be exceptions to this rule, particularly for installation media or emergency disks. For instance, you could put the whole OS in the ESP. Also, most EFIs are happy to boot from partitions that are not ESPs, so you could just have one big non-ESP FAT partition, as you've got. This can work fine for an emergency disk, but I wouldn't recommend setting up a regular OS installation in this way; I'd use a separate ESP and OS partition.
Note that a standard EFI can read FAT, but cannot read NTFS, ext2/3/4fs, HFS+, or any other filesystem. (Apple's EFI can read HFS+, and so can read its boot loader from a Mac OS X root partition rather than from the ESP, but Apple's EFI is the exception rather than the rule. A few EFIs also have ISO-9660 filesystem drivers -- but again, they're exceptions to the rule.) Because FAT is the only filesystem that's guaranteed to be readable by EFI, an attempt to build a boot disk that does not include a FAT partition is doomed to failure, except of course when used on those unusual EFIs that support additional filesystems.
I can't provide a procedure to set up a Windows emergency disk to use separate EFI and Windows partitions, since I'm more of a Linux person than a Windows person. Unless you run into a specific problem with your approach, though, I'd just stick with it; at least you know it works.
Best Answer
Yes it is meaningful.
Further study led to this helpful page on the topic. It discussed the instructions available here, which ultimately led to this repository of EFI shell programs. For my purposes** I used this file from the repository to populate the USB drive prepared as follows:
X:
in windows or/usb-stick
in Linux)X:\EFI\boot
or/usb-stick/EFI/boot
directoryboot
directory.bootx64.efi
With this arrangement, of files on the USB stick, it is now bootable using a UEFI compatible motherboard firmware. (Adam Williamson implores us to not call it a UEFI compatible BIOS!). Put the stick in an enabled USB port in the target computer, do whatever is necessary to boot from the USB stick in UEFI mode, and it will open an EFI shell. Continuing through Bryan Vyhmeister's post allowed me to successfully use the EFI shell to complete the task I had at hand.
** I needed the 'full' version as it gave access to the
mount
function required to get access to the files and executables on the USB drive.