jahtrust Posted May 15, 2018 Share Posted May 15, 2018 Hy there and thank you all for your effort with Recuva! I fiddled with drive names and of course ended up in formatting the wrong drive. To top it up it was a drive with some corrupted sectors, so I cloned the drive (1 TB) onto another 1 TB drive in order to recover my data. The issue is, that when I start a deep scan (there are 3 small new files written on the formatted disk - so only they pop up if I do a normal scan) it writes about 100 GB of data into RAM and terminates with an error translating to "The instruction/statement in "0x00 ..." referred to memory at "0x00 ...". The operation could not be performed in memory" (screenshot attached). Manually cancelling the scan before RAM is full (16% of estimated scan time) results in the same thing since processing seems to use RAM, too!? I read that years ago people had issues with 4-6 GB of RAM - yet 96 GB? I must admit that there are plenty of files on the drive (some numerical modelling results - i.e. approx. 50 million files after 10% of the scan). Now I wouldn`t mind ditching most of the results since they are backed up - but there are some thousand images, too, which I need to restore, preferably with intact file names. What could be the reason for this RAM issue and how can it be solved? Help is highly appreciated!! Link to comment Share on other sites More sharing options...
jahtrust Posted May 15, 2018 Author Share Posted May 15, 2018 *update* Seriously? Cancelling after 10 % of the estimated scan time and only recovering .jpeg files the estimated disk space for the recovered data is 30x larger than what the original drive capacity was??? And the initial folder containing the images only had about 50 GB... What is this? Link to comment Share on other sites More sharing options...
Moderators Nergal Posted May 15, 2018 Moderators Share Posted May 15, 2018 looking at your screenshot tells me you're trying to blindly restore all found without looking at the results. Each file listed there have multiple copies. What you are doing, restoring files, cannot be done without forethought. You will be more successful in looking. Also recuva still scans for everything even if you apply a filter, it's best to put the filter on after the scan has occured. ADVICE FOR USING CCleaner'S REGISTRY INTEGRITY SECTION DON'T JUST CLEAN EVERYTHING THAT'S CHECKED OFF. Do your Registry Cleaning in small bits (at the very least Check-mark by Check-mark) ALWAYS BACKUP THE ENTRY, YOU NEVER KNOW WHAT YOU'LL BREAK IF YOU DON'T. Support at https://support.ccleaner.com/s/?language=en_US Pro users file a PRIORITY SUPPORT via email support@ccleaner.com Link to comment Share on other sites More sharing options...
jahtrust Posted May 15, 2018 Author Share Posted May 15, 2018 Thank you for the quick reply! Indeed I did try to restore all found .jpeg files - I wasn`t expecting the total size to be so large since the original folder had "only" about 50 GB. Could you please shed some light on how so many copies of the images can be found and also what exacty is being stored in memory? Regarding the only option I seem to have (namely cancelling the search after 10% before RAM is filled - which probably will only get me a fraction of the data!?): is Recuva the right choice, i.e. is there a way to work around the memory issue or do I need to look for alternatives? I really appreciate your help @Nergal! Link to comment Share on other sites More sharing options...
Moderators Nergal Posted May 15, 2018 Moderators Share Posted May 15, 2018 I can't answer for the strange ram issue. I will pass this up the chain to see if we can get an official answer. ADVICE FOR USING CCleaner'S REGISTRY INTEGRITY SECTION DON'T JUST CLEAN EVERYTHING THAT'S CHECKED OFF. Do your Registry Cleaning in small bits (at the very least Check-mark by Check-mark) ALWAYS BACKUP THE ENTRY, YOU NEVER KNOW WHAT YOU'LL BREAK IF YOU DON'T. Support at https://support.ccleaner.com/s/?language=en_US Pro users file a PRIORITY SUPPORT via email support@ccleaner.com Link to comment Share on other sites More sharing options...
jahtrust Posted May 15, 2018 Author Share Posted May 15, 2018 Alright - thank you Link to comment Share on other sites More sharing options...
Moderators Augeas Posted May 15, 2018 Moderators Share Posted May 15, 2018 It doesn't matter what the original folder size was, you are finding, and attempting to recover, all deleted pic files. Recuva has found 48 million pic files, even at 1 cluster each that's nearly 200 gb. At ten clusters each, say, that's 2 tb to recover. By the way I have no idea what Recuva writes to memory, apart from everything. Link to comment Share on other sites More sharing options...
jahtrust Posted May 16, 2018 Author Share Posted May 16, 2018 I see. Yet as I understood it these were 48 million total files (before I applied the filter), not pic files and I specifically tried to recover only pics which I thought were less. Anyway, meanwhile I tried to recover just a selection of the images but a) they were all "unrecoverable" which I suppose is due to cancelling the search and images not being put together/being readable yet, and b ) there were thousands of images found with the same file name and hence not many individual images were found in general (also because I had to cancel the search at 10% before RAM was full and the workstation froze and restarted). 7 hours ago, Augeas said: By the way I have no idea what Recuva writes to memory, apart from everything. I can`t really assess what you meant by that. Does Recuva read "everything" into memory or does it write "everything" to disk? The latter makes sense of course as for the recovery - yet I wonder what`s being stored/read into RAM which hardly can be the data itself, can it? Anyhow - as far as I can see this renders recovery using Recuva impossible for me. Thanks for your help @all - appreciate it Link to comment Share on other sites More sharing options...
Moderators Augeas Posted May 16, 2018 Moderators Share Posted May 16, 2018 That's me trying to be too clever. When Recuva scans it holds all its info in memory as it doesn't write to the disk, for obvious reasons. When it runs a recovery I can't see a reason why much more is held in memory - a recovery log I suppose, which can be quite large with 48 million files to be recovered. But your original post says that you're running out of ram, and your second post says you're running out of disk space. Post two also says on the bottom line that 48 million files are being recovered after the pic filter has been applied. You are biting off a great deal, perhaps more than Recuva can chew. Link to comment Share on other sites More sharing options...
jahtrust Posted May 16, 2018 Author Share Posted May 16, 2018 Sry for the confusion. I was talking about memory in terms of RAM and not disk space. Recuva fills up the 96 GB and then terminates. As @Nergal said the scan got all file types regardless of any filter and the selection was to be made subsequently to the scan according the desired file type to be recovered - so the attempted recovery(!) probably considered a fraction of the 48 million files. On the other hand, the scan did produce 48 m files at 10% of the estimated scan time already which led to exceeded RAM - so I wonder if I am the only one having this issue since there are far greater disk volumes requiring recovery I imagine Anyways - thanks for the help guys and also for maintaining this community! Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now