I've been running Ghost 15 since March of this year without incident. Recently I found the following in the log:
8/30/2010 5:00:36 AM High Priority Error: Error EC8F17B7: Cannot create recovery points for job: sysImage. Error EC8F040B: Cannot create incremental recovery point of C:\ drive. Error E0BB0083: Unable to create incremental recovery point. Error EBAB0013: A test that safeguards the integrity of the program failed unexpectedly.
I immediately reran the backup, and it completed successfully.
Searching these forums and Symantec Connect I see that variations of this error have been reported from time to time on several releases of Ghost. None of the particulars and none of the solutions appear to apply to this case, however (note the details in the log entry). There's about 250GB available on the 1TB backup disk, and CHKDSK and other utilities indicate no disk problems, nor are any logged in the system (Win 7) logs. No USB devices were connected at the time, nor was any other backup program active. Can anyone shed any light on this?
Do you see an entry around when that second backup you started completed? If no, then you're good. A good rule of thumb on a destination is to try to have 30-40% free as a just in case. You said you tried several solutions, but it didn't work. Did you see a fresh error? One thing to check, is if you don't see an actual error it could have prevented an incremental and created a new base.
The retry, as I said in the original post, went without exception (no log entries other than those for the start and successful completion). Only the incremental backup (as specified) was created. The error has not repeated since that one instance. My comment that none of the cases and solutions mentioned in other reports of this error appeared to apply to this case meant just that: either the details in the log entry differed or the solutions didn't apply, e.g. a "solution" to remove any USB devices didn't apply because there were none connected. As to leaving 30-40% of a terabyte drive free (I had ONLY 25% or 250GB free)... if that's what Ghost requires then I'll switch to different backup solution. But I can't believe that's the case since subsequently both base and incremental backups (including auto-removal of backups beyond the maximum specified to be retained) have gone without incident, though there's now only 230GB of free space left on the backup drive.
To repeat my question, from the log entry provided in my original post, can you shed any light on what caused this error? Or is EBAB0013 just a catch-all code for otherwise unclassified exceptions? The lack of definitive answers to previous posts about this error going back through several generations of Ghost, along with your response, lead me to that conclusion. I'm very nervous about relying a program that throws random exceptions for unknown reasons, even if they occur only rarely!
The 30-40% rule of thumb isn't a requirement. When you have a problem writing to a drive that may be fragmented, having enough space to get around any fragmentation and/or bad blocks can be helped by freeing up space. That said, since no further error occurred, then you're good.
As to your question about EBAB0013, the answer is yes. It is a generic message. With Ghost, errors are structured in the following way:
General task that failed (failed to create backup in this case)
Specific Task/Primary Failure
Primary/Secondary Failure
Secondary/Tertiary Failure
The second and third failures are listed when appropriate. Troubleshooting off the task failure means the number of causes is very large. When you have the other details you can narrow down what is going on. Since the error occurred only once in your case, it was likely due to something else running on the system at the time Ghost attempted to create an image that hasn't occurred again. Without debug logs I can't really say what. At this point though the logs will likely have been flushed since this occurred so there's nothing to really debug at this point.
Humm... could be interaction with something Win 7 runs automatically, I suppose. The error occured overnight when no one is on the system and the remote network connection is disabled. I've got everything I can schedule (e.g. malware scans, disk defragmentation) set up to run at times other than when a backup is scheduled. Anything you've run into previously that I should look at?
I gather the "details" in the log entry I provided are not sufficient to provide any further clues. Do I have to enable some sort of "debug mode" in order to cause Ghost to keep a debug log? If so, then doing so for something this intermittent is obviously not practical. If not, then for future reference, is there somewhere I can find instructions on how to package up a debug log entry? If there is, I'll do so next time this (or any) error occurs, and save it for analysis by Norton tech support, if requested.