Page 1 of 1

TestDisk DEEPER SEARCH potential crash?

Posted: 31 Oct 2023, 14:50
by Salad70
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 ... ecame-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, and can't trigger "stop". Using Task Manager I can see the program *seems* to still be running (the CPU % usage is fluctuating, and its employing 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 over 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're able.

Re: TestDisk DEEPER SEARCH potential crash?

Posted: 01 Nov 2023, 18:47
by recuperation
Salad70 wrote: 31 Oct 2023, 14:50 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 ... ecame-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 won't accept such a statement without having seen all the extracted single SMART parameters as described in
viewtopic.php?f=5&t=10910
But even is everything looks OK, the disk may be broken.

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%
That appears too slow to me. You can calculate the transfer speed from the data you are showing. A sustained transfer speed of like 130 MB for a 5400 rpm drive is a rough indication how fast TestDisk should be.

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, and can't trigger "stop". Using Task Manager I can see the program *seems* to still be running (the CPU % usage is fluctuating, and its employing 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 over 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're able.
There is no "refresh" type thing that you require and just killing the TestDisk process would be sufficient.
In order to avoid stressing a possibly dammaged disk you might duplicate it using ddrescue as described in the manual.
You would then rerun TestDisk against the phyiscally healthy duplicate.