I made a 2GB Windows XP VHD using Virtual Box by following linuxbyexamples instructions here.
The VHD booted fine when copied to my Easy2Boot USB stick (Verbatim Store n Go USB 3.0 16GB) and booted using DavidB's 'Virtual Machine USB Boot' utility.
However, when I booted it from the same Verbatim Flash drive on my Asus EeePC I observed the following issues which I did not get when booting the same drive using Vbox:
1. E2B took about 2 minutes on the 'Accessing last sector' test but eventually continued
2. E2B took about 2 minutes at the 'Looking for WINHELPER.USB' message
3. When E2B finally got to the E2B menu, I could select the XP vhd file and it started to boot but seemingly hung once the white XP loading bar had completed. If left for a few hours (not sure how long as I wasn't watching) it did eventually get to the XP logo screen (and still there after 4 hrs). There was no LED activity on the USB drive that I could see.
On further investigation, I found that the USB stick was reporting it's size incorrectly to RMPrepUSB. It reported it had 30990336 sectors but actually the last accessible sector was at LBA 30990328.
RMPrepUSB was formatting as MAX size. both of these partition arrangements gave the errors reported above:
2PTNS
PTN1 start=63 size=30,990,210 (30990273)
PTN2 start=30,990,273 size=63 (30990336)
1PTN
PTN1 start=63 size=30,990,273 (30990336)
If I reduced the partition size slightly to 15131MB = LBA 30988288 then there was none of the problems and it all worked fine!
So there are a few things strange with this.
Problem 1 is explained as that is just trying to access the last sector of the last partition and so will always get a problem.
Problem 2 *would* be explained if grub4dos is trying to access the last sectors of any partition it finds - the grub4dos code just uses 'find WINHELPER.USB'
Problem 3 is the curious case - we should be loading XP from a 2GB VHD inside the FAT32 USB partition. now case=2PTNS-PTN1 consists of all accessible sectors, so why does XP hang (actually go very slow) at the end of the loading bar, etc. - presumably it is in real mode and using the EeePC BIOS and accessing non-existent sectors???
Anyway, it seems it is dangerous to rely on USB flash drives reporting their size accurately and I will have to now check that the reported size is correct in RMPrepUSB/RMPartUSB before I create any 'MAX' size partitions!