Question TestDisk DEEPER SEARCH crash?

[Stepfly]

Apologies in advance. My technical skills aren’t high, but I was following this explainer on attempting to recover an external HD which has converted to RAW.

https://html5.litten.com/updated-how-to-fix-external-disk-drive-suddenly-became-raw/

Working on Windows 10 Home. Desktop, Intel(R) Core(TM) i3-6100 CPU @ 3.70GHz 3.70 GHz, 8GB. 64-bit operating system, x64-based processor.

The drive I’m trying to rescue is a Western Digital 4 TB USB 3.0.

I performed the GsmartControl tests suggested in the article, and the results suggested the drive is healthy i.e. no physical damage.

I used TestDisk next to try a rescue/ Repair partition table and boot sector.

A Quick Search analysis didn’t work. Got an error message.

Set a DEEPER SEARCH running, which has been going for approx 3 days and hit 45%.

I turned my monitor off at night, but when I turned it on today the TestDisk App window is unresponsive. When I click on it, I can’t interact with the tool, so I don’t know if it’s still running or has crashed. Using Task Manager I can see the program *seems* to still be running (the CPU % useage is fluctuating, and its using 21MB of memory) The light on the WD drive is still flashing as if in use.

My main question is… Is there any way to “refresh” the TestDisk utility window so I can see an update process percentage and interact with it without interrupting the DEEPER SEARCH,

OR

If not, and I need to start the DEEPER SEARCH again, is there a recommended “safe” way to quit TestDisk that doesn’t incur further damage/ issues to the WD drive?

Sorry again for any incorrect terminology, but hopefully someone could offer some basic advice. Thanks in advance if you can help.

 

[fzabkar]

It's too late now, but TestDisk was the wrong tool. You should have cloned the drive with a tool such as HDDSuperClone (now OpenSuperClone) or ddrescue.

Clearly your drive is failing -- 45% in 3 days is seriously bad.

 

[Stepfly]

Thanks for taking the time to reply. Much appreciated.

The explainers I've read seemed to say that such lengthy delays were commonplace on large drives, and I think the cause of the transition to RAW was because it was jolted and when connected my laptop and didn't get ejected properly, rather than being dropped or other damage.

Either way, I'm after advice on what to do now. Just End Task via Task Manager... or something else?

You seem to be implying it doesn't matter, and the data is probably already lost?

 

[fzabkar]

45% x 4 TB / 3 days = 7 megabytes per second

That's bad. Testdisk will have scanned 2TB, pointlessly. Instead of thrashing your drive, you should have been saving every sector to a clone. The cardinal rule of data recovery is never to recover any sector twice. If you can read it, save it -- you may not get a second chance.

A tool such as DMDE would probably have found your file system within seconds. You would then have had the choice of recovering critically important files, or you could have proceeded with cloning. Personally, I would stop Testdisk. If the file system is repairable, it doesn't need a tool to scan the entire drive.

 

[Stepfly]

Thanks for taking the time to reply. Much appreciated.

The explainers I've read seemed to say that such lengthy delays were commonplace on large drives, and I think the cause of the transition to RAW was because it was jolted and when connected my laptop and didn't get ejected properly, rather than being dropped or other damage.

Either way, I'm after advice on what to do now. Just End Task via Task Manager... or something else?

You seem to be implying it doesn't matter, and the data is probably already lost

45% x 4 TB / 3 days = 7 megabytes per second

That's bad. Testdisk will have scanned 2TB, pointlessly. Instead of thrashing your drive, you should have been saving every sector to a clone. The cardinal rule of data recovery is never to recover any sector twice. If you can read it, save it -- you may not get a second chance.

A tool such as DMDE would probably have found your file system within seconds. You would then have had the choice of recovering critically important files, or you could have proceeded with cloning. Personally, I would stop Testdisk. If the file system is repairable, it doesn't need a tool to scan the entire drive.

Ok. Thanks for taking the time to offer the clarification. It's really not my field, so I just did some googling and tried to follow the instructions which seemed to fit my situation the best.

 

[Ralston18]

And I will add the suggestion to look in Reliability History/Monitor and Event Viewer.

Either one or both tools may be capturing some related error codes, warnings, or even informational events regarding the "conversion" and subsequent crashes.