Can Eraser 6.0.8.2273 create crash reports?

phkhgh

Member
In Vista x64, Eraser 6.0.8.2273 sometimes crashes on context menu erasing (not scheduled task, where err log might be useful). I noted it sometimes crashes when selecting several files at once to erase by selecting the files in Explorer, the R click > Erase. No explanation other than Eraser has stopped working. I see no dump files for this ver of Eraser, as in v6.2.x

Was running Eraser in user mode & erasing files in the same user acct as Eraser was started from (files in app data\local\temp folder).
After restarting Eraser, if chose only 1 or 2 files from same folder, it erased w/o crashing. There's definitely no shortage of RAM or CPU power on my machine.

Other erasing prgms I tried don't seem to crash when selecting multiple files like this.

Any ideas? Thanks.
 
phkhgh said:
In Vista x64, Eraser 6.0.8.2273 sometimes crashes on context menu erasing (not scheduled task, where err log might be useful). I noted it sometimes crashes when selecting several files at once to erase by selecting the files in Explorer, the R click > Erase. No explanation other than Eraser has stopped working. I see no dump files for this ver of Eraser, as in v6.2.x
What crashes? The Eraser that is running in the background, the Eraser that cannot be seen (that is, a second copy of Eraser, the copy in the background continues running), or Explorer?

phkhgh said:
Was running Eraser in user mode & erasing files in the same user acct as Eraser was started from (files in app data\local\temp folder).
After restarting Eraser, if chose only 1 or 2 files from same folder, it erased w/o crashing. There's definitely no shortage of RAM or CPU power on my machine.

Other erasing prgms I tried don't seem to crash when selecting multiple files like this.
What files are those? Is the force locked files to be erased feature enabled?

And the BlackBox DLL which does the crash reporting is only shipped with 6.2
 
Joel said:
What crashes?
Joel...
In Vista x64, Eraser 6.0.8.2273 sometimes crashes on context menu erasing
The entire Eraser program crashes. Generic pop up Error msg - same as when any prgm in Vista stops working, "(Eraser) has stopped responding." Then gives options, "look for solution on internet & close prgm. 2) Wait for prgm to start responding, 3) Close prgm now."
Everything in Eraser is locked up & must be closed via the pop up err screen, or close process in task mgr. There's only one eraser process running.

When the option to "close prgm now" is used from the "Eraser has stopped responding" pop up msg, the Eraser process in task mgr is also closed.

??? "2nd copy of Eraser"??? Not sure what you mean by that, but only one instance of Eraser is running - shown in task mgr.
What files are those?
files in app data\local\temp folder. Temp files.
Is the force locked files to be erased feature enabled?
Yes, but don't think it matters, because:
After restarting Eraser, if chose only 1 or 2 files - at a time from same folder, it erased the exact same files in same folder, that caused Eraser to crash 2 min earlier, when selecting ALL files in the folder (15 - 20). The state of locked / unlocked files was the same, when I tried to erase all files in the temp folder (& Eraser crashed) or a few at a time - a couple min later, & Eraser successfully erased them.

If "force locked files to be erased" was enabled, that shouldn't make a diff in Eraser crashing when choosing multiple files (~ 15 - 20), or not crashing when selecting 2 -5 files. Eraser shouldn't crash in either instance. If it can't erase a file, don't see a reason (other than a bug) for prgm to crash, rather than give an err msg or err log.

Thanks.
 
phkhgh said:
The entire Eraser program crashes. Generic pop up Error msg - same as when any prgm in Vista stops working, "(Eraser) has stopped responding." Then gives options, "look for solution on internet & close prgm. 2) Wait for prgm to start responding, 3) Close prgm now."
Everything in Eraser is locked up & must be closed via the pop up err screen, or close process in task mgr. There's only one eraser process running.
There are two, really. If you use process monitor, using any option in the context menu triggers a second Eraser instance to start (that the user will not see under normal circumstances). The only real way to determine is to check the list of processes in Task Manager.

It is also possible that the second instance did its job and exited normally; the copy of Eraser running in the background crashed. This sounds more like that's the case since you can only see one copy of Eraser running, and after clicking close no copies remain.

phkhgh said:
What files are those?
files in app data\local\temp folder. Temp files.
Is the force locked files to be erased feature enabled?
Yes, but don't think it matters, because:
After restarting Eraser, if chose only 1 or 2 files - at a time from same folder, it erased the exact same files in same folder, that caused Eraser to crash 2 min earlier, when selecting ALL files in the folder (15 - 20). The state of locked / unlocked files was the same, when I tried to erase all files in the temp folder (& Eraser crashed) or a few at a time - a couple min later, & Eraser successfully erased them.
Okay, that sounds like you've done your homework :p

phkhgh said:
If "force locked files to be erased" was enabled, that shouldn't make a diff in Eraser crashing when choosing multiple files (~ 15 - 20), or not crashing when selecting 2 -5 files. Eraser shouldn't crash in either instance. If it can't erase a file, don't see a reason (other than a bug) for prgm to crash, rather than give an err msg or err log.
Yes, that is most peculiar. The erasure code should not allow any exceptions to bring down the process. This hints that the exception is being raised outside the erasure code.

I took my own Temp folder, hooked up the latest Eraser nightly for 6.0 (no significant changes, just bugfixes) and did the same. Eraser does crash, but that does seem to be more of a quirk in the file unlock code than the Eraser code per se. Try disabling the force unlock files to be erased feature and see if that allows the files to be erased.

I did make some changes to the code elsewhere to improve stability, I need to run through that few hundred lines of code again.
 
Okay, I did quite a few tests:

Test #1: to exclude that it is the number of files causing the problem, I created a folder with 190 files inside them. Control-A, right-click, Erase. Eraser erased all of them fine.
Test #2: to exclude that it is the unlock code causing the problem, I erased a PDF and Word document which was open. Eraser did not manage to unlock the file BUT it did not crash (and reported correctly that it was not able to close the file)
Test #3: to exclude that it is only temp files: I erased the stuff in my Temp folder. Most files went, but some files were in use and could not be erased. The first time I did this, it did crash (in my previous post), but the crash evaded the debugger and did not show any error messages (!!) so the crash does seem to be in a very low-level part of the code. The only code generating this behaviour, AFAIK, is the Unlocker code.

So I'm in a catch 22 now. Yay.
 
Thanks. You added another about testing while I was writing this. BTW, why doesn't this forum have posts numbered in a corner, so they can be referred to ("in post 3, he said")?
At beginning of your next to last comment, you seem to be thinking out loud. I often do. Users (I) could monitor each of the 2 eraser processes, but that's not something avg users would do or be expected to.
It is also possible that the second instance did its job and exited normally
This is important to a developer or someone w/ access to & knowledge of the code, but to avg users, if it crashes, it crashes.

I find much more often now w/ v6 stable & v 6 nightlies than in most of v5x's, when Eraser encounters something it doesn't know how to handle or doesn't like, it locks up & must be manually closed. That was pretty rare for me in v5.x.
Try disabling the force unlock files to be erased feature and see if that allows the files to be erased.
I will, but it seems like I've had to flip flop between enabling / disabling "force locked files to be erased" for a long time. Is the code to unlock files written by Eraser developers? I can't say I've NEVER used a prgm that claimed to be able to unlock files & not once failed (especially non system), but it's pretty rare & didn't cause crashes. It's a neat feature if works, but in Eraser's case, seems to be a sticking point that regularly causes problems. If it doesn't work fairly consistently (lots of posts about it), maybe take it out until it does work.

Looking back now over many months of testing nightlies, I can see how many, many crashes could have been caused by probs w/ file unlocking. Either when 1 or 1 of 10 files selected was locked (& I didn't realize it), Eraser would crash. Maybe make it disabled by default & a note in UI that it's still a beta feature.

I haven't tested dozens of wiping prgms & definitely not being disrespectful, but haven't encountered many probs w/ prgms like CCleaner, File Shredder. They don't have the other features Eraser does, of course. But it appears if they encounter locked files they can't erase, either schedule them to be erased at restart or just report unable to erase them - but not cause a prgm crash. Maybe.... part of the reason is they don't try to unlock files. Really don't know - guess I could do a little testing.

You mentioned being in a catch 22 (do users < 40 know where that phrase came from?). Why is that? I may have given you the info so you, Joel - lord of the coders - single handedly may have found the source of a problem that's irritated users for a long time. What is the catch 22 part?
 
phkhgh said:
Thanks. You added another about testing while I was writing this. BTW, why doesn't this forum have posts numbered in a corner, so they can be referred to ("in post 3, he said")?
phpBB doesn't have this feature, apparently. I guess people will have to count (gah!)
phkhgh said:
At beginning of your next to last comment, you seem to be thinking out loud. I often do. Users (I) could monitor each of the 2 eraser processes, but that's not something avg users would do or be expected to.
Yes, that design is deliberate; hence I wasn't too surprised when you thought I was kidding when I said which Eraser process crashed.

phkhgh said:
It is also possible that the second instance did its job and exited normally
This is important to a developer or someone w/ access to & knowledge of the code, but to avg users, if it crashes, it crashes.
Indeed! Hence I pointed it out. As you mentioned, it isn't an intuitive behaviour for programs, especially when it's hidden. The alternative (that is, to let users be aware of it) would only cause more confusion.

phkhgh said:
I find much more often now w/ v6 stable & v 6 nightlies than in most of v5x's, when Eraser encounters something it doesn't know how to handle or doesn't like, it locks up & must be manually closed. That was pretty rare for me in v5.x.
Try disabling the force unlock files to be erased feature and see if that allows the files to be erased.
I will, but it seems like I've had to flip flop between enabling / disabling "force locked files to be erased" for a long time. Is the code to unlock files written by Eraser developers? I can't say I've NEVER used a prgm that claimed to be able to unlock files & not once failed (especially non system), but it's pretty rare & didn't cause crashes. It's a neat feature if works, but in Eraser's case, seems to be a sticking point that regularly causes problems. If it doesn't work fairly consistently (lots of posts about it), maybe take it out until it does work.
I wrote the code with some inspiration from a Sysinternals forum post. Their main idea was to call into the Windows NT native API, access handle information, and close them as necessary. It worked on my system and its particular configuration almost all the time, and has never once crashed (until this morning -- though I do not know what crashed since no messages were given to me, the Eraser process just disappeared.)

In short, I just short-circuited Windows. Is there any risk? Yes, most programs where the handle was expected to be open will crash or error out, but that's the point isn't it? Eraser may crash doing so, but internally that didn't happen to me before. The most delicate part of the unlock code is mapping numbers to filenames, but even then it has got fallback mechanisms which should prevent a crash.

phkhgh said:
Looking back now over many months of testing nightlies, I can see how many, many crashes could have been caused by probs w/ file unlocking. Either when 1 or 1 of 10 files selected was locked (& I didn't realize it), Eraser would crash. Maybe make it disabled by default & a note in UI that it's still a beta feature.

I haven't tested dozens of wiping prgms & definitely not being disrespectful, but haven't encountered many probs w/ prgms like CCleaner, File Shredder. They don't have the other features Eraser does, of course. But it appears if they encounter locked files they can't erase, either schedule them to be erased at restart or just report unable to erase them - but not cause a prgm crash. Maybe.... part of the reason is they don't try to unlock files. Really don't know - guess I could do a little testing.
Indeed, features bring bugs. A one-liner program cannot crash. But one-liner programs do not do anything useful. I guess I'm being rather ambitious here... which I do hope is for the good of the community.

I would need more information to be able to accurately diagnose crashes - the Unlocker code is written in C++ (not the managed C# the rest of the program is written in: C++ is a more machine-like language and was not designed to be a first-class .NET language) and for that to happen I would need a memory minidump (thank goodness those are only about 300kb) but to collect one would require lots of intervention on the part of the user and probably guided help over a more real-time communication tool (IM, or voice conversation)

BlackBox in 6.2 should be able to collect such crashes, but I do not think the BlackBox crash trapping code will trip when the crash is below the .NET framework (like I said, Unlocker is written at a level lower than .NET)

phkhgh said:
You mentioned being in a catch 22 (do users < 40 know where that phrase came from?). Why is that? I may have given you the info so you, Joel - lord of the coders - single handedly may have found the source of a problem that's irritated users for a long time. What is the catch 22 part?
Unless I can get Eraser to crash consistently, I have to dismiss this as "it works for me." Removing it would cause complaints from users where the feature does work, leaving it will cause complaints from users where the feature doesn't work.

I'm quite certain that the feature does work for the silent majority -- I mean, what's there to complain if the feature works, and it's not human instinct to drop by the forum and say that the feature works. Hence the number of reports of a broken Unlocker feature woul seem to be excessive relative to the number of people using it.
 
I took some screens when Eraser 6.0.8 crashed, trying to erase a locked file w/ "force locked files to be unlocked" enabled.
Per the ticket 394 comments, I'm using Vista x64 hm prem SP2. Do have True Crypt 7.1 installed, but doesn't start w/ Windows & not running when erasing files.
Use Kaspersky IS 2012 for the AV.

If I disable "force locked files to be unlocked...", Eraser does not crash, just a pop up notice the task completed w/ errors. Since this was initiated from explorer context, there's NO LOG showing what the errors are (kinda bummer).

Other shredders either did nothing - no msg, no erasing. Or, reported file was locked - close it & try again. None of the very few I tested crashed trying to erase a locked file.

Using a utility like Unlocker apparently unlocked the files, but caused a few temp files to immediately disappear. I did NOT select "delete files" in Unlocker. Something haven't encountered before. Thought was to unlock the files 1st, then try using Eraser, as a test. Maybe on other files later.
 

Attachments

  • Windows crash notice - Eraser after erasing locked file.pdf
    127 KB · Views: 81
  • 2011-10-30_150253.png
    2011-10-30_150253.png
    19.8 KB · Views: 2,323
  • task mgr screen after Eraser crash notice 2011-10-30.png
    task mgr screen after Eraser crash notice 2011-10-30.png
    12.9 KB · Views: 2,323
I'm priming my Windows Vista x64 Virtual Machine to see if I can duplicate the problem. The best thing would be for me to get the crash myself -- then I'll have all the tools to work around the problem.

The screenshot in the PDF is a standard Windows crash dialog; all I can gather from it is... .NET spluttered and died. There isn't enough info there for me to deduce anything more than that. It's probably me doing something I shouldn't (in this case, unlocking files... but ohwell) so I guess what really is the issue at hand is not that Eraser cannot unlock the file (it very well may not be possible to do so) but rather how can we quit gracefully.

As I said, I have a test build which you may want to try. It's got some stuff re-written though the core logic is the same. If you want it, reply to my PM with some means to send it to you.
 
Ok I did something really unorthodox, and I think I hit it. I ran Eraser as an administrator and tried to use the running Eraser to erase itself, and Eraser promptly crashed. This only happened with Vista with Kaspersky IS 2012. On 7 with Symantec Endpoint Protection Eraser says that it's currently locked and refuses to unlock it.

I'm not sure if it's a Vista or Kaspersky thing though, next up: finding out.
 
It's a Vista thing; even without Kaspersky it's happening. I'll have to hook up the process to a debugger and figure out what's blowing up.
 
Okay, I think I found the bug. It's rather obscure because it's at the glue between .NET and native code, and it's caused by a (false) assumption in my code that seems only to manifest on Vista 64 (didn't test x86). I'm working on a fix.
 
I've tested the fix, and it seems to work. I'll drop a binary by you soon.
 
I've committed a fix in r2341 and r2342. Builds after those revisions (see the final number in versions) should have the fix.

Did you manage to test the binaries I sent you?
 
Back
Top