What does it mean when the results of a scan for deleted files shows a comment "Ran out of memory" in the list of deleted files? And what do I need to do to eliminate this?
I am using Recuva v1.42.544 on a Vista Home Premium, Intel Core 2 Quad CPU @2.40HGz, 4.00GB RAM,
Thanks.
Hi rwintx, and welcome to the forum.
Have a read here, including the link in post #2 ...
http://forum.pirifor...showtopic=32992
And thanks for the logs, the devs do read all posts.
Hope that helps.
EDIT: Are you using "deep scan"? Try the normal scan if you haven't already.
Thank you DennisD. I am using Vista 32bit. I used normal scan not deep scan. I appreciate the link you gave, but I have to agree with D00dle, in that the Microsoft explanation was clear as mud. I am trying to recover a single 196MB wmv video file. Any additional suggestions are appreciated. Thanks.
Have a read here ...
Quick Start: Recovering files of a specific type (or in a specific location):
Or try a quick search for .wmv files ...
I've always found it helps to set the view mode to "Tree View" in "Options/General", and to set the actual recovery mode to "Restore Folder Structure" in "Options\Actions\Recovering".
The first will display scanned files in their original folder structure, and the second will recover files to a copy of their original folder structure on another drive or partition.
Don't recover to the same drive of course, and try normal mode first. You never know.
If you hit the "Out Of Memory" thing again, Recuva may still display files scanned up to that point. Not 100% on that as I've never hit that message, but Recuva does show files scanned to the point of a scan stopped manually.
Hope that helps
Thanks DennisD. To elaborate a bit on what I have done before trying your suggestions: I used the wizard, scanning for video files, located in the drive/folder from which the file was deleted. I think the scan is finishing without aborting. The deleted file is found and listed in the results. On the same line as the deleted Filename is the state "Unrecoverable" with the comment on this same line "Ran out of memory". My hope is that if I can eliminate the comment, the file will then be recoverable. Thanks again, and I will examine you suggestions in greater detail.
A couple more pieces of information. I expanded the scan to include more folders so now the file I want to recover is not the only one on the list. It is in the middle of the list, so I think the scan completed, even though the scan may have given up on the file I am interested in. I also was watching the Memory (Private Working Set) in Windows Task Manager for Recuva.exe, it went over 1GB, then decreased. Any more thoughts? Thanks.
I tried your suggestions, and I still get the same results. I also tried running Recuva in Windows XP compatibility mode and got the same results. I doubt that it is meaningful, but Recuva v1.25.409 gives the comment "bad allocation", rather than the comment "Ran out of memory". What should I try next? Thanks for your help.
You haven't said, but I'm thinking here that the file you're looking for may be on your system drive. Is that the case?
If so, because Windows is in a more or less permanent state of flux, it's possible that your file may have been overwritten.
If it's on another drive or partition, have you been writing anything to that location?
On the same line as the deleted Filename is the state "Unrecoverable" with the comment on this same line "Ran out of memory". My hope is that if I can eliminate the comment, the file will then be recoverable.
I don't know how you would do that but good luck with the idea.
At this stage, I usually suggest the option of trying other recovery programs in case they can just maybe do what Recuva is failing to do, although in this case it doesn't sound good for the recovery of that file, and Recuva is very good at doing what it does.
Have a look at some other programs from the link in this thread ...
http://forum.piriform.com/index.php?showtopic=35624&view=findpost&p=213366
... and in the meantime, I'm sure if any of the other guys can come up with a suggestion I may have overlooked, then I'm sure they'll do so. And if I can come up with anything else I'll post it of course.
Let us know if you have any success or not.
Thanks DennisD. The drive I am trying to recover from is not a system drive. It is an external USB drive. I have not been intentionally writing to that drive, and do not have any reason to believe anything is being written to that drive or that the deleted file has been overwritten. When I expand the locations scanned other deleted files are detected. Some have the same comment and some have different comments than the "Ran out of memory". Hence my hope that if I can prevent Recuva from running out of memory when scanning particular deleted files I might be able to recover the one I am interested in. It seems like I could do this if Recuva did not use over 1GB of memory in scanning for a 196MB file. So, if there is a setting on my computer or on Recuva that helps Recuva know that it needs to restrict itself to a reasonable amount of memory when scanning for deleted files I might eliminate the "Ran our of memory" comment. I guess that this could also be a bug in Recuva that is being worked on, but you are the only one giving me input so I doubt that it is being worked on. Thanks for the other suggestions, I will look into them. I continue to hope that someone will have a solution to this, as it does not seem reasonable to me that Recuva requires so much memory that it runs out. Thanks again.
The deleted file is found and listed in the results. On the same line as the deleted Filename is the state "Unrecoverable" with the comment on this same line "Ran out of memory".
That sounds quite simply like the file you want is past recovering, but if you could show us a screenshot of the above it may help as I've never been in the situation of running out of memory, and I work with 2gb in XP.
Regarding trying to avoid that message, all I can suggest is to make sure you are running with an adequate paging file. The Microsoft recommended size is one and a half times the size of your total memory.
On top of that, disable every running program/process that you can. Maybe even disconnect from the internet and disable your A/V.
Whether this would make a significant difference I don't know, as none of us here are Recuva developers, but sadly there are times when a file is just beyond recovery.
Have a look at the size of your paging file, and if you need help with that just ask, and post back your findings.
The external USB drive I am scanning is 2TB, could the size of that drive be a problem? I will try your additional suggestions and get back to you. Thanks for the help.
I would say that is a significant fact, as Windows Vista has set limits of memory it can handle, as explained in that "clear as mud" Microsoft article.
Physical Memory Limits: Windows Vista
If I'm misreading that, someone will surely put me right.
I do not have current access to my Vista machine. So I tried Win XP on the laptop, and got the same results. Attached is a screen shot. I will look into the other suggestions later. Thanks again.
Hi Rwintx,
There have been, as far as I can recall, problems with scanning very large drives. The drive also appears to have a large sector/cluster size, but Recuva should handle that.
When you do a normal scan for video, or any other specified type of file, Recuva will scan the entire File Allocation Table and then discard what it doesn't want. Recuva will always do a complete scan of all files. You can check this by running the scan using the Wizard and then pressing Switch to Advanced mode, where the bottom line will show how many files have been ignored. The point of all this is that specifying a folder or location to scan will not reduce the amount of files scanned, nor the amount of memory used. You would be better off just specifying the drive to scan, as this will find files that have lost their folder info.
I don't know what Recuva stores in memory, but I guess the error message is self-explanatory.
I would suggest:
1) Running the normal scan on the whole drive for video files and cancelling stage 2 as soon as it starts. I don't really know what Stage 2 does, but this might stop the memory problem. Then recover.
2) Running normal scan as above, and then recovering whatever you find whatever the file state is. 'Unrecoverable' is not quite true, as any clusters can be recovered (i.e copied to another location). I think that what Recuva is saying is that the data on the clusters might not be in a usable state. So recover anyway and see what you have.
Augeas and DennisD, thank you both for your help. I have not gotten to all of the suggestings, I may never understand the Microsoft explanation, but here is an update of what I have found out. I think the size of the external USB drive is a problem for Recuva. I tried Recuva on the system drive and got a variety of scan results, some deleted files recoverable, some not recoverable, having been overwrirren. But none had the comment "Ran out of memory". I ran Recuva for all file types and all folders of the external USB drive. All deleted files were unrecoverable, either overwritten or "Ran out of memory", some of the 'Ran out of memory" files were only 2KB. When I scan the system drive I see a nornal progression through both stages 1 and 2. When I scan the external USB drive I see stage 1 progess zoom from 6% to 99% and memory usage goes through the roof. I don't think stage 2 is even running on the external USB drive scan. Thanks again for all the help.
I should also have mentioned, I have tried to recover the file even though it is not recoverable. VLC video player recognizes it as video and tries to play it. There is a brief image, only for a fraction of a second, and then the screen goes black. This has been consistent throughout all my efforts. I have tried to stop the scan at the end of stage 1, before stage 2, but I do not know I was ever successful since the stage 1 scan always went from 99% progress to completion, whether I tried to stop the scan or not.
My opinion is that Recuva runs out of memory whilst trying to build its internal tables containing the folder structures, file details etc. I would think that the cluster runs it has extracted for the files are correct. If that's so, and the file you've recovered is unplayable, you may have lost the file.
I don't think you'll get much from this, but with the file name filter on try a few scans and cancel stage 1 early, Eventually you will catch the file hopefully without blowing the memory. The comment field should be completed - if so what does it say?
Then switch to Advanced Mode and highlight the file. Select Info in the right-hand panel. What does it say about cluster allocation and clusters overwritten?
A couple of more tidbits. My Win XP laptop will not let me increase the maximum pagefile size beyond 4096MB, which it was set at before I started this endeavor. No matter how hard I try, I cannot stop the scan. It seems to continue until it uses up all memory.
I don't seem to be having much luck. In addition to Recuva, I have now tried TestDisk, MiniTool Power Data Recovery, and Restoration. I am beginning to think that the recovery tools are not really prepared to recover from a 2TB, FAT32, External USB drive. I will try some of the others as I have time. As always I appreciate the suggestions and hope for more. Thanks.
Windows Explorer often does not let you look through reparse points, you get warnings such as
C:\Documents and Settings is not accessible
Access is denied
CCleaner DOES look through reparse points because it cleans my Browser caches that are on E:\ because it sees them as though they were present on C:\
Vista and Windows 7 are full of Reparse points.
Given a folder structure of A\B\C\D a reparse point at D designating B might give the appearance of an infinite series
A\B\C\D\B\C\D\B\C\D\B\C\D\B\C\D\B\C\D\B\C\D\B\C\D\B\C\D\B\C\D\B\C\D\B\C\D\B\C\D\B\C\D\B\C\D\ etc
Perhaps Recuva and other tools may see a never ending sequence that exhausts memory,
especially if a 2 TB drive is already straining their capabilities.
I have no solution, but this might be a cause of the problem.
Google knows much more about Reparse points than I do.