Why on earth doesn't it flush the filesystem buffers and unmount the volume prior to hibernation?

If I recall correctly, the Windows approach to hibernation is to hibernate the USB device tree along with the PCI device tree and the IDE and SATA device trees... It assumes it'll be able to pick up the "conversation" with the device midsentence on dehibernate. I rather suspect the design pre-dates easily removable portable storage media...

That would explain the problem I discovered many years ago with the FAT driver. Under Win2k at least, it appears to save the FAT table across hibernation. So if you while the computer is off unplug a FAT-formatted USB drive, change the contents on a different PC, and then plug it back into the first PC, when you restore the first PC from hibernation it'll corrupt your USB drive. It doesn't crash though, but then again it's probably a lot less complicated than the NTFS driver (which can crash when mounting a sufficiently broken filesystem).

I've got a better idea as to what happened with the second crash. When Windows bluescreens, it apparently writes the memory dump to the page file (the theory being that doing so needs very little of the kernel to be working). Presumably on the second restore attempt it tried to page in something and hit the part that contained the dump, bluescreening and overwriting the existing memory dump.

As far as I know, (although Thomas is welcome to point out if I'm wrong) he is still running XP... an OS only 2 major versions out of date and over a decade old... That said, XP did have a fairy decent understanding of removable storage, but their hibernation tech was a little fuzzy.

For reference if you do what he did in Vista or 7 the machine is just fine.

Nope, still on XP. An upgrade to 7 will most likely happen when I buy some new shinyness that doesn't work with XP, though it'll mean replacing some of the more exotic hardware I've got (I know the film scanner won't work with 7).