This was extremely painful to do, given that 1) the drive has a very limited amount of time before I/O stops working, and 2) hddsupertool has some badly-designed path parsing issues (I can discuss those with the author), but I was successful. This was done via the USB interface as well.

I also saw output on the screen (didn't save it) for both modules stating the checksums were good.

Do you want the files attached here or hexdumps of them or what?

I am currently communicating with the author of HDDSuperTool. He has managed to retrieve module 01 which I have now parsed for him. I have also presented him with a possible script for retrieving the ROM contents. Hopefully he can now retrieve a complete set of resources.

_________________
A backup a day keeps DR away.

Module 32 is clear. I believe the OP was going to try the mod02 patch.

_________________
A backup a day keeps DR away.

I haven't tried the mod02/mod32 "slow fix" patches (per hddsupertool) yet. I need to review the hddsupertool scripts to see what they do, and may have to modify them for the drive/situation. I'll explain what I mean:

Due to how the Linux framebuffer (console) behaves on my test box -- more specifically, output is very slow -- use of printbuffer or printscratchpad or lots of echo statements end up causing the program to take too long, by which time the drive has gone catatonic. I solved this in my own scripts by avoiding printbuffer/printscratchpad. (I could also try switching to a classic 80x25 text console, which would probably work fine).

A quick review of those patch scripts does show they use printscratchpad on a large buffer, particularly the mod02 patch script. I'd need to comment out those lines. But I also need to review the scripts to see what exactly they're doing ATA CDB-wise.

Current status update -- fzabkar and I have been conferring a lot privately, so the following has been done successfully via USB:

* Dumped modules 02 and 32 using hddsupertool scripts
* Dumped module 01 using a modified version of the module 02 script (very easy)
* Dumped the 256KB Marvell ROM (U12) using a hddsupertool script I wrote (fzabkar is going to see about giving that to the hddsupertool author and incorporating it into hddsupertool). The ROM was verified by fzabkar as 100% OK
* Made a short MP4 video showing how I'm able to dump about 350-400MBytes of data from the drive (using dd) during that very small window before it goes catatonic. The data obtained looks correct (MBR/PMBR/GPT, NTFS bootloader and MFT, and some real-world user data), but it's not enough. There's apparently a good amount of data on this drive (much more than 350-400MB) which my colleague needs

The ROM dump script I wrote saves me having to deal with desoldering/soldering U12 on, say, a SATA donor board -- instead I can just give the ROM file to a PCB vendor who can flash it and then ship me the board.

If I get a SATA PCB and it works, I still don't know what I'm going to do about decrypting the JMS538S data. I know no one with MRT Pro or PC-3000. And the MyBook bridge board solution is not very well documented (there are many board types all using JMS538S, with many different firmware versions). I can't move U14 for the same reason I can't move U12 (SMD/SMT desoldering is very difficult/dangerous for me).

There is a strong possibility that a bad/faulty head is what's causing this problem. The WD20NMVW-11W68S0 uses 4 platters, and fzabkar confirmed through review of module 0A that the drive does have 8 heads (logical/physical). If a faulty head turns out to be true, I obviously can't fix it and will send the drive back to my colleague + refer him to a data recovery company + call it quits.

ddrescue still isn't an option because I'd have to power-cycle the drive nearly 5700 times to get data in chunks of 350-400MB. It just isn't feasible right now given the circumstance.

Question about SATA PCB replacements --

The original USB PCB is a 2060-771801-002 REV A.

The compatible SATA PCB, per this guide, is labelled "771823" and nothing more.

There are sites that do BIOS flashing/swaps that sell several revisions/versions of 2060-771823-000:

* http://www.hdd-parts.com/wd-caviar-se.html -- search this page for 2060-771823 and you'll get 18 results that vary widely

* http://www.onepcbsolution.com/western-d ... -blue.html -- search this page for 2060-771823 and you'll get 10 results (some are REV A, others are REV P1)

How truly different are these when it comes to using one as a SATA donor PCB?

Does the drive support error recovery control? This can be determined by the output of the identify device command. HDDSuperTool will list it as a value of 0 or 1. If it is supported then setting the error control read timer would be worth a try. If it is not supported then it is no help.

_________________
http://www.hddsuperclone.com
Home of HDDSuperClone

Does mod02 have the value of 0x02 at offset 2? Mod 32 can be cleared but still have the slow issue until mod02 is patched, at least from the small test I was able to perform on a drive.

_________________
http://www.hddsuperclone.com
Home of HDDSuperClone

The drive does not support SCT ERC. smartmontools' smartctl -x flag will show whether the drive has SCT ERC capability or not (it's near the bottom of the output). I've provided both -a and -x output in an attachment in my initial post.

I've attached a .zip that contains modules 01, 02, and 32 for review by others. If there's anything else you guys want to peek at module-wise, just give me a list and I can hack up some scripts to snag all the ones you'd find of interest.

I still have not tried the mod02 "slow fix" patch yet. I need to read the script to see exactly what it does + comment out the printbuffer/printscratchpad lines (see earlier post of mine for why -- it's a situation specific to my setup/this drive).

And most importantly of all: again, everyone, thank you SO MUCH for helping. I love the fact that as a group we're all working towards narrowing down what the issue is, simply to try and determine if it truly is a head/mechanical problem or not. Honestly if you all had PayPal addresses I'd be donating money to each and every one of you. This is a perfect example of how more than one set of skilled brains when combined can do amazing things. Honestly I'm surprised nobody has considered hiring all of us to make some kind of data recovery company, haha. I hope I've "earned my wings" with the hddsupertool scripts I've written and all that. To the naysayers, let this be a lesson: never judge a book by its cover.

I read everything you wrote in full and actually understand it completely. I say this a lot, but THANK YOU. This makes perfect sense.

I had no idea about the WDR tool. I can certainly build a small system running XP using a reliable Intel ICH9 chip for southbridge/SATA -- that's a walk in the park. I have lots of spare parts/servers/PCs here. (I ran XP on my desktop until just last year, switching to 7). I'll give WDR a try when I get there. Thanks!

Just a general FYI: the next 6-7 days are gonna be busy for me due to my job, errands, life responsibilities, plus health issues.

So if I don't respond in the thread (or PMs) promptly, don't worry -- I haven't disappeared.

I hope everyone is having a good holiday season and has a great New Year.

P.S. -- For Spildit: I purchased a lifetime licence for WDMarvel, by the way, so that tool is now something I have in my arsenal. Seems it would work best on a dedicated XP system -- I tried it on my 7 workstation and Windows became quite irate about the unsigned drivers it was trying to install (which failed). XP's a lot more lenient and I really can't risk screwing up my main workstation (I do a LOT of things on it unrelated to data recovery, so you can understand).

Quick update which I think will surprise/amaze most:

I've found a way to keep the drive from going into a catatonic state. I've had it up/working with I/O now for almost 5 minutes and it's still quite happy.

I'm working on figuring out exactly what causes the drive to go catatonic, but given what my workaround does, I would say a specific region/area of the drive (LBA/sector-wise) is causing the drive to lock up (despite SMART not showing anything). Meaning there is something physical on the platter (gut feeling) that causes the drive to lock up hard. I'm thinking the drive firmware is trying to access something within that physical area shortly after the drive starts up and thus locks up.

All said, I believe it may be possible for me to use ddrescue in combination with this workaround to get back a large sum of data off this drive.

I'm very very excited to say the least. I'll post progress as I have it.

Well, I have a way to keep the drive "alive" for longer periods of time, but it does appear that reading certain LBA ranges cause the drive to go into a catatonic state. From my review of my data, I'm thinking these regions are calculable.

I believe this supports fzabkar's theory that there may be a specific head that's misbehaving or wonky. The drive has 4 platters with 8 logical/physical heads.

The bright side is that with my workaround, the successful I/O period is substantially longer, allowing me to try the mod02/mod32 patch without too much worry. I'll give that a shot. I'm hoping that might make the overall drive behaviour on failures/retries/etc. "better" for something like ddrescue.

Oh my... it's working after the mod02/mod32 patch! The drive didn't go into a catatonic state, and I/O appears stable so far:


/dev/sdb = origin drive (now patched)

/dev/sdc = destination drive (same capacity, slightly more LBAs, same sector size)

I'll let this run and see what the result is in the morning.

Glad to hear the slow fix worked. When a drive has the "slow" issue it is doing something during the idle time (between commands). It is searching for bad sectors, or a place to relocate bad sectors, or something like that. It locks up when it encounters a problem sector, and in your case even seems to go into device fault and require a power cycle (don't worry, you will find that area of the drive later in the recovery:). That makes my patch a bit difficult to implement, as I wrote it to read and write one sector at a time, allowing the drive to "hunt" in between commands. This makes is slow, but the reason I did that was because I found a USB adapter that would only work with the VSC commands one sector at a time. There is actually a way to do the mod02 patch with very little code, but I never tried that method.

Now I see you are using ddrescue 1.17. I would recommend using 1.19 or newer. Actually I would recommend using version 1.21-pre1 along with my passthrough patch. My patch can be found here:
https://sourceforge.net/projects/ddruti ... d_testing/
Also, a helpful understanding of ddresce here:
http://www.hddoracle.com/viewtopic.php?f=172&t=1173
Normally I recommend using the scsi passthough with usb devices, but since you have been able to use hddsupertool to work with it, you should be safe to use the ata passthrough. Either way the patch will allow a special exit code when it detects a device fault. Since you program, if you could write a program that would run a relay to power cycle it, and then a script to call ddrescue, check for exit status and call the relay program, you would be all set. Then again, if you are very lucky, there will only be a small bad spot on the drive and none of that will be necessary.

_________________
http://www.hddsuperclone.com
Home of HDDSuperClone

Module 02 consists of several sections which other HDD manufacturers refer to as Configuration Pages (CP). The mod02 patch involves switching off a particular CP. This can be done either by editing module 02, or by means of a special VSC that directly writes to a specified CP.

The following open-source Linux tool uses the direct approach. It was based on some work at WD's forum.

http://mod2patch.sourceforge.net/
http://mod32patch.sourceforge.net/

_________________
A backup a day keeps DR away.

Results are in: 100% success, no errors. SMART attributes for source drive also show no signs of read errors or pending sectors needing re-analysis:





In other words: mod02/mod32 patch somehow fixed this -- or alternately, rewriting mod02/mod32 on the drive somehow fixed it.

I'm absolutely ecstatic, and my colleague is as well. Now to check on everything NTFS-wise and do repair there, but that's all stuff I've done before so no help needed.

Yeah I know about not using the drive that caused all the grief to begin with.

The destination/donor drive I used is also in 100% working condition (I always verify them with full range LBA read/write patterns before I do any restoration onto them).

I'll be showing my colleague how to zero the My Passport drive and then he'll be taking it to a E-waste facility for recycling; It's outside of warranty anyway.

Thanks everyone! You'll be seeing a new post from me with regards to another drive (yes, from the same colleague) that has a completely different issue (pretty sure it just needs a PCB + U12/U14 swap).

We can consider this matter closed and a success. "Like watching a bad movie with an ending you can predict" -- I guess that means he predicted success even though the film wasn't worth watching.

How sweet it is! Chalk up another win to MacGyver. )))

Maximus, your HDD Tool really is Super! Kudos to you!

To the naysayers, Happy New Year.

(As for e-waste, the PCB could still be recycled on eBay.)

_________________
A backup a day keeps DR away.

100% recovery is awsome!

Now I would like to analyze this a bit. I agree that mod32 was clear, and that my mod32 patch should not have changed anything. But mod02 record 27 offset 2 did have the value of 02. My mod02 patch would have changed that one byte to 0, which seems to be the big key to the slow fix. So the big question is why did this drive have that problem with no apparent bad sectors? It would appear that the drive was looking for sectors that were not available to a normal read. So if the slow fix is related to relocating sectors, is it possible that the drive was checking the place where it would normally reallocate to and found an issue? There must be bad sectors someplace on the drive that would cause the issue. Or maybe some other issue that we don't understand. What exactly causes the WD slow issue?

Anyway glad to hear of 100% recovery, and glad HDDSuperTool was helpful.

_________________
http://www.hddsuperclone.com
Home of HDDSuperClone

"Don't believe everything you read on the Internet as true"

_________________
Buy your friends Toshiba\Hitachi and your enemies Seagate.