Hello,

one of my hard drives malfunctioned, so I need some professional help.

My drives:
=======

drive C (master): Maxtor DiamondMax 10 (model: 6B120P0, codename: Sabre, file system: FAT32, OS: Win98SE)
drive D (slave): Maxtor DiamondMax 10 (model: 6B120P0, codename: Sabre, file system: FAT32)

What happened:
============

Some days ago I was playing "Imperium Galactica II". The computer was running for about an hour. Suddenly the computer hung (screen freezed + music fragment ran in a loop). Seconds later the computer rebooted itself, but something had happened to drive C:

• 100 GB of data vanished. The only folder left on the harddisk is the "Windows" folder, so I can start Win98 as usual.
• The harddisk responds very, very slow.

First diagnostics:
============

I did run some tests with HDDHealth and SeatoolsDOS. The results of HDDHealth are (left: drive C, right: drive D):



As you can see, "SMART" and "write cache" are disabled. SeatoolsDOS told me:

• SMART is supported an enabled
• SMART has not been tripped
• Short DST failed

My questions:
==========

Any idea what happened?
How can I enable "SMART" and "write cache" again? (Do I have to replace the PCB?)
How do I get the vanished data back?

P.S.: I'm from Germany and my English is not the best. So, sorry for any mistakes.

Firstly, your english is better than most here, even the native speakers

SMART and WriteCache are not enabled by swapping the PCB so forget that.

SMART is not related to your data loss. I guess you have suffered some file system corruption, possibly due to bad sectors on this drive. I suggest you run MHDD and see how the drive behaves.

If your data is important, you can either seek pro help or create an image of the drive and run some data recovery software on it.

_________________
Data Recovery Ireland

I agree with CK image this drive now. SeaTools is for Seagate drives and not for a Maxtor drive. It can be used on Maxtor Seagate drives to run diagnostics on it. You best bet is to image this drive to a new one and work from the drive image. Sounds like a virus, corruption of your data files due to bad sectors in the drive. You data should still be there if you image it and work this way to retrieve your data.

_________________
Iorana Haraharaini

Thanks for your answers, CK and poehere.


Okay, that's what MHDD says:


Seems that there is only a problem with one block (block 58710). Unfortunately this important block was marked as UNC (data is uncorrectable).

MHDD was also able to get some SMART data:



The MHDD manual says for #195, that I have to "Watch for astronomical number". Is 10276 an astronomical number?


I'll do that.


Official description:


Seagate bought Maxtor in 2006. I guess, that's why it can be used for Maxror drives, too.

I believe SeaTools can work with any drive because it relies primarily on standard ATA commands. There may be some specific Seagate vendor specific commands that earlier Maxtors don't understand, but that shouldn't affect SMART support.

Instead I'd suspect that a driver, or maybe the BIOS configuration, has disabled SMART support. SeaTools for DOS may enable it, but Win98SE may not.

BTW, I'm still using Win98SE and FAT32 file systems on a 120GB Seagate drive. I've also partitioned and formatted a 320GB Seagate drive in a USB enclosure, although this uses a different driver that is not limited by 28-bit LBA.

Have you tried Scandisk in readonly mode? I would uncheck the "Automatically fix errors" box.

I would turn on brain instead :

MHDD reported ERRORS =1 and in SMART there is 1 sector in OFFLINE SCAN UNC / REALLOCATE EVENT / CURRENT PENDING SECTORS.

The position of the defective block is unknown here , but if this block belongs to the filesystem, this is why part of the directories is "vanished" and everything is slow.

As SMART is triggered THIS way (looking at the other ATTS and knowing how reallocation works in SABRE )this explain all.

Most probably the block suffered from a CRC problem during a "botchered write" / due to improper shutdown when the system crashed (unknown reason, but that's it).
The other "slow" blocks are simple worn out or maybe "false positive" (500 ms and above are more to be worried about), unless they are adjacent to the "X" (and this can be perfectly normal).

The problem, as is, seems more logical than physical and easily fixable with proper gear and knowing what to do, though.

NO !!

At first, thanks again for all your answers.


Yeah, I was thinking the same. Unfortunately, I've no idea how to fix the "broken" block.


You're right. The two "< 150 ms"-blocks are adjacent to the defective block.


More details, please. Neither I know what to do nor I know the proper gear.


I have to get my hands on another 120 GB harddisk, which isn't easy. Also: What program can I use to mirror the data bit by bit to another drive?

You can use COPYR.DMA or dd_rescue to clone your drive.

copyr-dma-free-tool-for-making-sector-hdd-copies-udma-t5450.html

http://www.garloff.de/kurt/linux/ddrescue/

The OP could boot the Win98SE box to a DOS command prompt by holding down the F8 key.

How to get to a MS-DOS prompt / Windows command line:
http://www.computerhope.com/issues/chdos.htm

The UNC sector is physical sector # 58710. This corresponds to logical sector 0xE517 (= 58710 - 63) in the C: volume.

You can use Debug (in the Windows\Command directory) to view the sectors on either side, and back them up to a floppy diskette (or your other drive) as follows:

debug
-?
-L 100 2 E516 1
-D 100 2FF
-RCX
CX 0000
:200
-N A:\E516.bin
-W 100
-L 300 2 E518 1
-D 300 4FF
-N A:\E518.bin
-W 100
-Q

If I've calculated correctly, when you try to load sector E517, you should get an error.

Um... this program is in Russian. And I've no idea how to enable Cyrillic characters in DOS. So, is there an English version around?


Can MHDD handle bad blocks?

@fzabkar: I'm a bit puzzled. Why should I want to view the sectors on either side of the bad block and back them up to a floppy disk?

The bad sector appears to be around the 30MB point into the partition. This places it either near the end of the second copy of the FAT, or around the root directory. Even if the root directory were damaged, I would still have expected to see other entries in addition to the Windows folder. A Scandisk may have been informative in this regard.

By viewing the sectors on either side of the damaged one, you may be able to refine your data recovery approach, depending on what you find. I'm typing this on a Win98SE box, so I may be able to help you.

BTW, I suggested that you save the sectors to a floppy diskette to avoid writing to the problem drive. You could instead write the sectors to a second hard drive.

Hi ,
Do not bother About So Much Stuff ,USe a Disc Cloning Software to Clone the HDD To another HDD ,then use a logical data recovery software in the cloned drive and voila .Do get a new hdd BTW so that you could install win 98 in that and get your data back to that drive ,enjoy.

_________________
Regards
Amarbir S Dhillon , Chandigarh Data Recovery Labs [India]
Logical,Semi Physical And Physical Data Recovery
Website-> http://www.chandigarhdatarecovery.com

Thanks for your answers, Amarbir and fzabkar.


That's a good point. So I did some debugging:

That's how the drive (drive d) looks in the "Explorer" (all data "vanished", except the "Windows"-folder and some files in the main directory):


Now the results of the debugging:

Block before the damgaged block (e516):


Damgaged block (e517):


Block after the damgaged block (e518):


As you can see, the damaged block is totally messed up. This explains why so much data has "vanished". But it doesn't explain why the "write cache" is disabled. Or is this a side-effect caused by the damaged block?

However, the next step is to clone the data to a new harddisk. Therefore my question again: Is there an English version of Copyr.DMA available?


The "-W 100" is a copy and paste error, I guess. It should be "-W 300".

Sorry, I've been AWOL.

My first observation is that the data that you have associated with the damaged block at E517h probably reflects the contents of system RAM at that particular time. It is probably unrelated to the sector data.

The damaged sector would hold 16 directory entries. I suspect that these would amount to 8 actual objects, either files or subdirectories. One entry would represent the DOS 8.3 short filename, and there would probably be a second entry (or more) for the long filename.

The first of the missing objects appears to be a DELL directory. There are two deleted directories, Program Files and Design Workshop (?). These are denoted by the leading E5h character.

ISTM that the best approach would be to clone the drive using dd_rescue or ddrescue (I'm still not sure which is best).

http://www.gnu.org/software/ddrescue/ddrescue.html
http://www.garloff.de/kurt/linux/ddrescue/

If logical sector E517 isn't recovered during the cloning procedure, then I'd ensure that it contains all zeros. If Windows then sees the remaining good files and subdirectories, then OK. If not, then try replacing each entry in E517 with a deleted dummy file. That is, add an E5h byte to the beginning of every second line. Hopefully Windows will interpret these as 16 deleted objects, and then allow you to see the rest.

Once you have cloned your drive, you could have one last attempt at brute forcing the damaged sector. You could use Debug again ...

-L 100 2 E517 1

... and keep retrying (using the F3 function key) until you get a successful read.

Then you could write the data back to the damaged sector using ...

-W 100 2 E517 1

This should cause it to be recovered or remapped.

If this fails, then I'd zero out sector E517 on the clone and try for the remaining data with DR software.

BTW, sorry for my cut-and-paste error.

I should add that I only suggested Debug as opposed to a full fledged disc editor because I was under the impression that you didn't have a second drive.

With an additional drive, it would be easier to use HxD or DMDE:
http://mh-nexus.de/en/hxd/
http://softdm.com/download.html

BTW, logical drive D: is drive 3 in Debug.

Thanks for your long and detailed replies, fzabkar.


True. I did some more "read tests" with Debug and every time I got different results.


Well, I used dd_rescue and I was not amused. Although there was only one defect block, dd_rescue coundn't read the following 110 blocks either. (Debug was able to read them. And if I compare the first line of the 111th block - which is dd_rescue's first "good" block after the defect block - with the copied data from the debug.exe, it shows that the gap is only 104 blocks long and not 110 blocks.) Another problem is the wrong number of blocks of the copy:

source: 240,121,728 blocks
copy: 240,048,768 blocks

The copy has 72,960 blocks less than the source. That includes the first 69 blocks, which are missing.

So, I'm definitely not satisfied with dd_rescue.


Yeah. Once ...


I have eight hard drives in total (all old ones, from 2.1 to 120 gb). However, I like Debug. It's very oldschool and it works better than any other program I've tested so far.


I'll keep this in mind, thanks.

Well, I have to blame me. I didn't noticed that I have to use the -A command ("Always write blocks, zeroed if err"), if I want a 100% direct copy. *headdesk*

but the bad blocks will contain only zeroes...