Recuva crashes on U.2 SSD

Recuva Recuva Bug Reporting
1

Hello,

I’ve been using Recuva for several years. Recently, I got hold of a U.2 SSD and attached it to the M.2 slot of my motherboard through a U.2 to M.2 converter.

Problem is, Recuva just crashes whenever I try to scan this SSD.

I’m attaching a log obtained in debug mode if it may give any clues as to what’s going wrong.

Thanks,
Bitman

[2025-10-19 14:01:03] [INFO ] Recuva v1.54.120 (64-bit)
[2025-10-19 14:01:03] [INFO ] System Info: Windows 11 Pro 64-bit, Intel Core i7-8700 CPU @ 3.20GHz, 32.0GB RAM, NVIDIA GeForce GTX 1660 Ti
[2025-10-19 14:01:03] [WARN ] LibRecuva::MountedVolumes::GetVolumeHandle: NtOpenFile() failed for \Device\HarddiskVolume9,
[2025-10-19 14:01:03] [WARN ] LibRecuva::Drives::Ssd::IsSSD: Identify device incorrect - all zeros
[2025-10-19 14:01:03] [WARN ] LibRecuva::MountedVolumes::GetVolumeHandle: NtOpenFile() failed for \Device\HarddiskVolume13,
[2025-10-19 14:01:03] [WARN ] LibRecuva::MountedVolumes::GetVolumePhysicalDisksNumbers: IOCTL_VOLUME_GET_VOLUME_DISK_EXTENTS failed with GLE(0x15)
[2025-10-19 14:01:03] [WARN ] LibRecuva::MountedVolumes::GetVolumeHandle: NtOpenFile() failed for \Device\VeraCryptVolumeM,
[2025-10-19 14:01:03] [WARN ] LibRecuva::MountedVolumes::GetVolumeHandle: NtOpenFile() failed for \Device\VeraCryptVolumeN,
[2025-10-19 14:01:03] [WARN ] LibRecuva::MountedVolumes::GetVolumeHandle: NtOpenFile() failed for \Device\VeraCryptVolumeO,
[2025-10-19 14:01:03] [WARN ] LibRecuva::MountedVolumes::GetVolumeHandle: NtOpenFile() failed for \Device\VeraCryptVolumeP,
[2025-10-19 14:01:03] [WARN ] LibRecuva::MountedVolumes::GetVolumeHandle: NtOpenFile() failed for \Device\VeraCryptVolumeM,
[2025-10-19 14:01:03] [WARN ] LibRecuva::MountedVolumes::GetVolumeHandle: NtOpenFile() failed for \Device\VeraCryptVolumeN,
[2025-10-19 14:01:03] [WARN ] LibRecuva::MountedVolumes::GetVolumeHandle: NtOpenFile() failed for \Device\VeraCryptVolumeO,
[2025-10-19 14:01:03] [WARN ] LibRecuva::MountedVolumes::GetVolumeHandle: NtOpenFile() failed for \Device\VeraCryptVolumeP,
[2025-10-19 14:01:03] [WARN ] LibRecuva::MountedVolumes::GetVolumeHandle: NtOpenFile() failed for \Device\HarddiskVolume9,
[2025-10-19 14:01:03] [WARN ] LibRecuva::MountedVolumes::GetVolumeHandle: NtOpenFile() failed for \Device\HarddiskVolume13,
[2025-10-19 14:01:03] [INFO ] CMainWnd::CheckForUpdates: Check for updates: is enabled
[2025-10-19 14:01:03] [INFO ] Piriform::CUpdateCustom::GetCurrentVersion: Check for updates: current version 1.54.120
[2025-10-19 14:01:03] [INFO ] CMainWnd::CheckForUpdates: Check for updates: new update is not available
[2025-10-19 14:01:03] [INFO ] Recuva::Updates::CCheckForUpdates::CheckThread: Check for updates url:
[2025-10-19 14:01:03] [INFO ] Recuva::Updates::CCheckForUpdates::CheckThread: Check for updates: version 1.54.120|0|0 is not available.
[2025-10-19 14:01:04] [INFO ] CMainWnd::CheckForUpdatesComplete::<lambda_2>::operator (): No update available
[2025-10-19 14:01:11] [INFO ] LibRecuva::FileSystems::`anonymous-namespace’::LogBootSector: Boot sector:
61KQTlRGUyAgICAAEAEAAAAAAAAA+AAAPwD/AAAQAAAAAAAAgACAAP/th98AAAAAAAAMAAAAAAAC

AAAAAAAAAPYAAAABAAAAXABzMi5zMigAAAAA+jPAjtC8AHz7aMAHHx5oZgDLiBYOAGaBPgMATlRG

U3UVtEG7qlXNE3IMgftVqnUG98EBAHUD6d0AHoPsGGgaALRIihYOAIv0Fh/NE5+DxBieWB9y4TsG

CwB126MPAMEuDwAEHloz27kAICvIZv8GEQADFg8AjsL/BhYA6EsAK8h377gAu80aZiPAdS1mgftU

Q1BBdSSB+QIBch4WaAe7FmhSERZoCQBmU2ZTZlUWFhZouAFmYQ4HzRozwL8KE7n2DPzzqun+AZCQ

ZmAeBmahEQBmAwYcAB5maAAAAABmUAZTaAEAaBAAtEKKFg4AFh+L9M0TZllbWmZZZlkfD4IWAGb/

BhEAAxYPAI7C/w4WAHW8Bx9mYcOh9gHoCQCh+gHoAwD06/2L8Kw8AHQJtA67BwDNEOvyww0KQSBk

aXNrIHJlYWQgZXJyb3Igb2NjdXJyZWQADQpCT09UTUdSIGlzIGNvbXByZXNzZWQADQpQcmVzcyBD

dHJsK0FsdCtEZWwgdG8gcmVzdGFydA0KAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIoBpwG/AQAAVao=

[2025-10-19 14:01:11] [INFO ] CNtfsUndeleterImpl::FindFileRecords: Reading MFT

2

Anyone?!? Please!

3

I would assume that “VeraCryptVolumeM” is the problem.

It looks like the partitions, or the whole drive, is encrypted and so Recuva cannot access them/it.

4

nukecad,

thanks for your reply. M:, N: and all the others are encrypted volumes that I sometimes mount, but they weren’t even mounted when I did the test. Guess Recuva found traces of them in the registry and searched for them, or something. I retried today and I can confirm that they appear in the log even if they are not mounted at the time when Recuva runs.

The drive I’m trying to analyze is D:, an unencrypted 16 TB U.2 SSD attached to the M.2 slot of my motherboard through a U.2 to M.2 converter.

Recuva’s bootup sequence seems to conclude successfully (entries with timestamps [2025-10-19 14:01:03-04] from my log), but then it crashes when I start scanning D: (the two entries with timestamp [2025-10-19 14:01:11]). Any help, please?

Cheers,
Bitman

5

Sorry but I have no idea what that gobbledygook in the debug log might mean, so the best I can suggest is contacting support.
They should have someone who can interpret those logs.

All customers MUST now access a ‘Live Chat’ support service.
To start raise a support ticket by using this: Contact Form.
Once you submit the form you will be given a support ticket/ID number onscreen, with a summary of your request.
Below that is the button to go straight into the ‘Live Chat’ where a virtual assistant will try to help you.
If the AI can’t help then you will be passed to a real person.

Note - We have been told that you MUST engage with the chat or you may not get a reply to your request form.
Note2 - It appears that the system is currently overloaded. Users are reporting very long waits for the Live Chat to respond.

6

Thanks! I filled the form and chatted with an AI that apparently understood my problem 100% and suggested some troubleshooting steps which, unfortunately, didn’t help, such as running Recuva as Administrator (which I already tried) and running a deep scan (which I hadn’t tried before but didn’t work). Nevertheless, it’s my first experience with an actually helpful and not-full-of-canned-answers AI. Now I’m waiting in line to chat with a human operator.

Best,
Bitman