Creating a Bootable Windows 7 USB Drive for Installation / System Repair / Recovery - First Cut

Normally, if I booted a computer from a Windows 7 installation DVD, I could get into System Recovery Options (e.g., Startup Repair, System Restore, Command Prompt) that would let me run various diagnostics.  Unfortunately, my laptop did not have a CD/DVD drive.  So if I wanted to see those Windows 7 startup repair options, it seemed that I would have to find a way to do so by booting the computer from a USB flash drive instead.  This post describes the steps I took to develop a USB drive that would give me those options.  It also incidentally describes how to make a bootable copy of the Windows 7 installation DVD on a USB drive.

One approach was to put the entire Windows 7 installation DVD on a USB drive.  The DVD contained about 3GB of material, so this would require a USB drive of 4GB or larger.  Another approach was to put just a Windows 7 System Repair or Recovery CD on a USB drive.  This would require only about 150MB, so I could use a smaller, older, cheaper, or otherwise unused USB flash drive.  The Recovery CD option might load faster than a full Windows CD, but it would not be useful for installation or for recovering system files.

Either way, the first step was to get the necessary files.  The Windows installation files would traditionally be purchased on a DVD, but it was also possible to download them.  Similarly, the Windows 7 System Repair Disc was ordinarily a CD, but it could be copied or converted to files on a hard drive.

To get a System Repair Disc, I had to search my computer for "system repair disc."  That didn't work in my case -- I must have renamed the relevant shortcut -- so I searched for various combinations of "create," "system," "repair," and "recovery."  I could also have used Control Panel > Backup and Restore > Create a system repair disc.  The option of downloading the file(s) needed for a system repair CD was apparently disappearing.  In any case, eventually I found and used the link to a little Windows 7 program whose title bar read simply, "Create a system repair disc."  This created the recovery CD.

Next, the files that weren't already in ISO format needed to be converted to ISO.  The downloaded versions of Windows 7 evidently came in ISO format.  By contrast, the installation DVD and the recovery CD were not in ISO format.  To convert them to ISO, I started by using Magic ISO Maker.  It warned me that it would not create an ISO larger than 300MB, but this seemed to be a bluff to motivate an immediate purchase.  Format Factory would apparently have been one among many freeware alternatives.  When I remembered that ImgBurn would create ISOs from files or discs, however, I deleted the Magic ISO output and used ImgBurn instead, since it had worked well for me in other sorts of projects in the past.

Once I had an ISO, I had a choice between two different approaches to get it properly unpacked and operational on the USB drive.  A dedicated USB drive would focus solely on one version of Windows 7 (e.g., 32-bit vs. 64-bit, Home vs. Ultimate).  This dedicated approach seemed likely to be relatively simple and reliable, and would probably be all that most users would need.  By contrast, a multiboot USB drive would allow the user to install and/or run two or more different operating systems (potentially including e.g., Windows XP and Linux).  I decided to go with the dedicated, single-system approach.

I started with the Windows 7 system recovery CD, which ImgBurn had now converted to a file I called Win7SysRepair.iso.  There seemed to be several ways to put this ISO onto a bootable USB drive.  One approach involved using Grub4DOS.  Another was to use Microsoft's Windows 7 USB/DVD Download Tool.  I ran that Tool.  It called for a few simple steps.  First, I plugged in the little 512MB USB flash drive on which I was going to install the Windows 7 system recovery CD files.  Then I pointed the Download Tool toward the newly created Win7SysRepair.iso.  I clicked the USB Device button, and the Tool found the USB drive.  I clicked Begin Copying and confirmed that it was OK to erase the USB drive.  The tool said, "Creating bootable USB device."  The first time I tried it, it failed, with this error message:

We were unable to copy your files.  Please check your USB device and the selected ISO file and try again.

I assumed this was due to interference from AntiRun, which I was using to keep an eye on USB drives.  I shut down AntiRun and tried again.  But no, the Tool failed the second time too.  To troubleshoot this problem, I ran a search and saw that this was a rare error.

The problem seemed to be that the Tool was formatting the USB drive as NTFS.  I thought the solution would be to go to Start > Run > diskmgmt.msc and quick-reformat the USB drive with a FAT32 file system (using a volume label of no more than eight characters).  But I still got the same error.  Another source said the problem was that the Microsoft programs (diskmgmt.msc and also the Tool) failed to use the Clean command.  In other words, my USB stick had residual formatting from some previous use.

The advice was to fix this problem by opening a command window with Administrator rights and type "diskpart" at the prompt.  This started the DiskPart program, with its own DISKPART> prompt.  The next step was to type "list disk" to see what drives were connected to the computer.  This showed me that, as expected, the last disk was the smallest:  491MB.  That was surely my USB drive.  (It seemed pretty important not to be reformatting the wrong drive.)  That 491MB drive was Disk 2.  So I typed "select disk 2."  It informed me that Disk 2 was now selected.  I typed "list disk" again to check and, sure enough, there was an asterisk next to Disk 2.  So I was ready to type "clean."  It said, "DiskPart succeeded in cleaning the disk."  With that done, I could type these remaining commands in DiskPart, one at a time:

create partition primary
select partition 1
active
format quick fs=fat32
assign
exit

I exited the command window and tried Microsoft's Windows 7 USB/DVD Download Tool again.  It still failed.  I tried again, this time using a different USB drive.  This time was even worse:  previously, it had failed at the 99% mark, but with this drive the copying process didn't even start.  I tried using an ISO built from a System Recovery CD created on another computer, running a different version of Windows.  But the Windows Download Tool said this:

Invalid ISO File

The selected file is not a valid ISO file.  Please select a valid ISO file and try again.

I got that error twice, with ISOs created by ImgBurn and also by Magic ISO Maker.  It was time to give up on the Microsoft Download Tool, reformat the USB drive, and try another approach.

I went back to look at the Grub4DOS approach mentioned above.  I wouldn't be using it to install multiple bootable operating systems on my little 512MB USB flash drive, but it looked like a straightforward process anyway; I figured maybe the education would come in handy later.  For this approach, I needed to download and install MultibootISO.  I found what appeared to be a popular, current version of this program on a Pendrivelinux webpage.

On closer inspection, what we downloading was now called YUMI (short for Your Universal Multiboot Installer).  YUMI was apparently a successor to both MultibootISO and Universal USB Installer.  YUMI was portable; no installation required.  YUMI didn't have a built-in option for installing Windows 7.  I got the feeling that YUMI was not going to replace MultibootISO for this particular task.  Nonetheless, I tried.  In YUMI, I selected "Try an Unlisted ISO."  YUMI didn't complain that the ISO was invalid.  It seemed to think it had succeeded.  Sadly, the USB drive wasn't bootable, at least not in the laptop where I tried it.  I tried again and, whoa, success!  Apparently I had just not hit Esc quickly enough to bring up my laptop's bootable USB drive menu when the laptop was first starting up, or maybe I had hit Esc too many times and escaped my way right out of that menu.  But now, on this second go, YUMI gave me the Windows 7 recovery CD functionality, running from my USB drive.

Well.  This YUMI thing was pretty cool.  When I started this post, I thought I would just be content with the Windows 7 installation DVD. For that purpose, my spare 4GB USB flash drive was sufficient.  But now I wanted to try YUMI with a large USB drive that would accommodate the Windows 7 installation DVD as well as other operating systems and other bootable CDs.  But this would have to await purchase of a 16GB or larger USB flash drive.

ASUS Eee PC: Booting from USB: First Cut

I needed a way to boot an ASUS Eee PC with Windows 7 installed.  The mission was to look at, and possibly replace or delete, a certain file in a particular directory on the Eee's drive C.  The Eee didn't have a CD/DVD drive, so it seemed that what I needed was a bootable USB drive with file management capabilities.  I knew the Eee was capable of being booted that way, because I had already successfully booted it with USB drives containing Acronis True Image and GParted.  Unfortunately, I had not succeeded in previous attempts to boot Ubuntu or some other program or operating system, so as to examine files and folders.  This post describes some more attempts along those lines, oriented specifically toward getting various programs to boot an Eee from a USB drive.

Hiren's Boot CD

More than a year earlier, I had made a similar attempt related to Windows XP.  In that attempt and previously, I had become familiar with various bootable USB jump drive packages, including the Universal Boot CD for Windows (UBCD4Win) and BartPE.  It now appeared that Hiren's Boot CD (HBCD) was an especially good option.  I noticed that it included DBAN, GParted, and other tools that I would like to have on a bootable USB thumb drive.  Following the instructions provided by Hiren and Pankaj (as also shown, somewhat confusingly, on a different website I found later), I took these steps:

1. I plugged in my USB flash drive -- 4GB, though they said 512MB was sufficient.  I suspected that a drive larger than 4GB would fail due to their use of FAT32 formatting.
2. I downloaded and ran their USB formatting program (changing no settings).  Then I downloaded and ran their grub4dos program as Administrator.  The device I selected was a Disk (not File).  It was a 4GB USB drive, so on my system that was hd3, which they described as "3851M" (i.e., not quite 4,000 megabytes).  I clicked Refresh next to Part List and selected Whole Disk (MBR).  I clicked Install.
3. I downloaded the Hiren's BootCD zip file.
4. I unzipped the BootCD zip file and found that it contained an ISO.  I didn't want to burn a CD in order to proceed with the next steps, so I tried using Virtual CDROM to position that ISO as a virtual CDROM drive. Specifically, in VCD, I clicked Mount, navigated to the ISO, selected it, and clicked OK. The mount failed.  I saw that Virtual CloneDrive (VCD) seemed to be more frequently downloaded, so I tried that.  When I started it, it gave me only a few options.  I adjusted those.  Now I had an icon in the system tray.  I right-clicked on that and got an option to mount drive G, which Windows Explorer was now showing as "BD-ROM Drive."  That opened up a dialog.  I navigated to the ISO.  That seemed to work.  The HBCD instructions said to copy everything from the mounted ISO to the USB flash drive, so I did.  There was some flaky behavior here:  at one point I basically had to restart Windows Explorer to see the contents of the mounted ISO again, but in the end I was able to copy those contents to the jump drive.

With those steps done, I plugged the USB drive into the Eee and rebooted.  I had to hit F2 repeatedly when it first started booting, because I had learned it did not remember boot settings.  I set the USB drive as the first drive to boot.  The USB stick did not boot.  The relevant error message seemed to be, "Cannot find GRLDR."  In other words, the grub4dos step seemed to have failed.  I looked at the directions and tried again.  This time, I skipped the formatting step -- the drive was already formatted -- and went directly to the grub4dos step presented on the alternate HBCD webpage that I had more recently discovered.  But everything seemed the same.  I tried booting the Eee again with the USB stick.  Same result.  I looked at the HBCD FAQs page.  It said this:

If you are getting GRLDR error, or if usb booting is halting with a blinking dos window, or if you are facing with smilar situations, try using syslinux to boot grub4dos. To do that, download syslinux.zip (145 KB), extract its contents, run ‘RunMe.bat’ inside of the extracted folder and follow its steps.

Oy.  But, OK, I downloaded and unzipped syslinux.zip and clicked on its RunMe.bat file.  It did copy files to the USB drive, as promised.  Now what?  I tried booting the Eee with the USB stick again.  That definitely worked.  I was now looking at a GRUB4DOS menu that listed a half-dozen programs.  Unfortunately, none of them was HBCD.  I tried a Google search for info on the HBCD "cannot find GRLDR" error.  Got a couple dozen hits, mostly in Vietnamese.  Bizarre.  I didn't like Bing, but an equivalent Bing search didn't have that problem.  Regardless, I didn't see a solution.  Back at one of the HBCD instructions pages, I noticed that they said I should have run grub4dos as Administrator.  I hadn't done that.  I was already logged in as Administrator, but maybe that wasn't sufficient.  I right-clicked on grubinst_gui.exe and clicked Run as Administrator.  That brought up the same Grub4Dos Installer dialog as before.

I went through the steps again.  In the process of abandoning the one HBCD instruction page for the other, I had also overlooked another step:  "Copy grldr and menu.lst (from HBCD folder) [actually found in the grub4dos\grub folder] to the usb drive."  I did that now.  The menu.lst (that's MENU.LST, with an L, not MENU.1ST, with a one) file overwrote the one that syslinux had placed on the USB drive.  I wasn't sure how this was going to work:  I hadn't removed syslinux from the USB drive.  But I gave it a try.  This time, I got a somewhat longer Grub4DOS menu.  Unfortunately, I didn't see most of the tools that had interested me originally; and after a moment, the computer went ahead and tried to load Windows 7, even though I had not to my knowledge issued any command of that sort.  I rebooted.  It seemed I must have left the cursor sitting on the option for "Custom Menu ... (Use HBCDCustomizer to add your files)," because that one was ready to boot automatically in just a few seconds.  Hitting Enter on that item opened a longer list.

What I wanted, in the particular situation, was something like Ubuntu, with which I could use a GUI to change files in a particular folder on the Windows 7 programs drive C.  I decided to try Eeebuntu 3.0.1 Netbook Remix.  It gave me an error message, and within 10 seconds I was back at the Grub4DOS menu.  I tried Ubuntu 10.04 Netbook Remix.  I tried Ubuntu 10.04 (GNOME Desktop x86).  All of these were giving me "Error 15:  File not found."  They seemed to be trying to load an Ubuntu (or whatever) ISO.  Was I supposed to have that on a separate USB drive, also plugged into the netbook?  I tried Eeebuntu again.  It seemed to be looking for eeebuntu-3.0.1-nbr.iso.  A search led to Aurora and Wikipedia webpages indicating that Eeebuntu 3 was based on Ubuntu 9.04, which at this point was two years old and outdated in a number of ways.  I wasn't that much more excited about the HBCD option to load Ubuntu 10.04, also a year old.

I had been thinking, or hoping, that HBCD would somehow miraculously combine all those dozens of CDs on one USB stick, but now that was just not materializing.  If I was going to be using HBCD just to boot Ubuntu, why not have the latest Ubuntu on a stick?  Make it simpler and more up-to-date.  I went to the Ubuntu download webpage and noticed that they were providing instructions that simply involved the Universal USB Installer and a downloaded Ubuntu ISO.  I ran my copy of Universal USB Installer and saw that it was willing to install Ubuntu 11.04 on a stick.  I was about to proceed with that, but then I wondered whether some other Linux distribution would be better for the Eee.  A search led to one webpage in which some people said that plain old Ubuntu was fine.  Another webpage suggested Leeenux.  I was familiar with Ubuntu, so I decided to try that (again).

When I had pretty much settled on the approach of using Universal USB Installer to download and install the ISO on my USB drive, it occurred to me that the advantage of HBCD was that I could have a bunch of ISOs on a companion USB drive, and could boot them all with the HBCD USB drive.  In this concept, I couldn't do it all with one drive, but I could do it with two, especially now that USB drive capacities were increasing:  my second USB drive could hold a dozen ISOs.  I revisited the option, presented in HBCD, of using HBCD Customizer (above).  I was thinking this might be a way to run Ubuntu 11.04 among others.  Thing is, I couldn't find it.  I didn't want to download it from just any random webpage -- it could be virus-ridden -- but it seemed like WOT-banned sites were featuring it.

XBoot

Another search led to some indications that the UBCD4Win was also customizable, so I turned to that possibility.  This search seemed more promising.  On closer examination, though, it appeared that creating this device required a Windows XP CD.  I had one, but others might not.  That requirement would also presumably have prevented me from using it to install Ubuntu.  So I turned to its cousin, UBCD (not for Windows).  A search led ultimately to Pendrivelinux.com, where I discovered XBoot, which was yet another possibility (along with YUMI and the Linux-based MultiSystem. The XBoot instructions required me to download the latest XBoot as well as the other ISOs that I would want to use.  I decided to start with ISOs for GParted, Ubuntu 11.04 (which, as I recalled, would not automatically contain GParted), Darik's Boot & Nuke (patched for XBoot), and Acronis True Image Home.  I had purchased a copy of Acronis, and would have been glad to recommend a freeware alternative, but I wasn't immediately finding one with an ISO.  There would probably be other ISOs I would want to add later, but this would do for now.  I wasn't as interested in some of the programs that were supposedly included in Hiren's Boot CD, for instance, because I was keeping a copy of my customized Start Menu (containing portable applications) on a separate USB drive, and many of the programs included in Hiren's were already on that Start Menu.  Many of those programs required an operating system (especially Windows) to be booted already, so I wasn't sure how or why I would be using them on a multiboot USB drive, though of course it could be handy to have everything on one large USB drive.

So anyway, I downloaded, unzipped, and ran XBoot.  It was a portable, which was nice.  I had created a folder for the four ISOs mentioned in the previous paragraph (i.e., GParted, Ubuntu, DBAN, and Acronis), so now I just dragged those ISOs over and dropped them on the XBoot program.  The instructions seemed to say I was supposed to do something with the QEMU and Edit MultiBoot USB tabs, but I couldn't quite figure it out.  I decided to start simply, by clicking the Create USB button on the first (Create Multiboot USB/ISO) tab.  This brought up a dialog giving me the options of using Syslinux or Grub4dos as my bootloader.  They recommended Syslinux, so I went with that.  The dialog automatically identified my USB drive.  XBoot then seemed to be copying my ISOs to the USB drive.  When it was done, it said, "USB created successfully!!  Check by running it on QEMU?"  I wasn't sure if that meant it was going to reboot the system into the QEMU operating system.  I wasn't in the mood to have my desktop system rebooted right then, so I said no.  Then I looked and saw that QEMU was just an emulator, so I probably could have tested it safely.  It wasn't too late:  the QEMU tab within XBoot allowed me (after a Refresh) to run the USB drive and, by golly, it seemed to work.

I plugged the USB drive into the Eee and rebooted it.  As in QEMU, it gave me the option to go into Utility, Linux, or Help.  The Utility submenu had Acronis, GParted, and DBAN.  I went into Linux in the main menu.  Ubuntu was the only option there.  I chose that option.  It ran.  I was able to access folders and go online in Firefox in Ubuntu.  Later, I discovered that, unlike the three other ISOs,  Acronis did not boot.  Acronis could be made bootable on a USB drive by installing the Acronis software and using its Bootable Rescue Media Builder.  I had already done that with another USB drive.  What I needed now was apparently not an ISO of the Acronis CD, but rather an ISO of that USB drive.  I used ImgBurn to create that.  Then I went back into XBoot.  There didn't seem to be an alternative to redoing the whole bootable USB creation process, so I did that.  This time, when the process finished, I tested all of the USB drive boot options in QEMU.  I saw that it had not deleted the previous options; I now had two Acronis entries.  One hung the system; the other successfully started Acronis.  I wanted to edit this menu, so I went to XBoot's Edit MultiBoot USB tab.  When I clicked the "Edit Syslinux menu file" button, I got an error:  "No application is associated with the specified file for this operation."  When I clicked Edit Grub4dos Menu File, it asked what program I wanted to use to edit it.  I tried Notepad.  That worked.  It opened menu.lst, which turned out to be in the root (top level) of the USB drive.  Menu.lst told me that the menu for the Utility section was on the USB drive too, in /boot/grub4dos/utility.lst.  My editing efforts were not too successful, so ultimately I just wiped the drive and started over.  I was not able to get Acronis to work, and in a subsequent retry the Ubuntu also stopped working.  I reformatted the USB drive (not Quick Format) and then redid the XBoot process without Acronis, and now the Ubuntu was failing to load.  I tried that twice.

Assuming I could get Ubuntu working again on the USB drive, the solution, so far, was to use XBoot, a Windows program, to load several program ISOs on a single USB drive.  The Eee would boot from this USB drive and would give me a menu allowing me to choose among those programs.  There seemed to be no practical limit on the number of ISOs that could be loaded this way.  The USB drive seemed to be capable of running just one ISO at a time, and Ubuntu loaded from the USB drive did not seem able to see the contents of the USB drive itself, so it did not appear that stray utilities added to the USB drive would be available to operating systems (e.g., Ubuntu) booted from the USB drive.

Grub4DOS

I wanted to try again to get a multiboot USB drive that would work with Acronis as well as with Ubuntu, DBAN, and GParted.  I found detailed instructions on using Grub4DOS in a way that seemed to meet this need.  The steps were as follows:

1. Download and unzip the needed files.  These were Grub4DOS 0.4.4 (2009-06-20) and the Grub4DOS installer (grubinst-1.1-bin-w32-2008-01-01.zip).
2. In the Grub4DOS-Installer folder, right-click and run grubinst_gui.exe as Administrator.  (This was familiar from the steps described above.)  Select Disk, click its adjacent Refresh button, and select the drive on which you want to install Grub4DOS.  The size of the drive was a clue.  In my case, I was installing to a 4GB flash drive, so I selected the one that was 3812MB in size.
3. Still in the Grub4DOS installer, click the Part List Refresh button.  This time, I got an error:  "Invalid partition table, if you still want to install, use the --skip-mbr-test."  This was presumably why Ubuntu had failed to boot on the last couple of tries with XBoot (above).  But I had already reformatted it!  Some advised using the HP USB Disk Storage Format Tool (HPUSBDisk.exe).  I closed down the Grub4DOS Installer and tried that.  I set it to do a quick format and not to create a DOS startup disk.  That did the trick; I was now able to go back in and select "Whole Disk" next to the Part List, as advised back in the Grub4DOS instructions.
4. Unlike the situation above, the instructions this time advised checking the "Don't search floppy" box (but nothing else) and then clicking Install.  That succeeded.  I closed the Grub4DOS Installer.
5. From the unzipped Grub4DOS download folder, I copied grldr to the USB drive.
6. Skipping to section 3 of the instructions (since I wanted multiple ISOs on the USB drive), I ran Acronis True Image Home on the desktop computer, where I had installed it.  I went to the Main Screen > Create bootable media.  When I got to the Bootable Media Type Selection section, I chose ISO Image.  I saved it to the same folder on the hard drive where I had my GParted and other ISOs.
7. I created menu.lst in that ISOs folder, so I'd have it in case I wanted to create another USB drive or retry with this one.  To create menu.lst, I started by copying and pasting this text into Notepad:

   timeout 10
   default 0
   
   title Acronis True Image Home 2011
   map --mem (hd0,0)/AcronisTrueImageHome2011.iso (hd32)
   map --hook
   chainloader (hd32)
   boot
   
   title CommandLine
   commandline
   
   title Reboot
   reboot
   
   title Halt
   halt

   The parts that could be edited were the title (Acronis True Image Home 2011), which could be anything I wanted, and the ISO's filename (AcronisTrueImageHome2011.iso), which had to match what I had actually called the ISO.  (Spaces in the ISO's filename would apparently have been a bad idea.)  I didn't change the (hd32) part of the "map" line.  The "--mem" part of the first "map" line was optional.  It apparently made the ISO load into RAM.  With 2GB of RAM on my Eee, I felt that I could do this with all of my ISOs.  If that had failed, I could have removed "--mem" from that line.
8. I copied the finished menu.lst over to the root of the jump drive. So now the USB drive contained two files:  grldr and menu.lst.
9. I copied the Acronis ISO over to the USB drive, so that menu.lst would be able to find it.  The instructions said I could have put it into a folder of its own, as long as the map command in menu.lst could find it (by referring to e.g., /subfolder/AcronisTrueImageHome2011.iso).
10. While I was at it, I copied the other ISOs (GParted, Ubuntu, DBAN) as well.  I used the patched DBAN ISO mentioned above.
11. I edited menu.lst so that it would include references to all four ISOs.  As just shown, it already had five lines referring to the Acronis ISO, beginning with "title."  So I copied, pasted, and edited those five lines for each of the other ISOs I wanted to boot.  Here, again, I was allowed to change only the title itself (e.g., changing "Acronis True Image Home 2011" in the copied "title" line to GParted, DBAN, or Ubuntu) and the name of the related ISO on the first "map" line.
12. I changed the timeout from 10 to 20 seconds.
13. Again, I made these changes to the copy of menu.lst that I had created in the ISOs folder on the hard drive, so that I would have a copy of it, and then copied it over to the jump drive.

I tried booting the resulting USB drive in the Eee.  It came up with a genuine menu.  First time around, it tried to boot Ubuntu automatically after 20 seconds' delay (that being the first item on my menu.lst), and failed.  Second time, I didn't let that happen; I arrowed down to Acronis (next item) and tried that.  That worked.  When I exited Acronis, it rebooted, and this time I tried DBAN.  That worked too.  Another reboot, another program:  GParted did not work.  It gave me a screenful of information, including this:

BOOT FAILED!
This Debian Live image failed to boot.
Please file a bug against the 'live-boot' package or email the Debian Live mailing list at debian-life@lists.debian.org, making sure to note the exact version, name and distribution of the image you were attempting to boot. . . .
Unable to find a medium containing a live file system.
BusyBox v.1.18.4 (Debian 1:1.18.4-1) built-in shell (ash)
Enter 'help' for a list of built-in commands.
/bin/sh: can't access tty; job control turned off
(initramfs)

It seemed that the Ubuntu/Debian live images (Ubuntu 11.04 and GParted) were not working with Grub4DOS.  A search suggested that others were having this problem too.  One post suggested that changes involving "kernel" and "initrd" might help, but I was not sure how to configure them.  I wondered if the --mem option was screwing up the Linux items, so I edited menu.lst to remove that option from those items.  For GParted, that worked, to the point of giving me the initial menu, but then it led back to the BOOT FAILED! screen (above).  For Ubuntu, I wound up back at the same message as I had gotten first time -- similar to the one just quoted, but much briefer.  It said something about BusyBox but then said, "(initramfs) Unable to find a medium containing a live file system."

Grub4DOS:  Ubuntu

I was perhaps experiencing the problem that "Some linux distributions just refuse to boot from an ISO file on a USB drive."  Of course, Ubuntu could be booted from a USB stick; it was the ISO part that was causing the problem.  This was apparently "experimental."  It seemed that the "kernel" and "initrd" commands could be copied literally, at least for Ubuntu 10.10; I wasn't finding much advice for 11.04.  The approach shown in a couple of websites was like this:

title Ubuntu 10.10
find --set-root ubuntu-10.10-desktop-i386.iso
map ubuntu-10.10-desktop-i386.iso (0xff)
map --hook
root (0xff)
kernel /casper/vmlinuz file=/cdrom/preseed/ubuntu.seed boot=casper iso-scan/filename=ubuntu-10.10-desktop-i386.iso splash
initrd /casper/initrd.lz

I adjusted menu.lst to replace the previous Ubuntu entry with these lines, copied the Ubuntu 10.10 ISO to the USB drive, and tried that.  (Note:  the line beginning with kernel is long; it wraps.  The next line after "kernel ..." is "initrd ...")  This gave me "Error 60:  File for drive emulation must be in one contiguous disk area."  A search led to the advice to use either Contig or WinContig to defragment the ISO on the USB drive -- to defragment a single file, that is, not necessarily the whole drive.  I was curious whether this kind of separate tool was necessary.  In Windows Explorer, I right-clicked > Properties > Tools tab > Defragmentation.  I selected the USB drive and clicked "Defragment disk."  In seconds, it said, "0% fragmented."  I tried booting again.  Now it said "Error 15: File not found" for the Ubuntu 10.10 ISO.  I couldn't figure this out:  the file was right there.  I re-copied the ISO over from the hard drive to the USB drive and, this time, I defragmented it with WinContig.  It offered to run on the whole USB drive after all, so I went ahead with that.  Basically, I was wondering if there was some kind of magic about the WinContig way of defragmenting.  It took much longer than the Windows defragmenter had taken -- a couple of minutes, altogether, just for that little USB drive.  Eventually I realized that it was hung.  I tried to use Task Manager (Ctrl-Alt-Del) to kill it, but that didn't work.  I rebooted the system.

I tried booting the Eee again with the USB stick.  This time, I got "Error 27: Unrecognized command."  I thought that maybe the Ubuntu ISO could not be in the root folder, so I put it into a subfolder called ISOs, and modified the three references to it (in the menu.lst lines quoted above) accordingly.  (The final menu.lst is shown below.)  Since things were not going well, I went back and re-did the 13 steps listed above.  This time around, they were like this:

1. Run the HP USB Disk Storage Format Tool on the USB drive.
2. Run grubinst_gui.exe as Administrator.
3. Copy grldr from the unzipped Grub4DOS download folder to the "MultiBoot" folder on the hard drive where I was saving everything that I would be copying to the USB drive.  That folder now contained grldr and menu.lst in its top level, and the ISOs in its "ISOs" folder.
4. Copy the contents of the MultiBoot folder to the USB drive.

This time, we were back to the good old days, when the Ubuntu ISO would actually get as far as loading its splash screen and seeming like it was going to start.  Evidently it helped to start over and/or to put the ISO in a subfolder.  (I wondered whether properly ejecting the USB drive from the desktop, rather than just yanking it out, made a difference too.)  And then, woo hoo, we had liftoff!  Ubuntu was operational.  I fiddled with it for a minute.  Nautilus worked; Firefox worked.  Fantastic.  I quit Ubuntu and tried the other ISOs on the menu.  GParted, splash screen ... BOOT FAILED.  Rats.  Acronis:  Orbit!  Finally, DBAN:  no problem.

Grub4DOS:  GParted and Parted Magic

So how to make GParted work?  A search led eventually to some suggestions that Parted Magic (which evidently contained GParted among other things) or RIPLinuX (which evidently contained Parted Magic plus) might be the superior tool and easier to put on USB.  I was willing to use any of the above, as long as I could figure out how to put it on a multiboot USB -- preferably, at this point, using Grub4DOS.  I looked into Parted Magic, reasoning that, again, I probably wouldn't need all the stuff on RIPLinuX, and it might load slower.  The contemporary way to put Parted Magic on a USB stick by itself was to use Unetbootin.  But how to put it on a multiboot USB?  One webpage claimed that I could download and unzip a USB version, install its contents to the root of the USB drive, and it would run with a modification of menu.lst.  Sadly, that version was no longer available at the cited SourceForge link.  That webpage made similar claims for Memtest86+, BartPE, and UBCD, and I was tempted to experiment with those as well.  I found other webpages providing seemingly easy instructions for adding Hiren's BootCD and Memtest86+ as well.  Most tempting was the option of adding a Windows 7 Recovery CD.  I decided to return to these possibilities later, time permitting.

But continuing with the Parted Magic investigation, I began to find that I probably should have called the subfolder "images" rather than "ISOs" -- referring, there, to the folder on the USB drive where I had put the ISO downloads.  So I made that change in menu.lst and in the folder structure now.  Then I found a thread that seemed to offer a way to make Parted Magic 5.10 work with Grub4DOS.  I downloaded the ISO of that fairly recent version and put it into the images folder on the desktop computer.  I replaced the GParted lines of menu.lst; and when the Parted Magic 5.10 ISO was finished downloading, I opened it with 7zip, extracted the pmagic folder, and put that into the images folder as well -- because that's what they did in that thread, for what reason I had no idea.  I copied the revised contents of the MultiBoot folder on the hard drive to the USB drive and tried booting the Eee with it.  The Ubuntu ran (again); the Parted Magic ran too, though for a minute there I thought it was hung.  Apparently it was taking it a while to load itself into memory.  It really had a lot of tools in it -- not only GParted but also Ghost for Linux, Partition Image, etc.  I didn't think I would be needing much else in the near future.  This success with Parted Magic version 5.10 made it unnecessary for me to look further into other posts relating to versions 5.9, 5.8, 5.7, 5.6, 5.5, 5.5, 4.5, or 4.3.  Acronis still ran, and DBAN still ran.  I was nearly home.

Grub4DOS:  Windows 7 Recovery CD

That discovery (above) of the possibility of adding a Windows 7 Recovery CD to my multiboot USB stick was just too good to pass up.  The instructions said that I would need to start by downloading Microsoft's Windows 7 System Recovery Disc.  This gave me a small torrent link called "Windows 7 32-bit Repair Disc.torrent."  I had already installed uTorrentPortable, so I used that to run that link and download the 143MB recovery disc.  When that was downloaded, I had an ISO that, once again, I could mount as a virtual CD using Virtual Clone Drive.  I downloaded and ran WinSetupFromUSB.  It looked like this might be destructive of my hard-won success on the USB drive, so I did this with another, blank USB drive.

In WinSetupFromUSB, I clicked Refresh to see the correct USB drive.  I clicked the Bootice button.  A dialog popped up.  I selected Process MBR and then Grub4DOS and clicked Install/Config.  I checked "Don't search floppy for GRLDR" but otherwise left everything else as it was, and clicked "Save to disk."  That seemed to be the end of Bootice, so I backed out of there; but then the Bootice dialog returned.  I killed it again, and this time it stayed dead.  Back in the main WinSetupFromUSB dialog, I realized I was suffering from a dearth of guidance.  The webpage I had been loosely following really wasn't cutting it.  Back to the previous one.  It seemed I should have formatted the USB drive while I was in Bootice, so I did that now:  USB-HDD, single partition, FAT32.  Now redo the Process MBR - Grub4DOS step just mentioned.   Now, back in the WinSetupFromUSB dialog again, I clicked the Vista / Win7 option, navigated to the virtual CD drive, and clicked GO.  A minute later, it was done.  I clicked Test in QEMU > GO.  It said, "Windows is loading files ..."  That took a while.  Then QEMU produced a BSOD.  This, I decided, was a project for another day.  A worthy one, if it worked, but a whole new undertaking, by the time I got all these other tools (Parted Magic, Acronis, DBAN, Ubuntu) working on that other USB drive.

Summary

It seemed that WinSetupFromUSB might be a good place to start, for someone who was beginning a voyage of discovery, on the way to creating a multiboot USB drive, and had some time to spare.  WinSetupFromUSB allowed the same Grub4DOS tool that I had found useful in the approach I took.  My approach is summarized in the four steps enumerated above:  run the HP USB Disk Storage Format Tool on the USB drive; run grubinst_gui.exe as Administrator; copy grldr from the unzipped Grub4DOS download folder to the "MultiBoot" folder on the hard drive where I was saving everything that I would be copying to the USB drive; download the relevant ISOs to the "images" subfolder in that MultiBoot folder; and then copy the contents of the MultiBoot folder to the USB drive.  Those contents included the menu.lst file, which in the end looked like this:

timeout 20
default 0

title Ubuntu 10.10
find --set-root /images/ubuntu-10.10-desktop-i386.iso
map /images/ubuntu-10.10-desktop-i386.iso (0xff)
map --hook
root (0xff)
kernel /casper/vmlinuz file=/cdrom/preseed/ubuntu.seed boot=casper iso-scan/filename=/images/ubuntu-10.10-desktop-i386.iso splash
initrd /casper/initrd.lz

title Parted Magic 5.10
root (hd0,0)
map --heads=0 --sectors-per-track=0 (hd0,0)/images/pmagic-5.10.iso (0xff) || map --heads=0 --sectors-per-track=0 --mem (hd0,0)/images/pmagic-5.10.iso (0xff)
map --hook
chainloader (0xff)

title Acronis True Image Home 2011
map --mem (hd0,0)/images/AcronisTrueImageHome2011.iso (hd32)
map --hook
chainloader (hd32)
boot

title Darik's Boot and Nuke
map --mem (hd0,0)/images/dban-2.2.6_i586-fixed.iso (hd32)
map --hook
chainloader (hd32)
boot

title CommandLine
commandline

title Reboot
reboot

title Halt
halt

Repairing Damaged JPGs

I was using Windows 7.  I had run a test and had determined that I had a bunch of damaged JPG image files.  Apparently this could happen sometimes when files were saved on a CD or other drive with an iffy file table.  In my case, it did not help to try to open the files in question on a different computer.  It was also not a case of recovering data from a damaged memory card, for which a tool like ZAR digital image recovery might be needed.  This was a situation of already having the files on the hard drive, but not being able to view them.  So:  how to repair them?

One possibility was to buy PixRecovery for $50.  They had a demo version, so I downloaded and tried that.  I had used Bulk Rename Utility to rename the corrupted JPGs so that their names ended with " - corrupted" without a JPG extension so that I would be able to pull them out if any of them got mixed with good JPGs.  But unlike IrfanView, PixRecovery was not able to detect them until they did have a JPG extension, so I had to rename them back again.  PixRecovery did not appear to be able to process the JPGs in bulk; I would have to fix them one at a time.  On the first one I tried, I got "No data to recover detected."  They did give me an option to "order a paid file review" for $199 per file.  I tried another file.  The program didn't remember the output directory I had just specified for the first one, so I had to trace back through the directory structure to find it again.  This time, I got a message, "Recovered with demo restrictions."  It didn't show me the actual picture, though, even with a watermark or stamp on it; it just showed me a JPG saying, "The image has been repaired in demo mode by PixRecovery."  So I couldn't verify that the picture was fully restored; I would just have to take their word for it until I paid and tried it.  PixRecovery also gav me a Corrupted Data Analysis Report for the "restored" photo, with a statement of recoverability (i.e., Low, Average, or Good).  This seemed like something they could have provided on a batch basis for all files -- at least in the paid version, if not in the free -- so that the user would not have to go through the manual steps for each photo regardless of recoverability.

Among sites offering to provide a file examination for a fee, VG Jpeg-Repair offered an online service that would evaluate up to 100MB of JPGs for 1 Euro.  Alternately, it sounded like the user could pay them 20 Euros and get an evaluation of an entire set of JPGs, and then pay around $1 per JPG for the ones that they could repair.  I didn't investigate this too closely at this point; this just seemed to be the general idea.  I recalled seeing other pay-per-file sites, but didn't look into those either at this stage.  An eHow article pointed toward several other data recovery services, including Ontrack Data Recovery, Total Recall Data Recovery and ACE Data Group.  Previous exposure and brief examination of these sites suggested that they were more oriented toward recovering data from damaged drives, though no doubt they could recover photos too -- but that they could be very expensive. 

I found a review of Jpeg Repair Picture Doctor ($100) that made it sound like software to avoid, in the sense that it could trash good photos and pretend that it had restored bad ones.  On the other hand, it apparently had a batch process and a trial phase, so if there was a good backup, it seemed like a way of possibly reducing the number of corrupted JPGs to restore.  Another review said that the best JPG repair option was to use PhotoRescue.  It looked like it was for recovering lost data from drives, not for JPG repair.  They offered Wizard 3.1 for everyone ($29), Expert 2.1 for power users ($29), and Advanced 2.1 for ultimate experts ($99).  I tried the Expert 2.1 demo.  It was indeed oriented toward recovering drives.  I couldn't figure out how to use it for fixing JPGs.

Another program, JPEG Recovery Pro ($50), seemed to be offering a 15-day trial that would at least show me low-quality watermarked copies of the photos after recovery.  They also had a Basic version ($40), but it seemed to lack some features that would be useful when editing numerous JPGs.  I downloaded and tried their Pro version.  When I ran it, I got an error:  "Access violation at address 00846DC1 in module 'JPEGRec5.exe."  Possibly it was due to the fact that I installed without first shutting down all other programs.  I uninstalled and tried again.  That wasn't it.  I tried on a different folder.  It worked.  Apparently the file and folder name combination was too long.  I moved the folder to a higher-level location, so that the full pathname would be shorter, and tried again.  Nope.  I removed spaces from the folder name.  No.  I made the folder name shorter than 9 characters.  No.  I removed the files from that folder to another high-level folder with an eight-character name.  Still got the error.  I put a copy of one of the corrupted JPGs in a different folder.  The program ran on that folder, in the sense of detecting several JPGs there, but it did not detect this particular JPG.  So, hmm, this program was a possibility, but I'd have to tinker with it to make it work.

There may have been other possibilities.  I did not fully explore the results of my search.  But at this point it did start to seem that, if I wanted to download a program and do my own file recovery, it appeared that it would have to be a manual, one-by-one recovery process, whether using PixRecovery or some other program.  I ran across references to JPEGsnoop and other programs that likewise seemed to require the user to do bit-by-bit editing of the JPG file in ways that were sometimes described as difficult.  It appeared that JPEGsnoop might provide a relatively easy way to locate where the errors were.
I looked at the corrupted JPGs in IrfanView again.  For the ones I looked at, the error was the same:  "Can't read file header!  Unknown file format or file not found!"  I did a search and found people going through various struggles.  One suggestion was to try opening the corrupted JPGs in a different image editing program.  IrfanView was often recommended, but these had already failed there, so now I tried Gimp.  It allowed me to select and try opening all of the corrupted JPGs.  None opened, so Gimp did not seem superior to IrfanView in this task.  Gimp did, however, produce more detailed error messages.  It showed only the first several onscreen and then redirected the rest of them to stderr.  I wasn't sure where that was.  The several that did appear onscreen indicated that several files had similar problems:  "starts with 0x31 0xd9" or "starts with "0xaa 0xe9."  These seemed to mean I would have to edit the files manually to correct those starting errors.  Microsoft said that stderr meant the command prompt window.  It seemed I could capture the full log of errors by starting Gimp from the command line and redirecting that output to a text file.  Right-clicking > Properties on the Gimp icon that I clicked on to run the program told me where the Gimp .exe file was.  I opened a command window there and typed the needed command.  I was running the portable version of Gimp, so in my case the command was:

start "" "W:\Start Menu\Programs\Multimedia\Images\Editors\GIMPPortable\GimpPortable.exe" > D:\GimpLog.txt

So then, when Gimp started, I tried again to open all those JPGs.  When Gimp was done trying and failing, I opened D:\GimpLog.txt.  Unfortunately, there was nothing in it, so apparently I hadn't done that quite right.

I still didn't have a plan for what I would do if I did find out exactly what the errors were, so I paused the error output project to think about that.  I decided that these were old files, and there was really no urgency to this project.  There was always the possibility that, in the next year or however long it would be until I would get back to it, someone would come along with a cheap or free program or other great solution that would really take care of it, without all that manual editing.  Therefore, I shelved this project for the time being.

Testing to Verify That Photo Files Are Good

I had a bunch of JPGs in different folders.  I wanted to convert them to PDFs.  In the process of doing this, I found a way to verify that the JPGs were still of good quality.  This post describes that method.I wanted to move the files in this case, but it would also work to just make copies of them and run through these steps on the copies.

I began by opening a DOS box, also known as a command window.  I was using Windows 7, but substantially the same steps would work in other versions of Windows.  The easiest way to open a DOS box was to have a context menu (i.e., right-click) option to open a command window in Windows Explorer.  I had added that option using Ultimate Windows Tweaker (UWT).  The option in question was in the Additional Tweaks section of UWT.  This option added an "Open Command Window Here" context menu (i.e., right-click) option in Windows Explorer.  If I hadn't planned on using command windows frequently, I could also have just gone to Windows 7's Start button > Run > cmd.

First, I assembled a list of files to be copied or moved.  The command I typed for this purpose was this:

     DIR "D:\Source Place\*.jpg" /a-d /s /b > D:\Dirlist.txt

with quotation marks, spaces, and everything else exactly as shown.  (If a command is hard to read here, it can be made larger with Ctrl-+ (i.e., hold down the Ctrl key and hit the + key on the numeric keypad).  You can also copy and paste it into a word processor or Notepad to make it more legible.)  I would have needed to run this command again if I'd been searching for JPEGs as distinct from JPGs.  This command gave me a list of JPGs that existed on my hard drive in a folder on drive D called Source Place, or in any subdirectories under that folder.  The list was contained in a file called Dirlist.txt, located at the root of drive D.  To see what command-line options (e.g., /a-d) were available, I could type, in a DOS box, the command with a /? after it.  For example, I could get the parameters for using the DIR command by typing "DIR /?" (without quotation marks).

Once I had my list of the JPGs I wanted to test, I could move or copy them to another folder where I would be doing the testing.  I created a folder called D:\TestJPGs for this purpose.  To move the JPGs there, I opened the Dirlist.txt file in Microsoft Word, though any editor capable of recognizing the ends of lines of text would be able to do the job.  (Using Word did require me to do the final editing in Notepad:  I had Word set to insert smart quotation marks, and those would not run as commands, so the last step before running a batch command file created in Word was to copy it into Notepad and replace the Word-style quotation marks with plain-text Notepad-style quotation marks.)  Using global search and replace in Word, I changed each line in Dirlist.txt to the following form:

     MOVE "D:\Source Place\Subfolder A\photo.jpg" -y D:\TestJPGs

In other words, Dirlist.txt provided the list of files that could be converted into a list of commands.  Quotation marks were not necessary around that destination name (i.e., D:\TestJPGs) because there were no spaces in that file or path name.  Doing global changes to insert things at the beginning and ends of lines was easier with the knowledge that ^p was a common line-ending character in Word.  It seemed necessary to use the Dirlist.txt step because the MOVE command did not offer a /s option.  That is, I would have to explicitly identify JPG file locations and command them to be moved.  Note that somewhat different options were available for the COPY command as distinct from the MOVE command.

Once I had all the JPGs in a single place, I could run a test on them.  The test consisted of simply converting each JPG into a PDF file using the free Irfanview program.  (If all the files to be tested were already in one place, of course, the foregoing MOVE or COPY options would not be necessary.)  In Irfanview 4.28, the command to be used was File > Batch Conversion/Rename.  There, the necessary steps were to select the files to be tested, click Add, designate an Output Directory, and then go to the Batch Conversion Settings area and indicate PDF output format, though probably other formats would work too -- taking care to click Options and adjust quality levels if you planned to keep the converted output files.

Then I clicked on the Start Batch button, there in Irfanview.  When the conversion process was done, Irfanview gave me a list of messages regarding files that had converted successfully to PDF, along with some that had not.  I sorted this list in Word and saved the ones that were in this format:

     Error! Can't load: E:\JPGs\filename.jpg

I verified that neither Irfanview nor Windows Photo Viewer could view those files.  My next step was to search for a JPG repair utility.  This search led eventually to JPEGsnoop, which (after the assorted misleading websites I encountered along the way) was a refreshingly genuine freeware program of repute.  I downloaded and tried it.  JPEGsnoop (also apparently good on AVIs and other filetypes) turned out to be able to detect bad JPGs, thus simplifying much of what I was trying to do in this post.  It wasn't perfect, though:  it got hung up on a photo that Irfanview was able to open with no problem.  It also created a separate .txt file per JPG, containing file information for each JPG it examined, which I didn't need right now, so I had to manually delete those.  Another program of this type, ImageVerifier, whose webpage seemed to present a programmer who was doing a lot of thinking and experimenting about how to verify and preserve files with the use of a database scheme.  After installing it, they told me that it would only evaluate 50 files unless I bought the paid version.  So at this point, I wasn't sure these were better than the IrfanView approach (especially since I did ultimately want PDFs to replace the JPGs with).

Returning to the question of how to repair JPGs, I did encounter the occasional webpage on how to manually edit JPGs to fix them, but this was not something I was going to get into at this time.  I didn't find any freeware for this purpose.  I did find some shareware, but it didn't seem to be very highly rated, specifically All Media Fixer and DDR Digital Picture Recovery.  Possibly PixRecovery was a superior alternative -- at a price of $149.  At this point, I had to conclude that the world was still waiting for a good, free, automated JPG repair program.

Windows 7: Notes on the System Imaging Feature

I decided to make a drive image using Window 7's system image feature. I had made an image previously, but System Recovery couldn't find it when I needed it.  As I was starting the system imaging process, I saw this warning:

Backing up to dynamic disk gives you limited functionality while performing system image restore.

I wondered whether my previous image would have been visible, when I tried to restore from it, if I had copied my Win7 image to a partition that was not on a hard drive containing any RAID arrays -- more specifically, to what Disk Management (diskmgmt.msc) would show as a "basic" rather than a "dynamic" drive.  I had originally saved the image to a basic drive, but had then moved them to a partition on a dynamic drive.  If I had originally tried to save it to the dynamic drive , maybe I would have gotten this "limited functionality" notification at that point.

My mission at this point was to see whether Win7's system imaging could do what Acronis True Image Home 2011 apparently could not.  Could it restore a bootable Windows 7 partition to a new drive C located on a RAID0 array?

I went into Control Panel > Backup and Restore > Recover system settings or your computer > Advanced recovery methods > Use a system image.  It gave me the option to create a backup now.  I took that, just in case.  I tried saving to a partition on the dynamic drive, just to see what would happen.  It did give me a warning, "The selected volume is on a dynamic disk."  I clicked on its "More information" link.  That opened this dialog:

Set up backup

When restoring a system image from this volume, the disks on your computer cannot be formatted to match the layout of the disks in the backup.  To have full restore functionality, select a volume on basic disk as your backup location.

It wasn't clear whether that meant that the very process of creating a backup on a dynamic drive would have this effect, or if they were just saying that trying to *restore* from a dynamic drive would be difficult.  I decided to save to the partition on the dynamic drive nonetheless.  But as I proceeded, it appeared that I was only setting up an ordinary backup.  The option wasn't available to "Include a system image of drives: PROGRAMS (C:)."  The explanation, which didn't entirely persuade me, was, "Because you are trying to restore your computer to a previous state, you can only back up data files" -- not program files, that is.

I canceled out of that and clicked Restart to continue the system recovery -- bearing in mind, here, that I was hoping to restore to the RAID0 array, which had not yet entered service, whereas this backup program was sounding like it intended to restore to (and overwrite) my current drive C.  I was actually willing to let it do that -- the system had been through a rough night -- but upon rebooting, it said, "Windows cannot find a system image on this computer."  It defaulted to the "Select a system image" option," so I went with that.  Then Advanced.  But still, we weren't able to find those images that I now had on two separate partitions.

So now I wondered if the failure to find my previous system images was due to the fact that I had changed their names.  I thought it made sense to do so.  They were all called WindowsImageBackup.  I changed them to put the date in front, e.g., 2011-01-07 WindowsImageBackup.  Maybe this kind of rigidity was calculated to make the program easy to use.  I suddenly realized that, contrary to my assumption, perhaps later backups would not overwrite the previous WindowsImageBackup folder.  I looked inside the WindowsImageBackup folder, and it did appear that images might be saved in subfolders with different dates in there.

So, OK, back in the partition on the dynamic drive, I changed the name of one of those folders back to plain old WindowsImageBackup.  It was still in a subfolder, not in the root folder.  I went again to Control Panel > Recover system settings or your computer > Advanced recovery methods > Use a system image you created earlier to recover your computer.  I skipped the backup step, this time, and clicked Restart.  The "scanning for system image disks" process still said, "Windows cannot find a system image on this computer."  I canceled that automatic search and again tried "Select a system image" and then Next.  Still no joy.

That was the story for the search for the WindowsImageBackup folder on the dynamic drive.  Back in Win7, I tried renaming the copy of the WindowsImageBackup folder that I had copied to the basic drive.  I went through the same steps again.  "Scanning for system image disks" and this time, praise Jesus and pass the tequila, we had a discovery!  We had liftoff!  We had a window that said, "Select a system image backup."  So the answer to this little mystery was that (a) you were not supposed to change the name of the WindowsImageBackup folder and (b) it had to be on a basic (i.e., not dynamic) drive.  Since this worked, I did not try the alternative of going into the WindowsImageBackup folder, in Win7, and just double-clicking on various files to see if they would spontaneously fire up and run the system recovery software.

So now that we had a system image ready to be restored, the question was whether it would insist on being restored only to the basic drive, or whether I would have an option to restore it to the RAID0 array I had set up to be my boot drive.  Actually, it did not say where it was going to restore.  It said that it was going to restore drive C, but it did not say where it believed drive C was located.  But surely it would not wipe out data partitions, at least.  I went ahead with it.  After five minutes or so, it said, "Restore completed successfully," and it rebooted back into Win7.  It had restored the image to the existing drive C, the one I had booted from.  So there did not appear to be an option to choose a different target drive.

So I now had restored my original hard drive to its original condition as of about midnight the previous evening, before things started getting funky.  Along the way, I had learned a bit about how Win7's system recovery feature functioned.

The remaining unknown was whether I could just munge my various copies of the WindowsImageBackup together into one.  Keeping backup copies, I went into Windows Explorer and did a simple copy-and-replace operation to combine those WindowsImageBackups, into one properly named WindowsImageBackup folder.  I didn't try to figure out which versions of the same file to keep; I just copied and replaced, more or less at random.

I left this combined WindowsImageBackup on the dynamic drive for the moment.  Then I went into System Image and let it do its reboot thing.  Its scan for system image disks failed to detect the ones on the dynamic drive.  So it seemed to be pretty much confirmed that it didn't want to save to, or restore from, dynamic drives.

I moved the WindowsImageBackup folder, containing the munged combination of two different backups, to the basic drive, and tried System Recovery again.  This time, it found the folder, but it detected only the older of the two backups within it.  So it seemed my file munging process had probably replaced the newer versions of some of the indexing files in that folder with older versions.  Apparently the imaging program looked at those small files when deciding which images were available.  I didn't test whether overwriting older indexing files with newer ones might have shown only the newer images.  Tentatively, it seemed that the best solution, when there were two distinct WindowsImageBackup folders, was just to keep them separate and eventually delete one of them, rather than try to combine them.