SMR Zone/Bad T2 Header

[JGRivers]

Drive: WD50NDZW-11A8JS1, 5TB 2.5"
Family: Spyglass 2 Ultra

Symptoms: Spins up, does not come ready. Heads actuate, but remain in middle-diameter for ~10 seconds before parking, trying again, and going into Kernel Mode. No SATA connection error when attempted to upload LDR; often indicates hardware issue, but also consistent with 190 corruption.
Steps taken: Block SA. LDR uploads successfully. Upload DIR and 02 to RAM. Restart utility in Normal Mode. Saved ROM and Modules.

Abnormal behaviors: Drive does not detect its SMR zone data when restarting utility in Normal Mode (detects all 10 heads, default 500 SA SPT, clicking three dots button does not prompt value to change; I manually change it to 2140 when prompted). Drive has a good copy of module 190, but errors on 189. When I run T2 analyze with T2 command, the wrong parameters show up (window that prompts the default values; when I have it show the original values, the values are WAY off). However, when I either upload it by reading the file or read whole module, the header error does not show up.

I've noticed this coming up on several cases already: that the T2 header information is wrong when the drive uses its own command, but when it reads just the module, the information looks fine. Sometimes, using Translator Recreate or Shingle Read recreate can work, but I haven't yet mastered the use of those utility tools, as the results of using the recreated 190 is inconsistent: sometimes the 190 file created is good, other times, it's no better than the original.

Has anyone noticed any patterns, or found ways to deal with some of these T2 header problems?

Also, I have noticed a bad 189 can cause T2 issues. The module directory states module 189 can be recovered by the drive, but I have not found a way to trigger the drive to fix its own 189, or a utility prompt to rebuild 189.

[JGRivers]

Update: Drive had a bad As module on SA1 when I spared SA0 because it had more errors. I wrote the bad module from a good copy I saved earlier using Composite Read. Then, I created what seemed like a good 190 by deleting the old 190, using T2 reinit, then T2 recreate, then used shingle read and used the good 190 from the prior recreate as template for the saved shingle read copy. This seemed to work, but as the drive is imaging and we haven't processed the data yet, I'm not sure how robust this 190 is and how bad the data loss from the loss of the original 190 cache resulted in (I know, at worst, it's less than 100,000 sectors).

Would one of the mods or admins familiar with the T2 recreate utility be able to verify if the steps taken here were an adequate way of creating a T2 translator from nothing? I read the 3 support blog articles on repairing a bad 190, but I'm still not sure how to use the tool effectively, such as if any of the previous steps I took were unnecessary or redundant.

[File-Savers]

I've had lots of similar issues. Best way I have found when dealing with the inaccurate Translator Recreate is to run the tool using the backed up 190 and not reading directly from the surface, especially when the HDD has heads issues. Also saving the recreated 190 and writing it to the drive from the modules directory seems to be more stable than writing it via the recreate tool.