OK, this is my problem:
I have a SATA Hard drive with rather important data in it (No Pron, mind you day job stuff) It is not the system drive but it is so copletely f'ed up, that when I try to read or copy certain files in it, freezes my computer. is even able to freeze CHKDSK low level disk checking app.

Fed up with having to do a hard reboot every time I attempted to extract my data, I took the HD out and put it in an external case, that connects to the computer via FireWire or USB. Now the damn thing cannot freeze my computer but if I try to copy files out it "disappears" from the windows system.

If I disconnect and reconnnect the case, windows re-detects the drive, I can see the folders and even open some files, but any attempt to copy/rescue files by copying whole folders out of it is rewarded with a failure/dissapearance act.

Questions:
Any Idea what may have happended to the drive? The hardware appears to be working fine, but there is something really wrong with the I/O

Any suggestion for utilities to try to diagnose/ extract my data out of it? We are talking about 60 GBytes, so copy file by file, which sometimes works some times not, is not an option. . .

Thanks in advance

IF it is formatted with NTFS and the hd is good (not physical defects) use linux to access it... not joking at all...

In case it works, please do not chkdsk/f it, but save your data and keep hd intact. I already faced an ntfs bug but -for the hd involved- I couldn't study it. The pc had to boot...
If it is this way, it is a very, very interesting case, as it can freeze *every* windows, even specially crafted boot cd.

Perhaps this isn't entirely helpful, but I'd be tempted to 'move' the files out, rather than copying them. At least this way you'll keep track of your progress and you'll have a better chance of determining if the lockups are random or if they are associated with certain parts of the file table/disk's surface.

Regards
Admiral

move will change the hard-disk right?

I'd say moving the files would be very dangerous, considering the presence of unknown hardware problems! I'd avoid writing to any part of the disk at all cost!

It might be your windows problem.Try a clean install on a new hardisk.

Agreed. What I'd do in this case is attempt to create an exact image of the failing drive onto another one, with a sector-by-sector tool like Ghost.

Is the drive accessible from DOS? (NTFSDOS driver if NTFS filesystem)

it has allready been mentioned,

in case of disk troubles, when nothing helps anymore ....
i plug it to a linux box.

and pleeease - its 100 times more secure to access NTFS r/o than r/w.
and for data recorvery especially - - i think, and common sense could tell, moving files is far more dangerous than reading them (copy).

i have no better idea than to use linux, you can try a live CD for that.
there are also specialised live CDs for that purpose, I use often an old
"mandrake move 1.0" CD - just because its laying around here.

i am not sure which of them can handle sata drives. i had major troubles
installing "linux" on my laptop 1 year ago, now sata is supported by most
kernels & installers so should not be the problem, especially when its not
your intended boot drive

for a very screwed disk, when you have no filestructure at all anymore, you
for example can use the dd command to dump (parts of) the disk, and restore
semi automated .... uh
else there are chkdsks for ntfs.

[edit] hm, is it possible the hd controller (on the HD) could have a problem?
when a low level chkdsk fails i am a bit afraid other chkdsks would do the same.
though using linux+tools you have far better diagnosis possibilities than just
"error xyz - chkdsk failed"

PM me or post for tips,

regards, 0xf001

The Russians have some very fine HDD tools, e.g. MHDD, Victoria, etc.

http://hddguru.com

First of all, I want to thank everybody, for taking the time and giving me leads to attack my problem. The Knowledge assets of this board go far beyond RCE.

I have kinda fix some of it:

Mistery 1: How a secondary, non-Boot, non-System SATA drive was able to freeze windows. . . It also froze Linux for that matter, as long as it was connected to the SATA bus. Linux tools were not very helpful in handling a drive connceted via USB. I have not completely figured out that yet, but when I connect the drive to the SATA bus, the BIOS indeed detects all the drives connected at the hardware level but gets confused about who has the master boot record. Does not find it where it belongs in drive C, IDE 0 partition 0. . .

My gut feeling is that either a failed linux install or a Rootkit tried to make the faulty drive the SystemDrive, but I had disabled the possibility of SATA being the MBR at the BIOS level, so when the faulty MBR tries to hijack the system it fails, but confuses the BIOS.
This is a mute issue when the drive is connected via USB or firewire, because my system cannot boot from these external devices.

I vaguely remember that the problem started when I updated the BIOS, so it may have trapped the problem

Problem 2:

Reading my precious data from the disk:

At very low level the sectors that contain my data are for the most part intact, but some have an unusually long Seek time. I found that out using one of the tools that LLXX pointed me to. When I try to read those sectors with high level "copy commands" the sytem hangs waiting for the next sector to read, then freezes.
by sheer chance I found that if I copy files while I am scanning the disk at low level using HDD scan v2.6, somehow the dive is forced to read "the next sector" in the file chain, breaking the impasse and allowing me to read most of my data automatically.
Only the "delayed seek" sectors lag behind, but I can now read them individually using low level tools and then do some plastic surgery on my incomplete files.

Now I have to figure out if the disk fuck up was a problem with maware or an innocent malfunction.

Thanks again

heya,

quite strange indeed.



then i think common sense could point that the hw, firmware, sthg on the disk itself is screwed, i am afraid.



hehe, i dont know what you tried
usb disks are shown as scsi devices and can be handled like any other disk
the mbr thematic should totally not matter imho

when 2 OSs show similar defects of the disk, how abt plugging it to a totally different machine via usb? when it shows the same i think its somehow safe
to assume the drive itself has a bit a problem. in case of data recovery ...
well i can only point to linux tools again.
in particular chkdsk, tunefs, debugfs, dd, ... there are a lot more depending on what you need.
ok i admit, all those tools require a bit of learning, and are not very fancy, but they help get the job done

regards, 0xf001

Howdy,

I had this problem about a year ago. I was trying to recover data from a drive that was acting screwy. I did not know it had a MBRV/root kit.
When I plugged that drive into my system it infected my hard drive.

It started up innocently enough but it froze. Reboot.
same thing only this time it froze after about 3 minutes. Reboot.

After doing this about 6 times I got no boot and the box was post coding.

I was able to restore my own hard drive but I lost all the data.
I got it back using Linux.
The other drive went to the trash.

Now when I get a drive that is fucked up, I plug it into my "junk" box
running linux and have at it.

Stop messing with that drive and get a junk box. Try to recover it that way.

Woodmann