Video Screencast Help

Error ED800012: The internal structure of the image file (CRC Check or Frame Header) is invalid...

Created: 02 Jul 2008 • Updated: 21 May 2010 | 22 comments
Andreas Horlacher's picture

I am gathering information about this error and trying to find similarities using this forum. If you are experiencing this error, will you please add your comment about how you are attempting to create and/or restore an image when you get this error, what you have done to troubleshoot it and/or get around the error, and if you have solved the problem, what the solution is.


Any data you provide will be invaluable in determining the nature of this error.

Comments 22 CommentsJump to latest comment

AJJCPA's picture

BESR 8 Desktop - We concluded that the verify option in job setup caused disk backup to fail.  To reach that conclusion, we tried other combinations that succeeded.  Individual file backups and full disk backup with no verify were successful.

Periwinkle's picture

We use BESR to make base backup sets daily to a network share on a USB drive.  The destination works for our backup sets created with LiveState version 6 and some of our BESR version 8 servers, but it does not work with our 2 Windows 2000 servers running BESR 8 and database/mail servers. One runs Exchange 2000 server the other SQL 2000 server.  I can confirm problems with these servers using the verify option, but I do not know if it is due to a bug in the verify option or an actual failure to make a clean image of these servers. It could be due to a compatibility problem with BESR and the database software or .NET on Windows 2000. Both of these serves also have IIS installed, their hosting websites( an intranet and OWA) and Microsoft IIS http scrubbing security tool.



Phil@Fuji's picture

Hi Andreas,

Thanks for contacting me re this problem.

I had given up on it.  It started in BESR 7 and I had hoped that BESR 8 would fix it, but it didn't.

My scenario - I use BESR 6.5, 7 and 8 on 6 different servers.  It works perfectly on all but one server, which has BESR 8 on it.  The troublesome server has a MegaRAID adapter, with 1 logical drive (70 GB).  The server runs Windows 2000 Server SP4, and has 2GB memory.  There is a C: drive (5GB) for the OS and Program_Files etc, and a D: drive (65GB) for data.  This server runs MS SQL Server 2000 - the executables and the data are on the D: drive.

I can create a BESR job to back up the C: drive with no problems, and I do this every night - a FULL backup every Friday night, and an INCREMENTAL backup every other night.  Works 100% of the time.

But if I add the D: drive to the job, or create a new job that just backs up the D: drive, it (almost) always aborts at the end of the job, with the error message -  

"The Internal structure of the image file (CRC Check) is invalid, damaged or unsupported"

I do NOT use the Verify option.

I suspected that SQL Server might be causing the problem, so I stopped the SQL Svr services, and tried the backup then, but it still fell over with the same error message.

Strangely enough, it WILL work OK occasionally - I have only ever had a successul BESR backup of the D: drive of this server twice (out of several hundred attempts).  I don't know why it worked these 2 times.

I use the same techniques and job options as I use on my other servers, some of which have similar hardware, OS, drive set up, and even SQL Server 2000.  All other servers work flawlessly.

I had given up on this troublesome server, and decided that it must be the unusual RAID card that was cauing the problem.

I will be VERY interested to hear of any progress, or if you would like me to try any new techniques or BESR 8 patches etc.




Markus Koestler's picture

In our environment the error occurs since BESR 7, with BESR 6 and LSR 3 and 6 there wasn't this problem. We are now using BESR 7.03 on most of our servers and 8.0.2 bzw. 8.0.1 on a small number of servers. Our servers run windows 2000 SP4. The servers have a C: drive for the OS and programfiles and a D: drive for user and program data. The destination for our backups is a 1 TB Buffallo TeraStation Pro/TeraStation Pro II. We run daily incremental backups and weekly full backups. We use the verify option to check the backups after creation. One thing we managed to find out is, that when setting to option of splitting the backup files into 100MB,250MB chunks the failure rate increases dramatically.

*** Please mark thread as solved if you consider this to have answered your question(s) ***

Yves Kleikers's picture



I use BESR 8 desktop edition (50 clients) and BESR 8 server edition (2 servers) in a Microsoft Domain (Active Directory) environment. I have never used the verify option with BESR 7 before so I don't know if the issue would have happened with v. 7.


Anyway, with BESR 8 (8.0.1 and 8.0.2) I started using the verify option at the end of a backup job. Following will happen :

- Backup job with verify option > backup location = network share > standard compression > Error ED800012, image file not created.

- Backup job without verify option > backup location = network share > standard compression > No Error ED800012, image file created ... but if I run a manual verify later (with the recovery point browser) the error will appear. So the created image is invalid anyway.

- Backup job with verify option > backup location = local > standard compression> NO Error ED800012, image file created > manual verify later = OK.

- Backup job with verify option > backup location = network share > NO compression > NO Error ED800012, image file created > manual verify later = OK.


Workaround for me at this time:

Either have a local backup location or have no compression of the backup image file. Having either a network share backup location or the standard compression will result in invalid image file.


I am not sure if the verify option will cause the issue at all. Even if I create a backup image file without verify on a network share, the image file will be created successfully (apparently) but I won't be able to restore this backup image at a later point. Also a later manual "verify" will display the error message.


Symantec employee has been trying to help for 3 weeks without any result !!!






Andreas Horlacher's picture

I have a small file (20k) that contains some registry changes that modify the way we communicate over the network. Please SEND ME AN EMAIL at and allow me to send you this file and the instructions on how to use it. 

Andreas Horlacher

Please mark 'solved' when issue is resolved

Skipsargent's picture

I am experiencing the same error. I am trying to evaluate this product for use in our production environment, so I purchased a retail box copy of BESR 8 Desktop. I installed it on my workstation running XP Pro SP2. I am imaging to an internal 1TB Seagate SATAII drive. Anytime I create an initial recovery point snapshot of my entire drive and I have the verify option enabled it fails with this error. I followed your link, the primary drive and destination drives are both NTFS formatted and the compression is set to none. Any other ideas? I tried to call into to technical support, but I was told that since I bought a retail off the shelf box instead of a volume business package I was not entitled to technical phone support. I'm thinking that was the last nickle I am spending with Symantec.

Andreas Horlacher's picture

Skipsargent -  thanks for your post. First, drop me an email ( and I'll send you the download you can try. I would post the link directly here, but I'm tracking the error directly before making a general release.


Second, you are the first customer I've had this happen to when saving to a local drive that was not USB, so finding a solution is vital. Can you briefly describe your system hardware configuration? Can you try saving to a different location, such as another internal drive or a USB drive?

Andreas Horlacher

Please mark 'solved' when issue is resolved

Roxer's picture

I am having the same issue.  We take snapshots of our running VMware VMs every four hours.  We also keep the base for four weeks before deleting.  I have tried to restore one of the VMs several times using all four Bases and each one fails with the "internal structure" error.  This is part of our DR strategy where we have to certify the backups quarterly.  The backups are performed over the network to a Windows share.  The server failing the backup is a Win2K3 box with a 300GB D: drive.

mjm01010101's picture

Andreas I emailed you and no response.  Any chance you can post the files here or a link here? 

Andreas Horlacher's picture

Hmmmm. Resend me the email. Make sure it goes to I'll respond today.

Andreas Horlacher

Please mark 'solved' when issue is resolved

Andreas Horlacher's picture
Good news - the fix has built into 8.03, scheduled to be released shortly. Once released, please LiveUpdate to this build, or
Message Edited by Andreas_ on 08-13-2008 10:27 AM

Andreas Horlacher

Please mark 'solved' when issue is resolved

louis11's picture

I am in desperate need of this fix! Is it released yet? I am using version 8.02, and Liveupdate reports there are no updates. The link you gave shows only 8.02 available.


Help Please!

Andreas Horlacher's picture

Drop me an email and I may be able to upload it to your site.

andreas_horlacher (at) Symantec (dot) com 

Andreas Horlacher

Please mark 'solved' when issue is resolved

louis11's picture

Do I need to rerun the backups after updating the registry with your fix?


I'm getting this error when I try to do disaster recovery from a bootable CD. If I manually verify the backups in windows they verify OK. However, I CANNOT restore these same backups from bootable CD b/c of this error.




louis11's picture

Ok I've found what caused the error in my case. I was testing disaster recovery on different hardware, and the Intel Server I used gave me this error every single time.


I tried it on another computer and it worked. For some reason it is descriminating against the one Intel Server I tried. This is the only computer of the 4 that I've tried that could not restore the backup.



DaveT's picture


I believe this error is given for several varied reasons:

     Backing up to a mapped network drive, with or without compression, and/or backing up to a network

          share, with or without compression.

     There are a ton of variables in any given network:
          The OS/SP version on the source system,
          The OS/SP version on the target system,
          The actual speed of the LAN (100 Mbps vs Gigabit or higher)
          The speed of the actual target drives themselves (SCSI, SAS, SATA, USB, FireWire, etc),
          Whether or not more than one backup job is sending to the target drive at any given time.
          etc, etc, etc.         

Every network is it's own beast and has it's own characteristics, so you may have to experiment.

I also believe that using more than one specific version of BESR can cause this error.  For example: I use BESR to send PC backups across the LAN to a Server.  If I use BESR on the Server itself to open the images, I get the error.  This is because the version of BESR on the Server itself is older than the version on the PCs.


An important detail is the version of BESR on the SRD versus the version of BESR that was used to create the backup image in the first place.  If you upgrade BESR after the install, you should create a new SRD for the system.  I tend to create the BESR SRD .iso's at least once a month, and/or after any upgrade.  I have always presumed that I need to create BESR SRD's to match the specific version of BESR that is installed on the source machine.  Since an older version of BESR won't open an image that was created with a newer version of BESR (like trying to open the PC image files on the Server itself), I presume an older version of an SRD will not recognize the newer image version, either - therefore the Recovery SRD is worthless and the Recovery will not work.  I have not tested this, and frankly don't care; it's too easy to create the SRD's and not quibble about version changes.


These are just a few observations I've made.  As always, your mileage may vary.

Dave T.

Jacob A's picture



I will pass your thoughts on up, thank you.

valeried580's picture

Hi. After successfully using Ghost 14 for six months, I ran out of space on my external drive which I use for backing up.  I removed old recovery points to free up space. Now when I start a back up, all starts off well, but as ghost approaches 100% complete, this ED800012 error message at the end of the back up process.  This is most worrying. What do I do to rectify this situation? uninstall and reinstall ghost 14?. All help welcomed.'s picture

I use BESR and have just upgraded to this version and still have the problem talked about above.  I actually have three servers using the software, 2 are 2k3 and 1 is 2k.   The one with the problem is one of the 2k3 servers and in fact the main AD server.  It matters not whether or not I back up the system drive or the data drives.  The image finishes and fails during the verify.  And it matters not whether the verify is looped in or manual.

Each of the servers has the program installed on them, and backs up to a network share on the same network space with no funky translations or anything.  In fact the share that it backs up to in each instance goes to \\192.168.1.##\servername.  All of the server shares are on the same drive on the server with the same permissions for the share level and file level.

I need help on this - suggestions?


Bakinup's picture

There are 50 XP nodes on this leg of our network   ( lucky me)   with BESR 8.0 .2.26412 Only time I see this issue is with the  compression setting at any other than none. When this happens the verify fails intermittently. I was not sure that the backup is good so I tried the procedure of copying the file locally and from the recovery environment verify the backup. Some of them would fail locally which means the backup is NG . If it ever failed, the backup would never complete again without failure on that node no matter what compression was used. The management  was reloaded on the failed node and with compression set to none it has worked every time.

We will be going to 8.5 BESRM soon .  I hope this is resolved in this rev Being able to use compression would be nice.