[Recuva stuck at damage analysis]

8 hours ago, Augeas said:

Whatever you've found look at the header data in the Info pane in Advanced mode.It's likley to be all zeroes. It is almost impossible to recover data from a modern SSD.

 

I assume the file is completely lost because it says the file data cannot be found on the drive. I'll do a deep scan and see if that'll glean any more info. 

[Recuva stuck at damage analysis]

17 minutes ago, Augeas said:

Cancel stage 2. You will still get the results displayed and you can recover anythng found.

 

I forgot to mention that I did try this as I found that answer on someone else's topic. In my case, the program stopped responding, I let it sit for a few hours and nothing happened. I figured it crashed so I forced the program to close.

Edit 1: I canceled before it reached 55% and It seems to be working now. I am however concerned a little bit as it says the file im looking for is no longer on the disk. It's not overwritten, as I have only performed read operations on the SSD since the time of deletion. I will look further onto my other drives to see if they were relocated for some reason.

Edit 2: I read another topic that mentioned the difference in recycled files, where $R is file data and $I is the filename. The file I found only has the $R and I cannot find a $I. I'm not entirely certain that is is the file because it says its size is close to 10 Gb, where the original file was closer to 1.5 Gb.

[Recuva stuck at damage analysis]

I posted this issue on the main forum and figured that was the wrong place to post it, and I dont think I explained the problem correctly. I am trying to recover an accidentally deleted .7z encrypted archive from an SSD. When I go to start the recovery process, I tell it to search for compressed files, and I don't do a deep scan. It breezes through the first stage, but on the second stage it stops at 55% and will not progress any farther. More interesting is that the wait time increases, and as of yesterday, it says an estimated 15 days. I ran Recuva in debug mode and in the log file, this repeats over and over continuously:

[2020-01-01 17:38:33] [WARN ] LibRecuva::Drives::Ssd::IsSSD: Identify device incorrect - all zeros
[2020-01-01 17:38:33] [WARN ] LibRecuva::MountedVolumes::GetVolumeHandle: NtOpenFile() failed for \Device\PartitionWizardDiskAccesser, 
[2020-01-01 17:38:33] [WARN ] LibRecuva::MountedVolumes::GetVolumeHandle: NtOpenFile() failed for \Device\PartitionWizardDiskAccesser, 

 

Here's what what the window looks like (It's pretty vague on its own):

And here's the log file:

Recuva_log[1_53_1087 (64-bit)][01-01-2020_17-36-51.637].txt

 

Any help with this issue would be greatly appreciated!

[Recovered unknown files]

11 hours ago, nukecad said:

Maybe as part of a factory test?

 

Seems likely, but why would they use "family" videos, and not stock footage such as a waterfall or sunset ect...?

[Recovered unknown files]

I can't imagine a store restocking a used thumb drive, but I guess it isn't unheard of. My guess is that someone had used that drive previously, otherwise, how else would the files get there?