The logs that are looked at are generated on each action failure. The only thing you could potentially clear would be the windows event logs, but that shouldn't be necessary.
1 Like
These logs, at least the ones that I looked at before zipping them up, went back at least a month. What if I delete everything in the support folder???
As long as you don't delete any of the utilities (SEAST, partinfo, SMEDump, etc).
2 Likes
The utilities themselves are in a different folder. I’m going to rename that folder, creat a new one there called support, run the backup again, and then the utilities. I’ll zip it all up. whom should I email the zip to?
Send it to Tony again.
Will do… thanks Erik…
Tony_Weiss wrote:Hi Tom,
I've sent you an email with log creation information and an upload location. Please let me know if you are able to get the logs to us, and when you have uploaded them. Thanks!
Tony,
I have uploaded the logs as instructed from my laptop, one of my failing Ghost 12 client computers running Windows XP SP3.
Tom
HI!
I, too have the same issue.
"Error ED800012: The internal structure of the image file (CRC Check) is invalid, damaged or unsupported."
Ghost 12:
Version: 12.0.5.29804
Build: 2008-11-12 15:59
LifeUpdate claims that this is the latest.
win XP SP3, latest updates as of today.
Drives a mixture of 2 SATA direct attachted drives connected to aSi3112r internal Adapter of my (old) ASUS A7N8X-E
two ATA drives (SW RAID0) and one external USB2/SATAII attached drive as a backup location.
I had been thinking that my drive might cause this, but reading the many reports of people having the same issue makes me wonder.
I was a little irritated, that I was not able to recover the backup (that I had created w/o verify) booting the ghost 12 CD. It basically stopped everytime in the middle of a restore leaving me no option to restore an image with errors.
I was finally able to get a new drive up and running by copying the partitions within windows ignoring source CRC errors. (and running checkdisk on the target/replacement drive)
I would expect the windows system log to show real IO errors as well, but with my new replacement drive I still get the ED800012 and no error in the windows logs)
Having a SW that can not create and restore backup reliably somewhat defeats the pupose.
Is there a way to increase verbosity of the debug information to get a better understanding for the root cause, or do you understand the issue and will provide a fix soon?
Thanks - Frank
Erik... any news on the second set of clean logs I sent Tony to give to you?
BTW, it seems XP-SP3 is a big common denominator here...
Message Edited by ShadowAndMax on 02-11-2009 05:01 PM
I haven't heard anything yet. We're trying to collect more logs so we can have a better understanding of the situation, so for anyone on this thread who is still encountering this error we need logs. There are two use cases though in order for us to filter/bucket the logs correctly.
The first is where an image fails verification after it is created. For this, we may need images, but potentially access to the machine as well.
The second is where the image creation succeeds, passes verification, but the error occurs when trying to restore the image. For this we need logs using the SEAST tool, and these need to be after the image that you are trying to restore was created (when in doubt, create a new image, collect the logs, try the restore and if the error occurs those are the logs we need).
http://www.symantec.com/norton/support/kb/web_view.jsp?wv_type=public_web&docurl=20090105115607EN
To clarify Shadow, were you in the second use case?
Message Edited by erik_carlstrom on 02-12-2009 08:49 AM
Hi Erik...
Thanks for the fast reply.
Well, yes and No, I'm PRIMARILY in the first. HOWEVER, when it fails verification, it doesn't leave the image it created but instead, erases it from the backup destination. So there's no image to send...
If you need access, I'd be more than happy to do it. I've done it quite a bit lately anyhow, so it's not an issue... You can even use pcAnywhere ;)!
For what it's worth, S&R looks at images created eariler and fails to validate SOME of them.
Enis
Message Edited by ShadowAndMax on 02-12-2009 10:02 AM
I'll let our engineers know. Tony may be contacting you to try and get contact information from you.
Tony’s got everything…
tschmidt wrote:
Tony_Weiss wrote:Hi Tom,
I've sent you an email with log creation information and an upload location. Please let me know if you are able to get the logs to us, and when you have uploaded them. Thanks!
Tony,
I have uploaded the logs as instructed from my laptop, one of my failing Ghost 12 client computers running Windows XP SP3.
Tom
Tony,
I have uploaded a second set of logs as instructed, this time from my desktop running Windows Vista. It is also randomly getting the CRC errors when verifying the backup after it completes the backup to my network drive attached to a Windows XP SP3 desktop. Once the verification fails, it of course deletes the backup image.
Tom
Hi Erik:
I had to do some things with my machine with Tim_L, and lost my networking. While I was trying to figure it all out, I flushed another hard drive, and started with Win XP-SP2 clean, only with it's updates, and Ghost 14.
I wanted to back up the old drive before screwing with it. So, Clean XP install, only "extra" software was Ghost 14.
Went all through the backup, then validated, and coughed up the same error. I have those longs on the new drive.
More details on my overall setup. I have 3 computers, of which 2 are running XP Home SP3 (1 desktop, 1 laptop) and 1 desktop with Vista. All 3 are licensed with Ghost 12. The XP desktop has an external USB drive (500GB Maxtor) that is my backup destination for Ghost for all 3 computers.
I have never had CRC errors when the XP desktop backs up with Ghost to its USB attached drive. But I get the CRC errors on validation from the network attached computers. Both network attached computers have the destination drive mounted on Z:\ My home network is Gigabit for the 2 desktops, and 100 Mb/s for the laptop using CAT-6 cabling and a Linksys WRT310N router. I am confident that I don't have network issues, as I previously had a Trendnet router and 100 Mb/s NICs on the desktops, but upgraded it all a couple months ago to Gigabit, including replacing the cabling. And I had the CRC errors before on the 100 Mb/s Trendnet router setup as well, so replacing my network hardware did not fix the issue.
I have also run CHKDSK /F /R on the USB drive and it has not found any errors, and reruns of Ghost to it from the network still give the CRC errors on validation. If a corrupt hard drive was at fault, then the local backup of my XP desktop to the locally attached USB drive would also fail with CRC errors, yet I have never had a validation failure when backing it up locally. The CRC errors only occur when backing up to a network drive.
I have also tried an evaluation version of Ghost 14 with the same CRC errors, so later versions still have this same bug.
I have been considering purchasing a network attached disk, such as a Buffalo Linkstation or a D-Link DNS-323 for my backup disk, where these systems use a Linux filesystem. But I am afraid that Ghost may once again give CRC errors for a NAS device like these.
Like I have stated before in an earlier thread here, I have also tried using a competitors product, and it backed up and verified across the network without error, proving that I don't have any hardware or network issues. I am extremely disappointed in Ghost's CRC failures, and unfortunately too much time has gone by waiting for a fix for this that it is too late to return the software for a refund so that I can purchase a competitor product to perform my backups reliably.
How much longer must the Symantec Norton Ghost and Save and Restore customers wait for a fix for this ongoing issue? This bug has existed for years, and through several versions of your software!
Tom
My problem is along the same lines, though I suspect the situation is much more grim.
I have 4 backups from years ago on Ghost 9.0. A few days ago, I realized I needed a file from theree of these backups. It's on all three, so getting any one of them to work would be sufficient. I am currently using the 30-day trial of Ghost 12.0, because I read somewhere that it was the last version to support files from 9.0. On all but one backup file, I'm getting Error ED800012. Of course it would happen to be the fourth backup, the one without my file, that would be the one to succeed.
Personally, I'm apt to blame it on the filesystem. The working backup is just a "Clean install" image, with my most commonly used installed programs. The other three are fully loaded with data, and thus weigh in at gigabytes more of data. At this point, I don't really care if the backup is fully functional. As of right now there exists no way to skip the CRC and just access whatever raw data is accessible? I understand that some of the data would likely be corrupt, but that doesn't mean it all is.
-Netrilix
P.S. I can't be the only one who finds "CRC Check" to be quite amusing. When you expand out the acronym, it comes out as "Cyclic Redundancy Check Check". Poetically redundant. 
I thought this was strictly related to Service Pack 3 for XP, but since I was able to reproduce it on a machine with only XP-SP2 and it's updates, and Norton Ghost 14, this has to be an error in the app, not the file system.
BTW, on that CRC acronym, maybe the developer was psysophrenic, and talked to himself all day long... Check? Check! lol
Message Edited by ShadowAndMax on 02-14-2009 06:18 PM
Looks like we may need to get access to the Machine. I've asked Tony to coordinate.
For the Ghost 9 item, try mounting the recovery points. Ghost 14 will still access images from Ghost 9 by the way. You can run a checkdisk through the recovery point browser to try and repair damage. Your situation is different then the other scenarios here.
What makes my situation different other than I've got BOTH S&R (NG9) and NG14?
With 14, on the drive I executed from, there was Win XP2, it's updates, and NG14. Can't be any cleaner than that.
S&R is generating the same error on a well populated disk. I would have figured that the NG14 test would be as clear as it can be... there's nothing on the drive that would interfere with Ghost's operation.
For what it's worth, I don't think there IS any damage to repair. I think it's the program that's not reading it's own files properly. The only thing that's verifying damage is the program that created the images.
Tony knows I'm willing to let you guys on my machine any time you need to do so...