[SOLVED] Is all hope lost?

Sep 1, 2019
22
0
20
2
At the advice of a mod here, I attempted to replace a non-functional Intel RST app. Doing so somehow resulted in almost all of the data being wiped from my Raid 1 drives. Windows says it can't boot to the device. I've hooked it up to another PC, and the contents of my drive is now:
  • A couple folders that I had stored in the root of C:\
  • A windows.old folder that has none of my data (that is, C:\windows.old\users\<myname> is empty)
AFAIK these SSDs had Trim enabled. A quick search makes it seem hopeless to recover data from these drives.

Is this true? Any suggestions?
 
Sep 1, 2019
22
0
20
2
I'm assuming that both drives are formatted as NTFS.

If cached data are not properly flushed to an NTFS volume, or if the system powers off during a file operation, then the NTFS "dirty bit" is set. On the subsequent boot Windows sees the dirty bit, realises that there are potential inconsistencies in the file system, and then executes CHKDSK in order to repair them.

That's one possible explanation, AISI. You can sometimes confirm that this is happening by examining the Unexpected Shutdowns attribute in the drive's SMART report.

Locating the NTFS "dirty bit":
http://www.hddoracle.com/viewtopic.php?f=117&t=2126

Hey fzabkar,

Just wanted to let you know that I finally found the solution to this issue. I checked the drive, and yes, the dirty bit was set. After trying Photorec and seeing that it indeed could find the contents of some of my files (albeit without any filenames or identifiers), I then tried Recuva, and it found my directories/files inside .chk directories. It's still a bit scattered, but there's a couple main .chk folders that have, for example, my C:\Users\<myname> directory, with the structure and files (even timestamps) still correct.



From what I understand, these files were segregated by chkdsk (either saved by chkdsk or need to be processed by chkdsk...or something).

I'm saving them to an external drive, and then will probably let chkdsk run on the drive to see what it resolves to.
 

Nmopt

Reputable
Dec 28, 2014
66
0
4,660
5
The only chance you got is to bring it to a professional company to read the data out, because data is never really ''lost'' but that costs a well sum of money.
 
Sep 1, 2019
22
0
20
2
I would remove one member of each RAID and set it aside.

Then I would examine the other member with a disc editor, eg DMDE.

Can you showe us the Partitions window in DMDE?

https://dmde.com/
Hi fzabkar, thanks for the reply!

Here's that window. I'm not really sure exactly what all this means or what I'm looking for. (I'm a software developer btw, so I can figure it out if you have some pointers).

 
Last edited:
I can't see any reason why uninstalling a driver would trigger a mass deletion. Instead I was wondering whether you had inadvertently deleted your old partitions and reinitialised your drive. If this were the case, then you might see your old files if you double-click the $Noname05 volume and expand the Root. Also try $Noname02 (your current volume).

If this doesn't work, and if you have indeed deleted your files, then trim would most probably have destroyed any chance of recovery. :-(
 
Sep 1, 2019
22
0
20
2
I can't see any reason why uninstalling a driver would trigger a mass deletion. Instead I was wondering whether you had inadvertently deleted your old partitions and reinitialised your drive. If this were the case, then you might see your old files if you double-click the $Noname05 volume and expand the Root. Also try $Noname02 (your current volume).

If this doesn't work, and if you have indeed deleted your files, then trim would most probably have destroyed any chance of recovery. :-(
Interesting, yeah that does show "some" files, but they're pretty scattered and almost all of them are random OS files or .chk files (which I'm not sure what they are), and lots of duplicate directories.

My guess at what happened was that somehow windows became unable to access certain files, so it detected a corrupted install and decided to start fresh for some reason.








 
It appears that you've done a full scan. I was wondering what was visible immediately after expanding the Root, without a full scan. A full scan shows everything that was found, including deleted files. CHK files are file fragments discovered by CHKDSK.

Anyway, it seems that there is no simple way to recover your data. If you want a free solution, try a full scan with PhotoRec. The basic version of DMDE costs US$20.
 
Reactions: DavidSchwegler
Sep 1, 2019
22
0
20
2
It appears that you've done a full scan. I was wondering what was visible immediately after expanding the Root, without a full scan. A full scan shows everything that was found, including deleted files. CHK files are file fragments discovered by CHKDSK.

Anyway, it seems that there is no simple way to recover your data. If you want a free solution, try a full scan with PhotoRec. The basic version of DMDE costs US$20.
Just opening the volume (without full scan) looks like I would expect if all the stuff was there.... But there's nothing in, say, Program Files or Windows if you expand those directories.



By the way, I was going to ask here anyways, but maybe you know the answer. When I boot to my Win 7 install (non-raid ssd), at startup it wants to run a chkdisk on both my Win10 drive (the problematic drive raid ssds), and on my storage drive (the still functioning raid hdds). I skip it each time because I'm worried what it's going to try to do (since I can't think of a reason why anything would be wrong with them or what it's trying to do, especially my storage drives lol). Any thoughts there?
 
I'm assuming that both drives are formatted as NTFS.

If cached data are not properly flushed to an NTFS volume, or if the system powers off during a file operation, then the NTFS "dirty bit" is set. On the subsequent boot Windows sees the dirty bit, realises that there are potential inconsistencies in the file system, and then executes CHKDSK in order to repair them.

That's one possible explanation, AISI. You can sometimes confirm that this is happening by examining the Unexpected Shutdowns attribute in the drive's SMART report.

Locating the NTFS "dirty bit":
http://www.hddoracle.com/viewtopic.php?f=117&t=2126
 
Reactions: DavidSchwegler
Sep 1, 2019
22
0
20
2
Ok, thanks for the info. Yes, that makes sense, since there's been quite a few "unexpected" shutdowns during this process. Sounds like it's unrelated to RAID then.

By the way, viewing the sector details on the problematic drive, the first block is filled, then most of the next ~131,560 blocks are all 0's, then from there to the end seem filled with stuff. I particularly noticed the message "Invalid partition table. Error loading operating system. Missing operating system.", in the right column.





Photorec is actually finding a TON of files, thanks for that suggestion!! Sadly all the filenames are gibberish and there isn't really any metadata, so this is going to take ages to sort out the real files from program files, but it gives me some hope.
 
Sep 1, 2019
22
0
20
2
I'm assuming that both drives are formatted as NTFS.

If cached data are not properly flushed to an NTFS volume, or if the system powers off during a file operation, then the NTFS "dirty bit" is set. On the subsequent boot Windows sees the dirty bit, realises that there are potential inconsistencies in the file system, and then executes CHKDSK in order to repair them.

That's one possible explanation, AISI. You can sometimes confirm that this is happening by examining the Unexpected Shutdowns attribute in the drive's SMART report.

Locating the NTFS "dirty bit":
http://www.hddoracle.com/viewtopic.php?f=117&t=2126

Hey fzabkar,

Just wanted to let you know that I finally found the solution to this issue. I checked the drive, and yes, the dirty bit was set. After trying Photorec and seeing that it indeed could find the contents of some of my files (albeit without any filenames or identifiers), I then tried Recuva, and it found my directories/files inside .chk directories. It's still a bit scattered, but there's a couple main .chk folders that have, for example, my C:\Users\<myname> directory, with the structure and files (even timestamps) still correct.



From what I understand, these files were segregated by chkdsk (either saved by chkdsk or need to be processed by chkdsk...or something).

I'm saving them to an external drive, and then will probably let chkdsk run on the drive to see what it resolves to.
 

ASK THE COMMUNITY

TRENDING THREADS