Photorec deadlock and output‑path corruption during long recovery

[artfuldodger348-del]

During a large‑scale recovery of MP4 files from a damaged NTFS volume, Photorec exhibited several technical failures that appear related to thread deadlock, state corruption, and incomplete persistence of session metadata.

1. Hard deadlock during long scans
   Photorec repeatedly entered a state where:

UI stopped updating (timer and sector counter frozen)

CPU usage dropped to zero

Window could not be closed

Process could not be terminated normally

Windows eventually terminated the process silently, leaving the window visible but non‑functional. This suggests a deadlock in the main recovery loop or an unhandled exception in the worker thread.

2. Resume session does not persist output directory
   After restarting and selecting “Resume previous session,” Photorec correctly restored the sector position but did not restore the output directory. It instead wrote recovered files to default locations (recup_dir.* in root or next to the executable).

This indicates the output path is not included in the session metadata or is not reloaded correctly.

3. Session resume with corrupted output path
   In several cases, Photorec resumed scanning and incremented the “files recovered” counter, but no files were written to disk in any location. This implies the output path pointer was null or invalid, yet the recovery loop continued.

This behaviour suggests:

output path string corruption

missing validation of the output directory before write

recovery loop continuing despite failed write operations

4. Silent failure modes
   Photorec did not report:

write failures

invalid output paths

inability to create recup_dir.*

exceptions during resume

The tool continued scanning and reporting recovered files even when no output directory existed.

5. Impact
   These issues caused:

loss of recovered data

inconsistent output behaviour

difficulty verifying recovery completeness

significant manual effort to locate or confirm output directories

6. Suggested improvements
   Persist output directory in session metadata

Validate output path on resume

Abort recovery if output directory is invalid

Add error reporting for write failures

Add watchdog or timeout for deadlocked recovery loops

Improve robustness of session resume state

Photorec is a valuable tool, but these reliability issues make long‑running recovery operations unpredictable and difficult to trust

[cgsecurity]

It suggests bad sectors on the source disk.

[artfuldodger348-del]

Source disk thoroughly checked revealing no bad sectors identified but still need to run deeper analysis but expect the same result as no behaviour from disk suggested any issues at all - this was done before running this process to check for this very reason. Hardware is new and reputable

[cgsecurity]

testdisk & photorec don't use threads, so they can not deadlock. As CPU usage was zero, it's not an infinite loop.
It means photorec was waiting for the read operation to finish. Run PhotoRec under Linux, do you have the same problem ?

[artfuldodger348-del]

Thanks for the explanation. Just to clarify: the behaviour I saw didn’t match a normal slow read. During the stall, the sector counter, timer, and recovered file count all stopped completely, CPU dropped to 0%, and PhotoRec stopped responding to input. Windows showed no disk activity, and the process didn’t resume even after waiting a long time.

The source disk has been fully checked (surface scan + SMART) and shows no bad sectors or read‑error behaviour. After restarting PhotoRec, the same region scanned normally, which suggests the freeze was caused by the Windows I/O layer blocking the read rather than the disk itself.

I haven’t rerun the recovery under Linux, but based on the disk health and the behaviour after restarting, it seems the issue was specific to Windows under heavy I/O load rather than a hardware fault.