Are these drives likely fixable? (Error code: 8007045D@02070008)

Notice: Page may contain affiliate links for which we may earn a small commission through services like Amazon Affiliates or Skimlinks.

blunden

Active Member
Nov 29, 2019
488
153
43
I heard about some Samsung PM863a SSDs pulled from a storage array that after a secure erase can no longer be initialized in Windows because of the error below.

VDS fails to write boot code on a disk during clean operation.
Error code: 8007045D@02070008


Some googling suggests that this particular error can be caused by lots of different reasons, many of which people seem to fail to recover from while a few seemed to be recoverable. My first guess was that the drives might still be locked (since that's a part of the secure erase process) but I don't have a way to check unfortunately. Have any of you had luck with drives throwing that error? :)
 
Last edited:

blunden

Active Member
Nov 29, 2019
488
153
43

Terry Kennedy

Well-Known Member
Jun 25, 2015
1,142
594
113
New York City
www.glaver.org
Thanks for your reply. :) It's a SATA SSD though. Samsung have some confusingly similar names for some of their NVMe and SATA drives.
Might be formatted with something other than 512 byte sectors, particularly if it was in an array where the controller expects that to check for errors on drives. Look at boot messages from a Linux live CD to see what it reports for sector size. I think the Linux package is called sg3_tools or similar that allows a format with a new sector size.
 

blunden

Active Member
Nov 29, 2019
488
153
43
Might be formatted with something other than 512 byte sectors, particularly if it was in an array where the controller expects that to check for errors on drives. Look at boot messages from a Linux live CD to see what it reports for sector size. I think the Linux package is called sg3_tools or similar that allows a format with a new sector size.
I see. Thanks. Finding out the sector size from dmesg sounds like a great idea. So sg3_format works on SATA drives as well, not just SAS drives?
 

blunden

Active Member
Nov 29, 2019
488
153
43
I plugged it in and hdparm reports that the drive is locked, as I suspected. However, the security level was set to Maximum which prevents me from just overwriting the existing unknown master password with a new one.

Code:
Security:
    Master password revision code = 65534
        supported
        enabled
        locked
    not    frozen
    not    expired: security count
        supported: enhanced erase
    Security level maximum
    32min for SECURITY ERASE UNIT. 32min for ENHANCED SECURITY ERASE UNIT.
The master password revision code supposedly suggests that it still has the default master password set which for some Samsung SSDs seems to be null or an empty string but that doesn't seem to work. As far as I understand, security level maximum means that I will only be allowed to use the master password for a Secure Erase (which I would be fine with) but when trying to do so I end up with the following error:

Code:
ubuntu@ubuntu:~$ sudo hdparm --user-master m --security-erase "" /dev/sdg
security_password: ""

/dev/sdg:
 Issuing SECURITY_ERASE command, password="", user=master
SG_IO: bad/missing sense data, sb[]:  70 00 05 00 00 00 00 0a 04 51 40 00 21 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Has anyone seen this error before? Googling it points to an issue with using USB enclosures but I'm connecting it directly to the SATA controller on my ASUS ROG Strix X370-F Gaming motherboard.

EDIT: I mounted it in a USB enclosure I had and connected that to my laptop. I was then able to run the commands and get the regular I/O error that is expected when the password is wrong. Still no luck though.
 
Last edited:

blunden

Active Member
Nov 29, 2019
488
153
43
Did you find the solution for that kind of drives from a storage array?
Yes, I eventually did. :D More than 3 years after buying it I finally unlocked it last weekend by using a very thin wire to short the enable pin on the chip responsible for the SSD's power loss protection while the drive was on. This made the drive immediately drop out and restart in the ERRORMOD state where the previous security settings are ignored, allowing you to run a secure erase to wipe out the old data and password.

Note that it also resets some of the SMART values so dump those before you proceed if you want to keep that data for future reference.

I got lots of help from people over at the HDD Guru forums in my thread linked below.


Another method using the drive's Safe Mode to trigger the same ERRORMOD state is available in that thread as well, but it didn't work for me.