Well, you have nothing to lose now.
Welcome to Testdisk.
Testdisk is a tool that "recomputes" the MBR. All it does, is work out
the primary partition table entries. It scans the disk, on track boundaries,
looking for partition headers. A 2TB disk, is going to take a long time....
Of course, everything on a 2TB disk takes a long time.
http://www.cgsecurity.org/wiki/TestDisk_Step_By_Step
You, the user, have to judge the answer it comes up with.
First, write down the "current" partition table info.
Connect the borked drive, to a working PC, and use PTEDIT32 to read out
the MBR. On Windows 7, you must Run As Administrator or otherwise PTEDIT32
gets an "error 5". If you don't edit anything in here, it's not
going to change anything.
ftp://ftp.symantec.com/public/english_us_canada/tools/pq/utilities/PTEDIT32.zip (free download)
Your disk, before using TestDisk, will look like this in PTEDIT32.
This is a three partition disk (three primary partitions). The
display shouldn't be red, as the red color is if you attempt to
edit the partition table (don't do that just yet). In this example,
the boot flag is set on the second partition. Only the Windows boot
loader cares about the boot flag - things like Linux GRUB don't
refer to it.
http://www.goodells.net/dellrestore/files/dell-tbl.gif
When you run TestDisk, it's going to attempt to identify the
partitions on the disk. Compare the "new" computed value,
against the PTEDIT32 information.
Perhaps that will tell you, whether the "structure" is damaged.
If Testdisk shows the same info as PTEDIT32, then there's something
else wrong with the content of C:.
If you erase a partition, then run Testdisk, it'll find the erased
partition. This is why you have to be *real* careful with it,
and not accept verbatim, what it finds. If you know the disk has
three partitions, don't accept a "four partition answer". Successful
usage of TestDisk, requires user prior knowledge. TestDisk isn't
very good at guessing.
For WinXP to boot, you'd need the boot flag set on the appropriate
partition. The boot.ini has an ARC (disk path specification), and
that specification has to be consistent with the partition number
that the partition is currently on. If you use a "partition editor"
for cloning, sometimes it can switch entries (move partition 2 to
partition 3 table entry), and then you'll get an appropriate error
at boot time.
Yours isn't doing that, so I doubt that's the problem.
But if you want to check for "MBR damage", you can slave
the borked drive to a working PC, run testdisk and check the
2TB drive, compare against what PTEDIT32 says.
And if it looks like that will take too long, you can just
admire the info PTEDIT32 is showing you. That will only
take you a couple minutes to verify.
If PTEDIT32 is upset with what it finds, I suppose even that
is an answer. It would imply the MBR got "blasted". Maybe there
isn't even an MBR there any more. Testdisk can work out a new
one, but worst case, you'd need to do a FixMBR from recovery
console if the 440 byte MBR boot code was also ruined.
(On a data only disk, the 440 byte area is a don't care.)
MBR = 440 byte boot code (different for each bootable OS)
4*16 bytes primary partition table (includes boot flags)
disk signature byte etc.
Total = 512 bytes
I'm not aware of any tool, that checks or verifies the 440 byte
boot code, or can tell you what's currently loaded. These OSes
have weaknesses in certain areas, when it comes to forensics.
Some things are harder to work on, than others.
*******
Nothing in your symptoms so far, points in the direction of
the MBR. The above is presented to satisfy your curiosity.
HTH,
Paul
