Hi all,

Data is NOT important; I want to make this drive usable again and I'm doing this for learning. Linux, HDDSuperTool (GPL build) over a JMicron USB-SATA bridge (152d:0583) with external 12 V; WD VSCs pass through fine.

Drive: WDC WD5000AZRX-00A8LB0, FW 01.01A01, S/N WD-WCC1U1920791 (Trails, A8L). SMART attributes clean (Realloc 0, Pending 0, POH 2). Spins up normally.

Symptoms:
- ID and SMART read OK; every user LBA read/write is aborted (ABRT, status 51 err 04), including LBA 0, by DMA and PIO. 866 ABRT entries in the drive's error log.
- SMART short self-test: "Fatal or unknown error" at 90% remaining.
- Not ATA-password locked, PUIS not enabled.

SA work so far (read-only):
- Dumped 405 modules by ID with HDDSuperTool (wd_royl_dump_mod_all, continue-on-error). Valid ROYL checksums on 01, 02, 0C, 31, 33, 34, 35, 36, 38, 39, 3A and others.
- Only these failed at the "prepare to read" VSC step (sense key 0x0B ABORTED COMMAND): MOD 32, MOD 148, MOD 4002.
- MOD 01 directory entries:


My understanding (please correct me): with MOD 32 unreadable the translator can't load, hence all-LBA ABRT. The documented fix is a same-model, same-size MOD 32 template, cleared (keep bytes up to the first section offset at 0x30, zero the rest, recompute checksum) and written with the VSC sequence fzabkar posted in t=29187 (08 00 02 00 32 00 key, then D6 3C BF).

Questions:
1. Could someone share a MOD 32 (0x3C sectors) from a WD5000AZRX-00A8LB0 or WD10EZRX-00A8LB0, FW 01.01A01 (MOD version matching), ideally from a healthy drive?
2. Is a cleared same-model donor MOD 32 safe here, or should I first try reading MOD 32 by sector from copy 0/copy 1? I don't have WDMarvel; is the physical-read VSC documented anywhere for scripting?
3. Anything I should check before writing (e.g. MOD 148/4002 failing too)?

I can attach my MOD 01, 02, 31, 33, 34 dumps if useful. Thanks for any help.

Update - MOD 32 fixed, self-test now passes, but all LBAs still ABRT

Thanks to the archive here I found same-model donors and made progress:

1) MOD 32: wrote a clean MOD 32 from WD5000AZRX-00A8LB0 WCC1U4970086 (files.hddguru.com TrailXLS folder) using fzabkar's direct-write sequence from t=29187 (VSC enable, key 08 00 02 00 32 00 via SMART WRITE LOG BE, then 0x3C sectors via BF). The donor 32 was already clear: wd32clr2's algorithm changes 0 bytes. Its MOD 01 entry for 0x32 is identical to mine. After a power cycle MOD 32 reads back byte-identical.

2) SMART short self-test now "Completed without error" (it was "Fatal or unknown error" at 90% before). Reallocated / pending / offline-uncorrectable all 0.

3) BUT every host LBA read/write still aborts (sense key 0x0B; drive error log: ABRT, ER 04 ST 51, READ DMA EXT and PIO at LBA 0 and mid-disk).

4) Still unreadable by ID (ABORTED at the "prepare" VSC): MOD 148 (2 sectors) and MOD 4002 (1 sector). Donor WCC1U2319253 (TRAILS folder, ROM 00650018) has both at version 00650019 like my overlays, MOD 148 at the same SA address as mine, 301/413 MOD 01 entries equal to mine. But comparing three donors, 148 and 4002 contain per-drive values (4002 bytes 0x30-0x3F differ on every drive), so I have NOT written them.

5) Ruled out: ATA password (Security not locked/frozen); the USB bridge (ABRTs are in the drive's own SMART error log); ROM/overlay mismatch (ROM MOD 4F = 00650018, SA overlays = 00650019, the same pairing as the healthy donor; ROM module versions 0A/0B/0D/20B/30/47/4F all match the donor's); MOD 02 slow-fix flag (section 0x1B identical to the healthy donor, offset 2 = 01 on both).

6) MOD 02 vs the healthy donor differs in only 18 bytes: checksum, serial, config string/date, plus section 0x0C rel. 0x4C (mine 0F / donor 0A), section 0x19 rel. 0x0E (05 / 07), section 0x27 rel. 0x02 (AE / A2).

Questions:
a) With MOD 32 fixed and the self-test passing, is translator regeneration (format with P-list) the missing step? Is there any documented way to trigger it with VSCs, or is a paid tool (WDMarvel/Arch7, MRT, PC-3000) the only route?
b) What are MOD 148 and 4002 on ROYL/Trails, and could their being unreadable block LBA access? Is there a safe way to rebuild them for my drive rather than copying a donor's?
c) Do MOD 02 sections 0x0C / 0x19 / 0x27 matter here (fzabkar, your MOD 02 parser would know)?

I can attach my MOD 01, 02, 32 (current) and ROM dump if useful (148/4002 can't be read). Linux + HDDSuperTool over USB (JMicron 152d:0583), no native SATA available.

Update - MOD 32 fixed, self-test now passes, but all LBAs still ABRT

Thanks to the archive here I found same-model donors and made progress:

1) MOD 32: wrote a clean MOD 32 from WD5000AZRX-00A8LB0 WCC1U4970086 (files.hddguru.com TrailXLS folder) using fzabkar's direct-write sequence from t=29187 (VSC enable, key 08 00 02 00 32 00 via SMART WRITE LOG BE, then 0x3C sectors via BF). The donor 32 was already clear: wd32clr2's algorithm changes 0 bytes. Its MOD 01 entry for 0x32 is identical to mine. After a power cycle MOD 32 reads back byte-identical.

2) SMART short self-test now "Completed without error" (it was "Fatal or unknown error" at 90% before). Reallocated / pending / offline-uncorrectable all 0.

3) BUT every host LBA read/write still aborts (sense key 0x0B; drive error log: ABRT, ER 04 ST 51, READ DMA EXT and PIO at LBA 0 and mid-disk).

4) Still unreadable by ID (ABORTED at the "prepare" VSC): MOD 148 (2 sectors) and MOD 4002 (1 sector). Donor WCC1U2319253 (TRAILS folder, ROM 00650018) has both at version 00650019 like my overlays, MOD 148 at the same SA address as mine, 301/413 MOD 01 entries equal to mine. But comparing three donors, 148 and 4002 contain per-drive values (4002 bytes 0x30-0x3F differ on every drive), so I have NOT written them.

5) Ruled out: ATA password (Security not locked/frozen); the USB bridge (ABRTs are in the drive's own SMART error log); ROM/overlay mismatch (ROM MOD 4F = 00650018, SA overlays = 00650019, the same pairing as the healthy donor; ROM module versions 0A/0B/0D/20B/30/47/4F all match the donor's); MOD 02 slow-fix flag (section 0x1B identical to the healthy donor, offset 2 = 01 on both).

6) MOD 02 vs the healthy donor differs in only 18 bytes: checksum, serial, config string/date, plus section 0x0C rel. 0x4C (mine 0F / donor 0A), section 0x19 rel. 0x0E (05 / 07), section 0x27 rel. 0x02 (AE / A2).

Questions:
a) With MOD 32 fixed and the self-test passing, is translator regeneration (format with P-list) the missing step? Is there any documented way to trigger it with VSCs, or is a paid tool (WDMarvel/Arch7, MRT, PC-3000) the only route?
b) What are MOD 148 and 4002 on ROYL/Trails, and could their being unreadable block LBA access? Is there a safe way to rebuild them for my drive rather than copying a donor's?
c) Do MOD 02 sections 0x0C / 0x19 / 0x27 matter here (fzabkar, your MOD 02 parser would know)?

I can attach my MOD 01, 02, 32 (current) and ROM dump if useful (148/4002 can't be read). Linux + HDDSuperTool over USB (JMicron 152d:0583), no native SATA available.

What exactly happened to the hard drive, what were the problems with it, and who did what with it before? Because something was clearly done wrong, as an unreadable 0x32 module alone would not have brought the hard drive to this state. Upload all modules and everything you copied from the service area of ​​the hard drive.

It would be worth a try, the only question is whether anyone has done anything stupid with the hard drive before.
No, these Western Digital hard drives have a static translator. It's possible that with a damaged P or G list, the drive would refuse to access the data, although it seems like you can erase all the defect lists on these drives and, as long as the translator module itself is intact, the data will be accessible. With an empty translator, the surface will still be accessible, although the drive will find a ton of defects. I can't say for sure, but with a damaged 0x32 module, the drive should allow access to the data. It's just a relo list. It does not affect data addressing, but unreadable sectors are added to it for further processing. As a possible source of problems with module 0x32, I'd point to either a mismatched version in the header, which is unlikely, or a module that's correct from your perspective and the software's perspective, but invalid from the hard drive's perspective. There's also a VSC for cleaning this module, so you don't have to edit it manually; after cleaning with the command, some data appears in the module. By the way, there have been problems with this: if you try to load a supposedly "clean" module from another disk that meets all the parameters, then because of this data, the disk rejects it and the firmware crashes as soon as it finds a bad sector and tries to add it to the RELO list.

There is a free version of wdmarvel (2.3 beta), but it is quite old and requires a computer from its time (i.e., any 20-year-old piece of junk with Windows XP and a SATA port). But it does have the ability to recalculate the translator and run internal formatting. The VSC for internal formatting and recalculation of the translator were on the fzakbar forum (hddoracle) and I saw them somewhere else. I won't search and I won't be able to find it. The problem with all this is that all these functions are already implemented in paid and not so paid programs, and no one does it manually anymore.

There's a current demo version of WdMarvel that will let you read modules and create a restore point. It offers far more free features and is much more convenient than the opensuperclone script. You'll only need to use the script when you need to write modules.
These are most likely empty modules or some junk left over from the factory scan. It only takes a few modules to get the hard drive ready. So, these modules are 100% not the cause; on brand-new drives, fresh from the factory, it's not uncommon for several modules to be unreadable. You can try reading them sector by sector, or you can try reading a copy from a different head. But then again, take at least the demo version of WdMarvel; you're creating half the problems for yourself by struggling with manual input of the VSC and OpenSuperClone.
It doesn't affect anything. You can safely use module 0x02 from a hard drive with the same firmware version and, if desired, correct its identity to match the data on the sticker. Within the same firmware version, the module is identical. These few bytes that are different are the APM settings, the inactivity timer, and so on.

Thanks ora, that's really helpful.

To answer your question: this is a drive I salvaged from my old PC. Since I started working on it, the only write to the service area has been the donor MOD 32 described in my update above. Everything else was read-only.

Sorry about the duplicated update above; the forum no longer lets me edit or delete it.

Thanks ora. I've packaged the saved firmware evidence for WD5000AZRX-00A8LB0, serial WD-WCC1U1920791.

Archive: wd-WCC1U1920791-forum-evidence-20261012.zip (13.15 MiB)
SHA256: 3adf3d5185427f344314e4ef1c7061460905d232471c1c7cf0f3dd6d42e09d20

It contains 402 target module dumps, the saved Identify/SMART/self-test/dump logs, the MOD32 write/patch scripts used, and the same-model donor files in a separately labelled directory. All 402 target module files and the separate MOD01/MOD02 files match the original saved hashes. There is a README and a package hash manifest.

Important limitations: the saved folder has no target ROM dump, no target MOD32 readback, and no recovered target MOD148 or MOD4002. The included donor 32.rpm and mod32_cleared.bin are NOT target dumps; those two donor files are byte-identical. The saved self-test log is the earlier failed test, not the later pass reported in my update. The failed head-1 copy-read log is included; that attempt returned zero geometry, crashed HDDSuperTool and the drive disconnected, with no module data recovered. No further forced reads have been attempted.

While looking up the commands you mentioned, we found two public scripts in the HDDSuperClone repository:
https://github.com/thesourcerer8/hddsup ... translator
https://github.com/thesourcerer8/hddsup ... nore_plist

Neither has been run on my drive. The source doesn't establish tested compatibility with my Trails firmware (ROM 00650018 / SA overlays 00650019).

Could you confirm:
1. Is the ordinary wd_royl_regenerate_translator script an appropriate operation for this drive/firmware, and what backups or other prerequisites are needed first? I have not used the ignore_plist variant.
2. What is the exact drive-native MOD32/RELO-clear VSC or a reliable reference for it? The existing MOD32 patch manually zeros/uploads data and warns it may not clear everything; I understand that is different from having the firmware initialize it itself.
3. Is translator recalculation distinct from the internal format-with-P-list you recommend here, and can this be done through my JMicron 152d:0583 USB-SATA bridge, or is direct SATA required?

No additional service-area changes have been made since my previous update. I'd like to wait for your review before trying either operation.

Hi,
Module 148 is required for the drive to operate; you can take it from the donor drive.

Mikippp

Thank you, Mikippp!