Eraser goes out of control!


I posted a topic here several days ago, then deleted it since it went unanswered. The topic was "Eraser seems to hang".

The problem was, when Id try to perform a simple erasure of as little as one file, Eraser would essentially hang. Well I found out a little bit more about what is going on. When this happens, Eraser isnt simply overwriting the files it should be--it is somehow inflating some of those file to an enormous size, for no obvious reason.

For example, if I try to erase a simple 1-KB text file, Eraser will often seem to "hang", when actually what its doing is turning that 1-KB text file into a multi-gigabyte monster, which devours my free space as well as my CPU time. If I let it continue, I can watch as my free hard drive space drops to nil. Of course, this takes a very long time and is an indication that something is seriously wrong!

As one specific example, the other day I tried erasing the Recycle Bin. In the Recycle Bin, among other things, was a very small text file that had been renamed (by Windows) to "DC-1.TXT". Everything was fine until Eraser got to that file. After some time, I noticed my free space was plummeting, and that DC-1.TXT was 5.5-GB in size, and growing steadily!

This is happening on WinXP SP-1, and it can happen when I try manual erasure of individual files, or when I try to erase the Recycle Bin. I am NOT mistakenly performing "erase unused disk space" operations here!

This problem is driving me crazy. Any ideas, other than "install an old version of Eraser"?


Update: I just removed Eraser 5.6, rebooted, then installed Eraser The same problem exists with this older version.

An example with Eraser I tried to erase my C:Temp directory, which contained a file named AM-Install.exe. This file started out at about 100 KB in size. Look at these screen shots, taken in quick succession, which show how simply trying to erase C:Temp made AM-Install.exe grow continually:

(Each screen shot is 92 KB in size)

Shortly after taking these screen shots, I stopped the erasing process (thankfully, it responded--sometimes, it doesnt). By then, AM-Install.exe was around 8 GB in size. If I hadnt stopped it, it would have taken up all available space on my hard drive.

Why on earth is this happening?
That sure is an odd problem. I am using Windows XP (Home Edition), with SP1 installed, and I cannot duplicate the same situation. In fact Ive never had a problem with Eraser blowing up files like that.

But then again I dont have encrypted drives or anything like that in place, just a regular unencrypted C: drive (singular partition), nothing else. Might be a reason.
Yeah, I always get the really weird problems! [B)]

I dont use Windows XP Encrypting File System (EFS), but I do use BestCrypt. I have tried to think of what might be causing Eraser to go nuts on me, but nothing makes sense... For example, anti-virus utilities cause more than their share of problems, but this problem? Its just too weird. I also cant imagine how BestCrypt could be part of the problem--yes, it has a set of drivers, but not the kind of drivers that intercept I/O like that.

Barring some insight from Sami or Heidi, I guess Ill go on a diagnostic spree myself. If I figure it out, Ill of course provide an update.

As an aside, I have installed Eraser, and so far the problem has not happened with that version.
Thanks, and good thought, but I never had that option enabled (I found out long ago that it causes its own set of problems on my WinXP system).

Still, with version, the problem hasnt happened. I will keep trying to reproduce the problem with Eraser, but so far it seems the problem is related to some change between 5.5 and 5.6.

Update: Ive repeatedly carried out the exact steps that cause the problem, using version, and no matter what I try, that version works fine. So again, the problem seems to stem from a change between 5.5 and 5.6.

Sorry, Garrett; I am just trying to provide information... I can stick with using version for the time being. Id just hate to miss out on future updates. Maybe I can quickly learn C++ and debug it myself... yeah, sure! [:p]

Ive had the exact same problem since converting my partitions to NTFS a few weeks ago. Im using Win2000SP3. It occurs mainly on certain system files and in-use files. For example, the dreaded IE index.dat files but also some obscurer Application Data files and things in the temp directory.
When it tries to erase such a file, the wiping progress meter appears to freeze and so I click cancel. Despite doing this, disk activity continues and the file grows until the partition is full before the eraser task closes. Then I just delete from Windows normally. Clearly this is a bit of a problem if the file involved is marked as in-use so that I can only kill it from the recovery console...
Affected paths include:
Application DataMicrosoftAddressBook*.*
Local SettingsApplication DataMicrosoftWinNTNTBackupCatalogs*.*
Application DataMicrosoftMediaPlayer*.*
and Mozillas history.dat

Hope this problem can be sorted out!
Best wishes,

quote:Originally posted by cantorisIve had the exact same problem since converting my partitions to NTFS a few weeks ago.Does the problem happen with Eraser version Here is where to download that version (click "" then select a mirror): ... p_id=37015

If you tried, and found the problem absent, wed be onto something for sure.

(Sidenote: In my case, at least, the "affected path" can be anything at all.)

I installed v5.5 (not 5.51) and the same problem occurred. The trigger was an XML file in content.ie5. Ive now gone back to v5.6 for the time being but in the next day or two I intend to try out some of the older versions and see if they are affected.

Best wishes,

I installed from the archive named "", but the about box shows "".

What other software do you run? Im wondering if we can find a commonality here. I am running (not that all of these could possibly be at fault--in fact, some of them are probably just plain ridiculous to list...):

PC-cillin 2003
BestCrypt 7
Script Sentry v2.7.1
BOClean v4.10
O&O Software DriveLED
quote:Originally posted by Scott
I installed from the archive named "", but the about box shows "".

Actually v5.5.2 is the same version as v5.5.1, but with the version number fixed up (soas the actual version number of the program is the same as the one mentioned in the "About" dialogue), plus one other fix which apparently affected Windows XP users. That fix is probably the only other adjustment which has been done to Eraser, all the other changes have either involved changing the installer from version to version, or minor cosmetic changes (or in the case of v5.6, toolbar buttons with the wrong icons on them).

Maybe you should try v5.5.2 and test it out. I seem to recall that the fix for Windows XP is mentioned in the changelog, and in fact references a Microsoft KB article. It might be a reason for newer versions of Eraser not working properly on your system. ...

I think Ive solved the problem. I normally shut down all my running apps before using Eraser to minimise in-use files. In view of this I didnt expect our software configurations to be relevant. But I see we both have BestCrypt installed. If you kill the bcresident.exe task before using Eraser I think you will find all is well - it has been here the past couple of days! :-D
Thanks everyone for your input.

Best wishes,

Thats good to know, but it leaves me more puzzled than before. You dont have to close any applications to overwrite files; if those files were in use, it wouldnt be possible to overwrite them at all. (You should shut everything down to erase unused disk space, but thats not what I--and I thought we--were having trouble with.)

Another mystery is why version 5.5 works fine, but 5.6 does not. Still another ponderous question is why bcresident.exe, which shouldnt have handles open on any of the problematic files, would matter.

>You dont have to close any applications to overwrite files;
>if those files were in use, it wouldnt be possible to
>overwrite them at all.

For example, ZoneAlarm and my UPS software between them make lots of logs and temp folder stuff that I have no desire to keep and that I dont want building up. I stop both lots of software so that I can get at those files to delete them as otherwise it wont let me.

>Still another ponderous question is why bcresident.exe, which
>shouldnt have handles open on any of the problematic files, would matter.

No idea! Have you tried reinstalling v5.6a and running it with bcresident.exe stopped to see if it works for you too? Would be nice to get it confirmed as the cause and not just two days of flukiness on my part!

Best wishes,

I havent tried 5.6 again, but I will, and Ill close bcresident to see if that helps. Im not sure when Ill get around to it, though.

Having had Eraser behaving for two days, last night it did its trick of turning two of the usual trigger files into monsters despite bcresident.exe being killed.
So I guess thats back to square one again. :-(

Best wishes,

quote:Originally posted by cantoris
Having had Eraser behaving for two days, last night it did its trick of turning two of the usual trigger files into monstersCould you try v5.3? It was the last version compiled with an older version of the compiler.

Assuming that GetFileSize and GetDiskFreeSpaceEx from Windows API return correct values, some weird conflict with the new compiler (possibly an integer overflow somewhere?) is the only cause for these kind of problems I can think of.

Garrett, if you can reproduce this problem, you may want to step through the code with a debugger and see whats going on there. All overwriting functions (wipeFileWith...) stop only when they receive an error from the WriteFile API, or the variable uLength reaches zero.
I have uploaded a new install based upon my current code base.

1. Uninstall whatever versions you have
2. Install this version
3. Reboot.

In addition:
Run chkdsk /f on all drives
Reinstall the latest service pack
I would suggest you run windows update and get the latest patches.

I have tested this in the following way:

3 machines
A – NT4.0 SP6 B-Win2kProf SP3 C WinXP Prof SP1

1. Mozilla
Installed latest mozilla 1.3b
Ran Mozilla.
In explorer right clicked on history.dat and attempted to erase.
In XP eraser reported file in use and failed gracefully.
In Win2k reported file in use and failed gracefully.
NT File in use and failed gracefully.

2. index.dat
Same effect; all failed gracefully

I think this problem could be related to out of date dll’s conflicting. By shutting down as many apps as possible you might be able to isolate the problem to one.

Also try searching for duplicate dlls in the directories of any running apps.

I am going to investigate possible issues with the writefile api as Sami suggested.


Thank you both for investigating this :-D
I uninstalled my existing Eraser and then installed the new build but the problem recurred.
Here are more details of my setup:
My system is Win2kSP3 and was installed from an i386 folder into which I had slipstreamed SP3 already. All Microsoft patches are up to date. Yesterday I booted to recovery console did a CHKDSK /P on all drives before booting to Windows. Then at the end of the day I shut down all apps, including things in the system tray, killed some things from TaskManager and stopped some Services that had not come with Windows. Then I ran Eraser but it still failed on one of the usual trigger files. Two of the commonest folders to cause this for me are:
Documents And Settings\%Username%Application DataMicrosoftAddress Book*.*
Documents And Settings\%Username%Local SettingsApplication DataMicrosoftWinNTNTBackupcatalogs*.*

There have been occasions when Ive wiped these manually on successive days and theyve been fine and so Ive added them back into the On-Demand list only for the problem to reoccur.

My next step is to try v5.3 as Sami suggested.

Best wishes,

quote:Originally posted by admin
I have uploaded a new install based upon my current code base.What changes did you make?
quote:In explorer right clicked on history.dat and attempted to erase. In XP eraser reported file in use and failed gracefully.I dont think Eraser has ever had problems with locked files, and it seems unlikely that this problem has anything to do with them. After all, when the CreateFile API fails, Eraser logs the problem and moves on to the next file.