Skip to main content

Verify Archive always fails on Win7x64

Thread needs solution

I've been using various versions of Acronis True Image for years, and I've been very happy with the product until just recently. I purchased Acronis True Image Home 2010 for a customer and installed it on his computer. It's a fresh installation of Windows 7 Professional x64, on a Dell Optiplex 980 with an i5 processor and 8G RAM. As a normal part of my installation procedure, I installed True Image, and performed a backup right after installation of the OS and all current updates. I stored the archive on an external 1TB USB drive, as I usually do for my customers. I proceeded to install more software, and ended up having a problem with a particular package and felt the need to go back to the freshly loaded OS and start over. I had installed the latest build 7046, and created a bootable CD. When I went to restore, it said that my archive was corrupted and wouldn't restore it at all. Since I had created the archive with the bootable CD (as I usually do), and I had read that there might be problems with the drivers for the bootable CD not being the same as the Windows drivers for the machine, I reinstalled everything from scratch again and backed up from within True Image in Windows. A verify of that archive shows it as corrupted as well. I can browse through both archives without any trouble, but can't restore either one. What further information can I provide to resolve this issue?

0 Users found this helpful

The corrupt message really means: TI can't read the archive into RAM and recalculate the 4000 checksums/GB such that every one matches the one stored with the archive when it was created. Only 1 bad checksum will cause it to be declared corrupt. Browsing and restoring various files and folders may work because it appears TI only verifys those checksums that pertain to the data being restored in such a situation.

So anything that can cause this to happen is a possible cause. A poor driver, a bad USB port, bad RAM, bad area on the disk holding the archive and as one person found out, a bad CPU.

Various things to try, start with the ones that you think are easiest to do:

Since you can't validate either in Windows or with the CD (Linux) version and you can create the archive with the CD it is unlikely it is a driver issue.

Create the archive on an internal HD. TI will, space permitting, create an archive on the partition being imaged if you don't have a second partition or physical internal drive. It will protest but it does work but it is useless for a restore. See if such an archive will validate. Internal HDs tend to be less problematic than other storage media. It this works then it puts more focus on the USB drive/interface.

Can you validate the archive on another machine? The validation does not rely on the original data being present for a bit-for-bit comparison so you can validate it on any machine.

Check the RAM with Memtest86+ free from www.memtest.org . It is a good idea to let it run overnight if errors don't pop up immediately. Don't assume because you don't observe other problems that the RAM is OK. TI seems to uncover many marginal RAM issues. While the test is very good especially if allowed to run overnight it still isn't total real-world with concurrent disk accesses etc. Try other RAM or remove half the RAM and try it, then the other half. The RAM should not have aggressive timings and the system as a whole should not be overclocked.

Run chkdsk X: /r on the partition storing the archive. Replace the X with the drive letter of the partition being tested.

Check the power supply voltages.

Hi,

I let Memtest86+ v 1.70 run, and the memory check through passes overnight and produced no errors. I bought another copy of TrueImage 2010 home and installed in on a different machine, and ran the validation on one of the images I created on the external USB drive (the PC was running XP SP3 32 bit), and that image was marked as corrupt as well. I created an image on an internal SATA drive, and it was marked as corrupt. Chkdsk runs on the all the drives I've used and shows no errors. The target system is not overclocked, and the machine is new. I can reproduce the error on multiple identical machines (Dell Optiplex 980). The 5V and 12V supplies read 5.0 V and 12.0 V respectively. I'm running out of things to check, and I've already put days into trying to solve this problem. All of the suggestions were good, and I appreciate them, and look forward to more troubleshooting help.

Thanks,

Jim Walters

The current version of Memtest86+ is 4.1 and it adds support for the i5 processor among other things. However, I doubt this is the problem if you are having trouble on every Optiplex 980 machine. Given that, I think you should contact Acronis via the Chat facility; it does sound like there may be an issue with the model and TI.

In the interest of finding out where the problems lie, I installed a couple of fresh HDDs in the test machine, installed a fresh copy of Win7 32 bit, ran updates, and installed acronis TrueImage 2010 Home. First time imaging the machine, it worked fine and verified correctly. Perhaps it is an issue with the 64 bit version of the drivers? Does anyone have known success with the 64 bit version running?

Thanks!

What doesn't make sense to me is that you said you created an image with the CD and it didn't work.
If the CD Linux version is running all Windows is out of the picture and TI is dealing with a regular NTFS disk that is static.

Did you validate the sucessful image with the CD version or just the Windows version?

Imaging issues when running under Windows are often traceable to the Snapapi module which handles the "live imageing" but it is not used when running from the CD. There may be an update for Snapapi if you think it is the problem.

Hi,

Normally, when I build a system, I install Acronis True Image on it and create a bootable CD. I then use the bootable CD to create a backup image to an external hard drive (that I keep) so that I can put everything back to the way I gave it to a customer. I give them the computer and the bootable CD, and tell them to make a backup after they have made their customizations. This computer came back after just a couple of days, and the customer wanted it put back the way I had given it to him because he installed some software incorrectly and couldn't get it to re-install with the proper options (it was always re-using the incorrect options he selected the first time). I tried to do the restore, and Acronis (from the customers bootable CD that I had made for him) said that the archive was corrupted. I was bummed, but that's life sometimes, right? I rebuilt the machine from scratch, installed True Image, and ran a backup from inside of Windows (because I had read in the forums that there were sometimes driver issues with the Linux based CD image with newer hardware). I ran a verify on that archive, and it claimed that it was corrupted too. I've verified other archives on that drive that were created with other computers and they verify OK, and I tried verifying the images marked corrupt on other computers and they don't verify OK on other hardware. Now that I have created and verified images created under the 32 bit OS, I'm beginning to suspect problems with the 64 bit version of the OS and/or program. The thing that doesn't make sense to me is why the 64 bit OS would fail to backup/restore from the CD. The OS should be out of the picture and it should just be files in an NTFS volume. Are there differences in the NTFS filesystem under a 64 bit OS?

Thanks,

Jim

Jim,

When you previously did the validations from the TI CD and they failed (on the x64 setup), were the boot-ups to the CD a cold boot (computer off/no power, power on, computer on) or were they warm boots/restarts (directly from Windows)?

Sometimes hardware will be left in a state that Linux doesn't like.

Hi,

It seems like the CD (whether cold booted from no power on or rebooted from the OS) always says archives are corrupt, even if they are not marked as corrupt by TrueImage under Windows 7 32 bit. I've stopped trying to validate archives from the CD because of that, and am only trying to validate archives from the program or the Windows shell extension (rt click, archive, validate)

Thanks,

Jim

Jim,
A couple thoughts.
1. Download the iso file from your registration page and burn the iso to create a different recovery cd. This one may produce a different result.

2. It is important that the validation be from within the Rescue CD. If you wanted to restore the system or disk, the Rescue CD is the thing to use so the validation is important.

3. There was a recent posting of a somewhat similar problem where the solution was to use a different external drive.

Hi,

I downloaded the ISO, burned it to a CD, and it fails in the same fashion as the other CD I created. I'm not using an external drive anymore, I'm backing up to a second internal SATA drive (it's faster!). I've also reloaded windows 7 32 bit and 64 bit fresh from the Dell CDs, loaded drivers, performed updates, and loaded Acronis True Image Home 2010 to two separate hard drives so that I can switch back and forth to the different versions very easily. I'm trying my restores to a third hard drive (which are all failing on 64 bit, and all succeeding on 32 bit). I'm still happy to hear further suggestions!

Thanks,

Jim

Jim,
Humour me. Pull out about half the RAM so it is 4GB or under. I can't provide a good reason why this really should matter but as long as there is one more thing to try, we aren't done.

Anything obviously different in the partitioning?

I am not aware of any NTFS differences for 64 vs 32 bits but I don't really know.

Hi,

Sorry about the long delay in replying, but I wanted to test all of the possible permutations (as well as a number of competing backup products). It seems like there were a number of factors that were making my problem seem really perplexing.

Here's what I believe I know at this point:

I had one defective Dell Optiplex 980 that would randomly blue screen every few hours. Since it happened to be one of the machines that I was creating images for the other 2 machines on, that caused some software installations with defects in them to be propagated to good hardware (which caused other anomalies and strange behavior). That defective hardware will usually create a corrupt image. We'll call that problem #1.

If a Dell Optiplex 980 with 8G of memory in it creates an image using the bootable recovery media, it will usually be marked as corrupt when a "verify archive" activity is run from either the CD or from within Windows. This happens to either 32 bit or 64 bit Windows 7 and 32 bit Windows XP. The 32 bit versions of Windows 7 and XP appear to be able to create archives with TrueImage Home 2010 installed while Windows is running, but I've only done this a couple of times. The fact that I got some good backups under 32 bit versions of Windows started me suspecting problems with 64 bit OS loads, but I now think that was a dead end. We'll call that problem #2.

If a Dell Optiplex 980 with only 2G of memory in it creates an image using the bootable recovery media, it usually succeeds. I can perform backup and restore operations on a Dell Precision T3500 with either 2G or 8G of memory, and this always seems to succeed. This leads me to believe that there is a problem with large amounts (>4G perhaps) of memory in the Optiplex 980 machines. I can repeat this problem on multiple identical machines. We'll call that problem #3.

At this point, I'm having trouble with one of the Optiplex 980 machines blue screening about once a day (not the defective one that blue screens every couple of hours), so I'm not all that confident in the brand new hardware that I've installed. We'll call that problem #4.

So, I'm getting ready to replace all of the Optiplex 980 systems with Precision T3500 systems and see if that fixes things. I'm not looking at this as a TrueImage specific problem anymore (although I still have several other systems on my bench that I can't get to restore properly or boot with TI, a Dell Vostro 1015 among them), so that's a good thing for Acronis.

I really appreciate all the help from everyone here to help me narrow down the problem. I was really at my wits end, and don't know how I would have done it alone!

Thanks,

Jim Walters