Recuva stuck on analysing damage

Recuva Recuva Bug Reporting
1

Recuva always stuck on 52% on one of disks when analysing damage. Disk is healthy trying to recover deleted 24GB file.

image.thumb.png.267f37ea229ae875ae55b88a150c1d30.png

image.thumb.png.4de3c055fd5e2fa5db73908a57c8deca.png 

Debug log



[2022-11-18 01:47:07] [INFO ] CNtfsUndeleterImpl::FindFileRecords: Reading MFT
[2022-11-18 01:47:07] [INFO ] CNtfsUndeleterImpl::FindFileRecords: Reading files
[2022-11-18 01:47:07] [WARN ] LibRecuva::MountedVolumes::GetVolumeHandle: NtOpenFile() failed for \Device\HarddiskVolume4, 
[2022-11-18 01:47:07] [WARN ] LibRecuva::MountedVolumes::GetVolumeHandle: NtOpenFile() failed for \Device\HarddiskVolume4, 
[2022-11-18 01:47:07] [WARN ] CheckHResult: (backupComponents->Query()) failed with hresult (0x1)
[2022-11-18 01:47:07] [ERROR] LibRecuva::Util::LogBaseException: Base exception: drives.shadowcopy.drivelistfactory.cpp(15) : backupComponents->Query() failed (0x00000000)

[2022-11-18 01:47:15] [INFO ] CNtfsUndeleterImpl::FindFileRecords: Rebuilding folders
[2022-11-18 01:47:15] [INFO ] CNtfsUndeleterImpl::FindFileRecords: Restoring tree
[2022-11-18 01:47:15] [INFO ] LibRecuva::Utils::LogOperationDuration::LogOperationDuration: LibRecuva::Scan::StageAnalyzeDamage::AnalyzeDamage started.
[2022-11-18 01:47:15] [INFO ] LibRecuva::Scan::StageAnalyzeDamage::AnalyzeDamage: Analyzing damage of 201798 files.
[2022-11-18 01:47:15] [INFO ] CDamageAnalyzer::PerformAnalysis: 33231 deleted files, 168567 filesystem objects
[2022-11-18 01:47:17] [INFO ] LibRecuva::Utils::LogOperationDuration::~LogOperationDuration: LibRecuva::Scan::StageAnalyzeDamage::AnalyzeDamage ended. It took 1.419000 seconds.
[2022-11-18 01:47:17] [INFO ] LibRecuva::Utils::LogOperationDuration::LogOperationDuration: LibRecuva::Scan::StageAnalyzeDamage::ProcessEmails started.
[2022-11-18 01:47:19] [INFO ] CMboxCurrentMessage::CMboxCurrentMessage: mbox: Starting the stream, size 2806522411

image.png

2

The usual recommendation when Recuva is stuck on stage 2 (or 3) is to cancel the job. The list of files found is still displayed. I don't know what the cause is but Recuva is - I assume - trying to sort and analyse in memory the data found. Perhaps it is trying to extract further info from the disk.

You have a specific file names in the path/filename box. It may be a better choice if you leave this box clear so that Recuva will return all files found, a sort of bigger net.

You also say you are trying to recover a 24 gb file. On file deletion Windows' file system (NTFS) will delete cluster addresses on files larger than 4 gb, so the chances of recovering such a large file are somewhere between minimal and zero. Perhaps the lack of valid cluster addresses is causing Recuva to stall. Who knows?

3

Was able to recover everything using Photorec. As the file was email MBOX folder it was able to extract each email separately which later I joined back as MBOX and indexed. Only one week of emails missing. Seems it worked as Photorec largely ignores filesystem and scanned all free space for file types according to filter.