Real Headscratcher--Changes made to SSD revert on reboot

chockomonkey

[H]F Junkie
Joined
Oct 11, 2003
Messages
8,328
I've never come across this problem, and apparently neither has anyone on the internet either.. so here I am posting as a last resort. I have exhausted all of my ideas.

In the interest of being thorough--yesterday a client informed me that his workstation was extra slow. I checked it out, and indeed applications were locking up in bizarre ways, but I couldn't exactly figure out why. I ended up whitelisting some of his applications in his antivirus.

Today I come into work and notice some critical errors in the remote administrator console pertaining to this workstation. I pull the syslogs and notice that there are a lot of errors referencing a bad block on device 0, the OS ssd.

Running chkdsk on the drive in read-only mode completes and finds errors to fix. Attempting to fix the errors with the /f flag causes chkdsk to abort at 10% consistently without any indication as to why.

CrystalDiskInfo doesn't report anything wrong with the disk. Thinking that odd, i figured i'd get the manufacturer's ssd utility.. and this is where things got really weird. I downloaded the Kingston SSD Toolkit, installed it, but it would not run. It simply wouldn't do a thing. I saw a note in the install that it may require a reboot post installation. So i figure, why not?

I reboot. When i go to launch the toolkit, it's simply not there on the drive. Fuckin weird. I go to download it again, but notice there's another utility, the Kingston SSD Manager, so i give that one a go. I install it and launch it. The program works but its views are entirely unpopulated. In the logs, it says it cannot access device 0, the SSD in question. In my preliminary research of why this program can't display the information, i read something that the SATA mode must be in AHCI for this kinda thing to work, so I reboot again to check it out, and sure enough it's set to IDE mode. Long story short, i tried to make the regedit change to enable the msahci driver, but that change isn't saved on the SSD after rebooting. The second kingston application is also gone also, as if I never even installed it.

I imagine that this drive is dying, but.. in this way?? I have never seen nor heard of a drive going into some pseudo-read-only mode as it takes its last breaths.

Anyone got any clues?

tldr:
- notice bad sector error messages in eventvwr for the SSD
- chkdsk gracefully aborts at 10% consistantly
- seemingly any changes made to this SSD are lost on reboot
- WTF!??!
 
Try disabling fast/quick boot in BIOS. I assume there's something going on where power is being cut to the SSD before it can fully flush its write buffer.

Additionally, if possible, update the drive's firmware.
 
might it be that it is eol and has reverted to a read only state so you can back up and replace the drive?
 
Try disabling fast/quick boot in BIOS. I assume there's something going on where power is being cut to the SSD before it can fully flush its write buffer.

Additionally, if possible, update the drive's firmware.
I disabled quick boot, didn't seem to make an affect.
Have you tried a different SATA cable or port?
I just tried both of these. Didn't seem to make any difference in drive functionality.
So it seems I'll have to go this route. I just pulled the drive and threw it in a reference machine on my workbench. Hopefully i can get some kingston utilities to work on the drive here and see if it's EOL or perhaps flash its firmware.

Thanks for all the ideas and help thus far.
 
So I threw the drive into another computer, and attempted the same diagnostics. It still fails to be recognized by both the kingston ssd toolbox and the kingston ssd manager. CrystalDiskInfo shows the same info:

Capture.PNG
chkdsk still fails at the 10%, but now I can see the eventvwr log entry, which states "The data written out is different from what is being read back at offset 0x1006bfb000 for 0x1000 bytes."

Anything written to the drive is still lost upon reboot, so I've taken an image of it and will try to restore it on another drive.

It's still really odd to me that, if it IS EOL due to runtime hours or hitting some "max allowed writes," why wouldn't they have engineered it so that it'd just tell me that in one of their programs?

Silly kingston!
 
Was this drive ever encrypted and if so with which software? Also, have you tried updating the firmware on the drive? I know most if not all recommend a wipe of data before writing firmware but I wonder if it would even take the firmware write at all.
 
So I threw the drive into another computer, and attempted the same diagnostics. It still fails to be recognized by both the kingston ssd toolbox and the kingston ssd manager. CrystalDiskInfo shows the same info:

View attachment 55137
chkdsk still fails at the 10%, but now I can see the eventvwr log entry, which states "The data written out is different from what is being read back at offset 0x1006bfb000 for 0x1000 bytes."

Anything written to the drive is still lost upon reboot, so I've taken an image of it and will try to restore it on another drive.

It's still really odd to me that, if it IS EOL due to runtime hours or hitting some "max allowed writes," why wouldn't they have engineered it so that it'd just tell me that in one of their programs?

Silly kingston!

it may not be able to anymore, while it may be annoying, if you can recover the data, that may be more usefull then the drive flatout dying and having everything lost which is what usually happens. Not even sure that what I saidf is the issue, it's just something I picked up of what certain SSD's should do when they reach a certain stage to avoid data loss.
 
Was this drive ever encrypted and if so with which software? Also, have you tried updating the firmware on the drive? I know most if not all recommend a wipe of data before writing firmware but I wonder if it would even take the firmware write at all.

I don't believe it was ever encrypted. i would have definitely tried to update the firmware had either of the kingston utilities even recognized the drive.

it may not be able to anymore, while it may be annoying, if you can recover the data, that may be more usefull then the drive flatout dying and having everything lost which is what usually happens. Not even sure that what I saidf is the issue, it's just something I picked up of what certain SSD's should do when they reach a certain stage to avoid data loss.

I can definitely recover data from the drive, but i never keep data on OS drives anyway. It's just windows and programs, everything profile related is on our servers anyway, so it's not a big loss for me even if it went up in flames. This was more... enlightening than anything. I think you were right on the money. Talks with other sysadmin friends of mine were also surprised but more or less corroborated your claim in their own research on the topic. For instance, https://superuser.com/questions/345997/what-happens-when-an-ssd-wears-out

I've since scrapped the drive and got a new one in house.

Funny to note---i used diskpart to delete the partitions, then made a new one, then formatted it and assigned a letter. Diskpart didn't think anything was wrong, but the two old partitions with all their old data is what showed up when the volumes were assigned drive letters lol

Thanks again to everyone who helped me figure this one out!
 
Back
Top