Deep scan: not enough memory

Recuva
1

Hi everybody (it's my first post)!

I've tried using recuva to recover files from a 370 GB (formatted: that's why I need deep scan) NTFS Windows partition.

I've used Recuva Portable (zip package) 32 bit v.147 on a WindowsXP (32 bit) system (more details on it will follow later) installed on a different hard disk.

Here's what is happening:

---------------------------------

->"Step 1" goes on until 87%, then jumps directly to 100%.

->I get a message telling me there's not enough available memory before I can see any "Step 2" stage.

->All this process lasted about 6h 30m.

Important:

-------------

I tested it twice: first on Windows XP with 2GB of RAM, then on Windows XP 3GB of RAM (*), and the result was exactly the same.

Possible causes:

----------------------

1) Address space gets limited to a max of 2 GB in Windows XP 32 bit.

2) PAE support is missing.

Possible solutions to the above causes:

--------------------------------------------------

1) Maybe recompiling Recuva with the /LARGEADDRESSAWARE compilation flag could add 1GB to the program address space (bringing it to a total of 3 GB). I still don't know if it's enough but it's worth trying...

2) I don't know much about PAE, but I think it should affect systems with more than 4 GB of RAM (not my case).

Could somebody please tell me if there are other ways to solve this problem ?

(*) Actually I'm using Windows XP 32 bit inside VirtualBox from a Linux 64 partition (that's why I can change the amount of RAM. I needed "RAW disk storage", described in VirtualBox manual, to make Racuva find my NTFS partition).

P.S. I've tried running the 64bit version of Recuva under Wine (from my Linux 64), but it was impossible to make it access the NTFS partition.

2

Perhaps Linux and / or Virtual Box is introducing some restrictions upon the Access by Windows XP to your hardware.

Comment ( I am not confident of this but it seems plausible )

If you have 64 bit hardware and 64 bit Linux, the probability is that you have to allocate 6 GB of 64 bit RAM as seen by Linux for 32 bit XP to have the benefit of 3 GB of RAM.

When you tried 2 GB and then 3 GB of RAM, was this as allocated under 64 bit Linux, or as seen by 32 bit XP ?

Suggestion :-

Install 32 bit XP as a dual boot and run Recuva under native XP, not a virtual imitation.

3

Although it's not entirely clear what you've done or are trying to achieve, the usual process for recovering live files from an NTFS partition that has been formatted is to run a normal scan with Options/Actions/Scan for Non-Deleted Files checked (available in Advanced Mode only). This will be far faster and use fewer resources.

4
When you tried 2 GB and then 3 GB of RAM, was this as allocated under 64 bit Linux, or as seen by 32 bit XP ?
As seen by 32bit XP (I can check it on the System page of XP).

Install 32 bit XP as a dual boot and run Recuva under native XP, not a virtual imitation.
This should be probably better, but ,as I've already explained, I guess it would not change my problem (I remember some month ago I managed to run an old version of Recuva from a "Live XP CD" I made myself (there are free programs around that can create it from a Windows XP installation CD: the deep scan "step 1" stopped after a while without completing due to the lack of memory).

The problem seems to be the 'cut' of RAM memory addressable by the program (and if this is true I guess many users could experience the same problem with WinXP and deep scan). That's why I suggested building Recuva with the /LARGEADDRESSAWARE compilation flag (does somebody know if this have already been done?).

the usual process for recovering live files from an NTFS partition that has been formatted is to run a normal scan with Options/Actions/Scan for Non-Deleted Files checked (available in Advanced Mode only). This will be far faster and use fewer resources.
Thanks for pointing it out; anyway I've already tried it and I can only found very few files (not of my interest). When I stop the deep-scan early I can find some of the files I was looking for.
5

You may have to pay for official support to get an answer from the developers upon the feasibility of changing the compilation flag and then debugging the result.

It might be quicker and easier for you to find / make a friend with a 64 bit version of Windows that does not run out of memory,

or perhaps approach someone in the computer classes at a local school/college.

6

You may have to pay for official support to get an answer from the developers upon the feasibility of changing the compilation flag and then debugging the result.

It might be quicker and easier for you to find / make a friend with a 64 bit version of Windows that does not run out of memory,

or perhaps approach someone in the computer classes at a local school/college.

Yes, that make sense. Thanks for the tip :rolleyes: .
7

Hi everybody (it's my first post)!

Hi Imnt, and welcome to Piriform.