Simple.
Disconnect the optical drive cable, with the two optical drives on it.
All optical drives should disappear, all *three* of them in Device Manager.
There is a problem there, but I cannot figure out exactly what. And I
think the detection of three devices, where two exist, is *the* problem.
The OS is "pinging" the hardware status of the phantom optical drive,
and that's chewing up cycles.
While you might be running some virtual CDROM software, and mounting
an ISO as an optical drive, somehow I doubt that. You'd probably remember
doing that.
Once the optical drive cable, with two optical drives is removed, you
can try removing or deleting the phantom item in Device Manager.
*******
That would leave the two Maxtor hard drives on the other IDE cable.
The thing that was D: and changed to J:, and you changed it back
to D: again, is "raw". That means you've lost the file system
on it. It could be, there is some damage near the beginning
of the file system. The header of the file system likely no
longer says it is NTFS.
Since it is a logical inside an extended, now you're going to
need to figure out where it starts. Probably two sectors
past where the Extended is located.
With a Linux LiveCD and hexdump, you would normally see
something like this. In this example, you work out a potential
sector offset (do the math to locate where D: starts), and then
when you display the data, the word "NTFS" should show up. That's
how you know you've located it. You can use PTEDIT32 in Windows,
to dump the MBR and get the offset. PTEDIT32 should show the
Extended, and the D: might be a couple sectors past that.
(You can run this first, and capture MBR information... I sometimes
prefer this to using "sudo fdisk /dev/sda" type commands in Linux.)
ftp://ftp.symantec.com/public/english_us_canada/tools/pq/utilities/PTEDIT32.zip
(Then boot into Linux, and actually track down the beginning of D: .
This is what I use as a disk editor, of sorts. This is the command
I used, to locate a partition on a 3TB hard drive.)
sudo hexdump -C -s 0x20000140000 -n 512 /dev/sdc
20000140000 eb 52 90 4e 54 46 53 20 20 20 20 00 02 08 00 00 |.R.NTFS .....|
20000140010 00 00 00 00 00 f8 00 00 3f 00 ff 00 00 08 00 00 |........?.......|
The program "TestDisk" could scan and locate these things,
but it'll likely run into the same problem, of not seeing
a file system on the old D:. And CHKDSK is not going to
want to run on D:, because at the moment it is raw, and
CHKDSK won't know it needs to run CHKNTFS. There is a way
to tell CHKDSK to run when no drive letter is evident, but
that still doesn't solve the problem of CHKDSK figuring out
which version of tool to run (FAT or NTFS).
(Tool used to repair an MBR. In this case, you may be able
to view files once the tool has scanned the disk. It may
be able to see the file system, but no guarantees. There is
no point repairing the MBR, because it's not the thing that
is broken. So the only reason to run this first tool, is
to see if the files can be listed on the partition or not.)
http://www.cgsecurity.org/wiki/TestDisk_Step_By_Step
(This is an example of a file scavenger, for cases where
perhaps the MFT (master file table) is gone. Scavenging
if there was no backup...)
http://www.cgsecurity.org/wiki/PhotoRec
I don't know how to "hand repair" a file system. I'd be probing
the head of the file system, just to see if the sectors
are readable there or not. It could be, the system will
freeze when you hit the bad spot in the disk.
*******
You can run a tool like this, to try to recover the data on D:
You'll need some more disk space, to put the recovered files.
This is a free tool someone wrote, and when I offered this to
one user, they got their files back. I haven't tested it here.
This tool, the source code, was eventually sold to some other
developer, and the originating web site removed. But archive.org
still has a copy.
http://web.archive.org/web/20070101070056/http://www.woundedmoon.org/win32/driverescue19d.html
driverescue19d.zip 1,007,764 bytes
MD5SUM = 63b7e1e8b1701593d5f52c7927d01558
*******
So now it's a data recover effort on the former D:. Or,
restoring D: from backups and blowing away the file system
on D: using the restoration.
Most of what I've suggested above, is for idle curiosity.
The "driverescue" stands the best odds of getting anything
you don't have backed up from the old D:. But, you'll need
to connect an external USB hard drive, as a place to
put the data, as you've run out of spots on the IDE cables.
The TestDisk and Photorec, are likely poor substitutes
for "driverescue", since driverescue will be attempting
to use an MFT if one can be located. Photorec can't handle
fragmentation for example, and as far as I know, fragmented
files will show up as damaged files if recovered that way.
I have tested Photorec, by copying a file, then erasing
it, and the unfragmented test file was successfully recovered
by scanning for it.
There are any number of $39.95 commercial programs for
data recovery that you could try. Some, they offer
a trial version, that will display the file names as
proof of recoverability. Then you pay the $39.95, and with
the license key in hand, you can complete the recovery
operation.
Paul