Jon said:
Just for fun I deleted ntldr and rebooted. I didn't get the "NTLDR
Missing or Corrupt" message, so whatever is happening isn't getting that
far in the process.
Jon
Interesting.
I was going to suggest this, but I guess not. As you'd
proved it's not going to help.
http://support.microsoft.com/kb/305595
The idea is, you use the Windows installer CD, go to i386 and
get a copy of NTLDR and NTDETECT.com and copy those to a floppy.
Then, I went to the existing C: drive and copied boot.ini from
C: to the floppy, a total of 3 files. Note - before you object,
the usage of a floppy, is part of an imaging trick - this floppy
will *not* be offered to the broken computer.
Then, I used this.
http://www.chrysocome.net/dd
(
http://www.chrysocome.net/downloads/dd-0.6beta3.zip )
Then, make an image of the floppy. This is a sector by
sector image. It copies every sector on the floppy.
DD has some bugs in its "end-of-device" check, but in
this case, it knows where the end of the floppy is.
dd if=\\?\Device\Floppy0 of=bootxp.dd bs=512
The resulting file should be 1,474,560 bytes (2880 sectors).
So now I have an image of a FAT12 floppy, with three files on
it, stored in a 1,474,560 byte file.
Next, I transfer that to my 1GB Kingston USB flash.
dd if=bootxp.dd of=\\?\Device\Harddisk2\Partition0 bs=32768 count=45
which will transfer the floppy image to a USB stick. The larger the
block size parameter the better, as long as it's a power_of_two. So 32768
is as close as I can get to the larger USB flash stick storage size.
Note, the files that were already on the USB stick, I didn't lose them,
because I backed them up.
dd if=\\?\Device\Harddisk2\Partition0 of=savethefiles.dd bs=262144 count=3838
The dimensions of devices can be determine by using this command,
as described on the program author's web site.
dd --list
and knowing that "Partition0" represents the whole device as a block device.
That's where I get the information that my USB stick is 1,006,108,672 bytes.
And know that 262144 * 3838, copies the entire USB stick.
I can reverse the dd transfer, and put the image of what was on there, back.
*******
OK, I did two boot tests. I booted the floppy with NTLDR, NTDETECT.com
and boot.ini, and it presented the OS boot choice menu (WinXP boot manager).
So that worked. That means the floppy bootstrapped me into WinXP, and
the WinXP boot manager took over. The boot.ini ARC path was important
to that process selecting the correct disk. I have two disks, and WinXP
is on only one of the disks. The floppy targeted the correct disk.
Next, I used the popup boot and selected the USB flash stick. And the same
thing happened, it booted to the WinXP boot manager, and WinXP booted. So the
Microsoft recipe works
The reason the image transfer using "dd" is needed, is to get around the
USB flash stick formatting issue. The format on the floppy is likely
something like FAT12 or FAT16. You can't expect to take a huge USB flash
stick, and convince Windows to format it FAT12. By imaging a floppy diskette,
file system and all, and transplanting it onto the USB key, that is part of
what makes this work. The floppy is used as an intermediate "cheating" step.
The other part, is certain "emulation" modes the BIOS has. It treats USB
devices according to size in some cases. Some BIOS even know when a USB ZIP
drive is connected to the computer, and do something different internally
for those. So there's no guarantee that my experience would have worked
for you. Some older BIOS, just don't have good working USB boot options.
*******
Is the file system on that disk, mountable from Linux ? That would
tell you the file system header is at least partially OK. Linux
may not check everything in there for consistency. I would have
thought CHKDSK run from some Windows environment (recovery console),
should also have been looking at that. Windows probably wouldn't have
mounted the partition, if it didn't recognize it. So right away,
that suggests the file system header (bytes at the very beginning
of the partition) are OK.
In Linux, you can do
sudo disktype /dev/sda
to get a rundown of what Linux thinks is on the disk in terms of
file systems. I expect GParted would display the information
as well. I like disktype because it's a small (optional) tool
which is handy when something is broken.
http://disktype.sourceforge.net/
With enough fiddling, you can even get Package Manager and
a network connection on a LiveCD, to give you a copy of the
binary of that. Few distros come with that as standard. You
have to go into the Package Manager, turn on all the Repositories,
reload, then search for disktype, all to get the tiny executable.
I don't really know where to go next. You did a fixboot (update
the boot sector in the C: partition, in the file system header
area) as well as fixmbr (fix the 440 bytes in the MBR sector 0).
You shouldn't really need to do a fixboot, unless the partition
had been formatted and the file system header overwritten by
a formatter. I know this, because I copy the files off my
WinXP occasionally, format C:, and copy the files back. And
the OS won't boot, unless that is followed by a fixboot. Otherwise,
you probably wouldn't (normally) need it.
So that's yet another option for you (if you're bored). Copy
all the files off C:. Reformat C:. Copy all the files back.
Do a fixboot. Make sure NTLDR, NTDETECT.com and boot.ini
are present. And try booting. That's a lot of work, and
when I do that process, I dual boot Win2K and do the file
copying step from there. So it's not something you do with
only one OS present. While you can do things like run an
NTBACKUP plugin from BartPE and other exotic things, that's
really reserved for when you have a running system and
need a hobby
Paul
