I have a Western Digital 500GB Raid Edition drive that started causing problems in Windows XP. It actually gave such terrible fits to the OS that it caused about 3 or 4 BSODs (blue screens). When I traced the problem out, it was obvious that it had a missing disk, but I didn't figure this out until some automatic backups began to overwrite any proper backup of the drive letter in question.

The way XP was setup is like this:
I had 2 almost identical 500 GB drives installed in this machine, Disk A and Disk B, and I used it as a sort of network file server for some things. Most of the data is backed up in a variety of ways, but apparently not everything on D:
C: drive, 30 GB, in RAID 1 mirror (Disk A & B)
D: drive, 540 GB in a RAID 0 stripe, meaning about 270 GB per physical disk. (A+B)
E: drive, 200 GB on Disk A.
F Drive, 200 GB on Disk B.

Disk B failed, along with the D: drive of course. I would like to fix this drive and bring it (or a proxy for it) back into Windows XP to complete the recovery from Windows of the logical RAID 0. Incidentally, the mirror on C: works fine, so the PC is running fine except that I put a lot of miscellaneous programs onto the D: drive.

Looking at the Windows logs, it appears it failed while an automatic backup had just begun.

When I remove the drive from the Windows PC and I try it on a completely different PC with low-level DOS utilities and even Linux, there is generally these problems:

• POST time is sometimes very long, but the BIOS eventually detects the drive, its model name, and its correct size.
• Booting is slow.
• Windows boots extremely slow. When it runs, it usually will detect the drive, but none of its data. If I go to Disk Management, I am asked if I want to partition it.
• Nothing can read the partition table... Gpedit, mhdd, hdat2, Windows, fdisk, etc. They all give errors or say the MBR is empty.
• None of the utilities I use has ever seen any bits of user data. MHDD scans, for example, just reports errors for every sector.
• Pretty much everything can read the SMART data and the various drive properties and parameters.
• HDAT2 has tons of info! down to the date it was manufactured (matches the date printed on the drive) and various tidbits about its capabilities.
  

I have a donor drive that was made the same day in case I can rob parts or service data from it. Would anyone like to walk me through a potential recovery please? Just a background on me... I am a PC technician, mostly of the amateur variety, but I do paid contract work, too. I have worked on computers for over 20 years. I have successfully repaired/recovered two hard drives by doing a PCB swap. It has been a few years, but I have a feeling this may be more involved. The other ones had been hit in a lightning storm, whereas this one failed for an unknown cause while it was in use.

Your diagnosis and help is appreciated.

The "safe sex" way for data recovery with RAIDS is to diagnose what is actually going on with each drive; repair them as possible, and make a bit copy clone of each and every drive. The recovery is done on the clones, not the original drives, because if you mess up the originals, there are no second chances.

I might be willing help you for some frozen flying fish and a bottle or two of yellow Bajan hot sauce and Cockspur Rum . . .

_________________
http://www.datasaversllc.com

I have never heard of any of those, so I am guessing that they are inseparably linked to clean rooms, server rooms, and datacenters full of spinning hard drives? Where I'm from (let's not get into that), I prefer blackened red snapper (which would imply that it is cooked), Tabasco, and Myer's Rum, although not necessarily in that order, and not necessarily all at the same time.

There are some basic stuff you can start to do your own, like checking what's the issue of each drive.
Connect them to another computer and check if they work fine or if you can detect some problem with it.

If you don't know what those things are, then I sincerely doubt you are from Barbados.

_________________
http://www.datasaversllc.com

Oh, I see now. Barbados is more of a mantra than a precise location. I meant it more as an inside (my head) joke, I am sorry. I didn't mean to throw you, but some of those signup forms get pretty involved with some oddball questions. I didn't realize my location would show up next to every post. If it is relevant, I am in flyover country, as they say in American politics, CST.

Back to the hard drive: I only have one bad physical drive, Disk B. Disk A (another Western Digital 500GB) is fine, and boots normally without B present since its mirrored C: drive is perfectly intact. The shared drive D: is striped such that both Disk A and B must be present for the RAID 0 to work at all. Windows merely lists drive D: as having failed due to the fact that there is a missing hard drive in the stripe. I intend to get Disk B working (or an exact duplicate) and then put it back into Windows. When this happens, Windows will likely show Drive D: immediately on boot. The mirror on C: will rebuild itself without me doing anything, and it should take only about 20 minutes I hope.

I have had a drive fail on this computer a couple of times (this may be the third time), so I have a handle on how this RAID is built. Just to be clear, this is a DYNAMIC disk configured in Windows, as there is no separate RAID controller. So when I do any recovery of the bad disk, I will hopefully see the three partitions: (1)The intact mirrored C: partition should be a normal NTFS 30GB partition... and (2) there will be the RAID 0 partition that follows it, and none of the data on it will make any sense to a utility program... and (3) there will be a normal NTFS partition at the end of the drive.

Your scenario is confusing, and I see that "ShellGameBot" is a very apt alias for your array.

From what I can tell, your challenge is to do a recovery on the single bad drive, and to make a bit clone of it rather than do file recovery on its contents. In other words, make the image as functional and with as much data fidelity or integrity as possible.

Like I said, it's a good idea to copy even the good drives before you try to reassemble everything. Expect the unexpected.

_________________
http://www.datasaversllc.com

So I will want a drive image of the good drive, too? Sorry for my mixed up partitioning scheme... my original intent was for the RAID 0 drive D: to be primarily for temporary scratch and 2nd backups, etc. I think it eventually got some more important data as the years went by. Yeah, it was a fun experiment that eventually ran too long. I believe I could use Copywipe or something similar. If my memory serves me, that is the program I have preferred in the past, but my memory is not serving me right now.

Also, what can I run to see what is wrong on the bad drive? Is there a MHDD script that will read the ROM? I was thinking about using a spare 500GB drive as a donor for the bad drive, but I have been reading that it is necessary to copy the ROM files off the bad drive and see if any of the service area is good. Couldn't I compare the MHDD output from each drive and see if there is a corrupted firmware file that is keeping the drive from reading the data sectors? The EID and ID commands both work. I was able to view SMART logs. I was able to disable SMART. (I was hoping that disabling SMART might keep the drive from any more write attempts.)

Regarding your first question, re-read my first post.

Regarding the 2nd, find someone with the proper diagnostic gear and experience. You cannot do it reliably without either.

_________________
http://www.datasaversllc.com

I do agree with Jon.

WD uses Vendor Specific Commands (VSC) for low level diagnostic access to the hard drive's ROM and firmware area. To read the serial flash memory ("ROM") on your PCB, you could use the MHDD script entitled "WD Marvell Royl serial flash 192 read" at the following URL:

http://yura.projektas.lt/files/wd/mhdd/index.html

Note that MHDD version 4.5 supports scripting whereas version 4.6 does not.

Before you run the script, you will need to create a 512-byte VSC key file named rom192.bin containing the following data:
http://yura.projektas.lt/files/wd/mhdd/romread192.jpg

To do this, you could use a freeware hex editor such as HxD:
http://mh-nexus.de/en/hxd

Alternatively, you could use the DOS Debug command, as follows.


After executing the script, you would need to examine the 3 resulting files (3rom0/1/2.bin) to confirm that they look right, and then pack them into a single file. This file would then need to be written to your donor's flash memory.

You could concatenate the three 64KB file segments, in a DOS window, as follows:

copy /b 3rom0.bin + 3rom1.bin + 3rom2.bin rom.bin

If the above is too much for you, then a clickable alternative is WDR-UDMA or WD HD Pro, but it isn't freeware (~US$80 - $150).

BTW, "ROYL" refers to the architecture of your drive. If you examine the firmware modules, you will see a "ROYL" header.

You could compare your results against other ROYL examples here:
http://www.datadonor.net/index.php?fold ... wgU2VyaWVz

_________________
A backup a day keeps DR away.

This is a more challenging task. I would first use MHDD to read MOD 01. This module contains a directory of all the MODs in the Service Area (SA). We could then construct a more comprehensive script to read all the remaining MODs.

The following Salvation Data article contains some useful information on MOD structures:
http://www.salvationdata.com/blog/fix-i ... m-content/

Here is what MOD 01 looks like in a hex editor:
http://www.salvationdata.com/blog/wp-co ... ntifi5.png

Notice the header "ROYL", the MOD ID (0x0001, little endian), and the size in sectors (0x000C).

The remainder of the BIN consists of a table of MODs that lists each MOD ID together with its size in sectors.

For example, here is the entry for MOD 35:

1202 3500 0100 0318 2000 0000 0000 0000 0000

The data are in little endian format. The MOD size is 0x0001 sectors, 512 bytes.

Each MOD entry occupies 18 bytes (0x12) and appears to begin with 0x1202 (or 0x0212 if endianness is taken into account).

The last entry begins with 0xnn02, where nn is some number that I don't understand.

The total number of MODs is stored at offset 0x30. This is 0x0134, ie 308.

To read MOD 01, we could use the following script:



Here is the VSC key sector (you need to pad it with zeros):



The above script will retrieve the first sector from MOD 01. When we have this, we can determine its actual size, and then rerun the script with the correct sector count.

_________________
A backup a day keeps DR away.

That was a long road. It looks like I got the ROM code. It was three files.

I booted to MS-DOS 7.1 (Win 98se) that I installed on an old hard drive (takes me back) and put the script file in C:\mhdd\scripts and kept the 512-byte VSC key file in C:\mhdd. I then ran mhdd. I tried a "eid" to make sure the drive was alive, followed by ".royl-192" which was the name I gave this script.

IT worked!! So I exited to DOS and copied them all to a combined file that was 192 KB in size. It took awhile, and I had some difficulties here and there. I noticed that the first time I did it, I had been running other mhdd commands which had given random errors. But to make a long story short, my first attempt had some large sections full of "00." I guessed (correctly) that this wasn't correct for the ROM image. But I re-ran the script a day or so later and found that the ROM image had changed and it had data where the "00" sections used to be.

Here was the key for me: I ran the same mhdd script on a known GOOD drive, and found that its ROM did not have that blank section. Reading the files and comparing them in HxD (on a WIndows computer) was priceless. All of this was aggravated by switching from DOS to Windows and copying the files back and forth. I have a solution, but that's for another time.

So I have what appears to be a GOOD copy of my ROM from both drives. There appears to be some differences in the two ROMs even though they appear similar (with periodic ROYL signatures). The difference starts at offset F8A7 of the third file (3ROM2.BIN), while the first two files were identical. I will work on the MOD 01 later.

Could you upload your two ROM images?

I believe the first part of the ROM is the boot firmware (SA MOD 109). The differences at the end are the data for the Service Area translator, Service Area adaptives, head map, ROM module directory, and firmware version. At least that's what I deduce from the MHDD script.

The Salvation Data article suggests that equivalent modules in the SA and ROM have different IDs.

SA module 105, ROM 30 - Service Area translator
SA module 103, ROM 47 - Service Area adaptives
SA module 102, ROM 0A - head map
SA module 107, ROM 0b - ROM module directory
SA module 104, ROM 0d - firmware version

For example MOD 103 in the SA is equivalent to MOD 47 in the ROM. These "adaptive" data are unique to each drive.

_________________
A backup a day keeps DR away.

Ok, this is a test to upload a file. This will be the BAD hard drive's ROM, 192 KB.

I think the upload worked. Here is the GOOD drive's ROM image.

Here was my first attempt at getting MOD 1. Are you saying that it is incomplete when you only get one sector of this? In any case, if I understand this process, MOD 1 is found somewhere on the platters of the disk, so this means that, if nothing else, there is at least some Service Area data that is physically present on the disk since your script worked. Now I noticed that there are maybe two different copies of these MODs on the platters, and that if we were to do it by the book, we would read both copies and see if they are the same?

Anyway, here is the MOD 1 file, zipped. It is 512 BYTES. (not KB)

Nice work!

AFAICS, the first 0x120 bytes of the ROM contain some kind of table, with each entry occupying 32 bytes.


Each entry appears to point to a block of code or data.

For example, the first entry suggests that there is a block at 0x0120 of length 0x0AE0 bytes.

The next entry points to a block at 0x0C01 of length 0x68C8.

Block #1: 0x0120 + 0x0AE0 = 0x0C00
Block #2: 0x0C01 + 0x68C8 = 0x74C9
Block #3: 0x74CA + 0x44C8 = 0xB992
Block #4: 0xB993 + 0x0784 = 0xC117
Block #5: 0xC118 + 0x01D4 = 0xC2EC
Block #6: 0xC2ED + 0x048C = 0xC779
Block #7: 0xC77A + 0x159C = 0xDD16
Block #8: 0xDD17 + 0x010EB4 = 0x01EBCB
Block #9: 0x01EBCC + 0x60D8 = 0x024CA4

The last block ends at 0x024CA4, after which the ROM is filled with 0xFF bytes until offset 0x02C000. The block from 0x02C000 to 0x02C8CB appears to contain data rather than code.

Offsets 0x02C8CC through 0x02F89A once again contain 0xFF bytes. The point at which you noticed the difference (0x02F8A7) is the first CRC byte of ROM module 0x0D. You can see the firmware version (12.01C01).

Each ROM module begins with a "ROYL" header. If we use this as our guide, then the ROM MODs are as follows:

MOD 0x0D, location 0x2F89B - 0x2F8E0, length 0x01 sectors, 0x46 bytes
MOD 0x47, location 0x2F8E1 - 0x2FAE0, length 0x01 sectors, 0x200 bytes
MOD 0x30, location 0x2FAE1 - 0x2FEE0, length 0x02 sectors, 0x400 bytes
MOD 0x0B, location 0x2FEE1 - 0x2FFB1, length 0x01 sectors, 0xD1 bytes
MOD 0x0A, location 0x2FFB2 - 0x2FFEF, length 0x01 sectors, 0x3E bytes

If we now examine the contents of ROM MOD 0B (directory of ROM MOds), then the structure becomes clear.


We can recognise the MOD ID, size in bytes, and starting offset.

I suspect that the leading 0x12 is the size of each table entry (18 bytes).

I would also hazard a guess that the 0x01 bytes indicate that these are ROM MODs, whereas a value of 0x02 would denote SA MODs.

The sixth MOD entry appears empty. Coincidentally (?) I notice that MOD 4F referred to in the Salvation Data article is not present.

_________________
A backup a day keeps DR away.

I don't know how to select each individual copy of a particular MOD, but the reason we read only the first sector was to determine the MOD's size. In this case the size is 0x000C sectors.

524F 594C 0100 3000 0100 0C00 258E A200

To read the entire MOD 01, we just need to modify the count register in our MHDD script.

_________________
A backup a day keeps DR away.

Ok, I edited the script to
to read what amounts to 6KB, or 12 sectors. Since $01 represents 1 sector 512 bytes, $0C represents 12 sectors 6 KB, I am guessing that for a large read that we can read at most 255 sectors if the second register is $FF. Although I wonder what $00 would do?

Anyway, here is my complete MOD1 attached.