How to resolve persistent VERIFICATION errors?

TI v10 build 4871.
Running on WindowsXP-home SP2.

I'm still on trial and getting worried.This is a beautifully done application, but if I can't get reliability, I can't buy it.

I did image backups of C drive, and of external drive E (USB2). With one exception, every verification attempt failed, and every error report in the log says:
Error E70020
Image corrupted, hex70020
Tag=hex82db9339b70c0c3afc
It doesn't matter whether Zone Alarm or antivirus or antipest is on or off.
It doesn't matter whether I am or I am not connected to the internet.
I do not touch the computer while it's backing up, so other than Windows, no user activity.

I have 6 days remaining in trial. Any chance someone here can help me see how to make it work?

 

Does the verification error happen as part of the backup, or when you check the image separately?

What compression level did you use?

Where did you store your backups?

Is your system overclocked?
F.

 

Thanks for answering.
1. error occurs during Verification. Separately from creating an image. Also occurs when I close and restart TI. Suppose you have a corrupted file that's now to go into an image, might that cause it? If TI would tell exactly what's corrupted we might nail this one down.
2. Normal. I've taken all defaults since I'm in learning mode.
3. On external drive (usb2) in a directory I created "AcronisImages...". The source was also external, but a different drive. The .tib images of C and the other external files are there. The contents can be seen and opened. I can't tell whether ALL files will be seen as I have gazillion of them.
4. ?? don't know what it is. Something to speed up the computer? How do I check? I never set anything of that sort.

 

I would try three things next.

1) Try to create an image on your local drive rather than on your USB drive. Not a good place to backup to in principle, but this exploring the possibility that ATI is having trouble reading (or writing to) your USB drive. Do images here verify OK.

2) Create an image on your USB drive with compression turned off. Not that likely that this is an issue unless you are using maximum compression - but there have been cases reported where compression + a RAM fault can lead to this situation.

3) What happens when you make an image from the rescue disk. Does that verify OK?

F.

 

1. OK, will do. Can I just pop it into any directory I make or make a secure zone?
2. OK
3. HOW? When I installed the trial version I made the rescue disk. CD. I gather it's bootable. If I put it into the CD/DVD drive I hope it won't start booting. So then I start TI and just run an image of it, right? Do you mean the Acronis rescue disc or the OEM recovery CD?

 

Hello act8192,

1. No need to create a Secure Zone - just image to any folder.

3. Yes, foghorne means the Acronis bootable rescue CD. If your CD/DVD drive is set as the first boot device the CD will boot into a standalone version of TI. Unfortunately, the trial version of the rescue CD cannot create images - only restore images you created whilst running TI in Windows mode.

Regards

 

My Thoughts

1. Create a directory on your C: drive. Do not use the Secure Zone for now.
3. The Rescue Disk CD should be bootable and it will not start booting by placing it in the drive.. Open the CD/DVD drive and place the Rescue disk in it. Leave the drive open and re-boot. Windows will close the drive as the system shuts down. The OEM Recovery CD is not used here.

Revised
1. I believe my statement is incorrect. True Image will most likely not permit an image to be created and stored on the same partition. I also missed the fact that you are using the trial version.

Bruce

 

Thanks Menorcaman.

I missed the fact that this was a trial so that is not going to be that helpful as a suggestion.

However, trying to validate images which were created under Windows, from the rescue disk may be of some value.

F.

 

Apologies for over doing the reply here, it seems rude not to though

Don't use the secure zone.

To boot from the rescue disk you need to configure the BIOS so that it looks to the CD before the harddisk.

F.

 

Nobody overdid the replies, but have we missed the point of this exercise because I brought in the "bootable" issue?

I thought foghorne's original idea was to use the source = Acronis recovery CD I made, and make an image of it on destination = my C drive.

I then asked if it'll boot, thinking it undesirable for this goal. What have I missed, please?

 

TI will allow an image to be created and stored on the same partition if there is enough room although it will display a warning which is then ignored. You cannot recover the partition if its image is stored on it since one of the first steps on restoring is to delete the partion (and your image!).

The trial will not create an image; that can only be done from within the time limited Windows version.

 

I think the idea was to make an image of C using the recovery CD since this runs in a Linux environment and rules out any problems with Windows application interaction. This is not a common problem.

The original issue as I see it was to create an image of C on a local drive/partition to rule out any hardware problems with the external USB drive. If you can't make and validate an image on an internal drive it is extremely unlikely you will be able to do it on an external drive or DVDs. In other words, the most successful device is an internal HD.

Do not create the Secure Zone. Create an image of C onto another partition or drive if you have it. If you don't, you can create it in a location on C if you have enough space. Ignore any warning messages. After creation then attempt the validation.

You can try it without compression but Normal compression is not known to cause problems and does reduce the size of the image considerably in most cases.

Edit: corrected drive type, should have been "internal". Thanks bvolk.

 

Hi act8192

Sorry for not being clearer.

I tried to suggest a 3 pronged attack to try to gather more evidence as to what is causing your problems. However I missed the fact that you have the trial version. I have tried to emphasise changes to my original questions in bold:

1) Try to create an image on your local drive rather than on your USB drive from your Windows True Image program, this exploring the possibility that ATI is having trouble reading (or writing to) your USB drive. Do images here verify OK.

2) Create an image on your USB drive with compression turned off from your Windows True Image program. Not that likely that this is an issue unless you are using maximum compression - but there have been cases reported where compression + a RAM fault can lead to this situation.
Does this verify OK?

3) (Revised) What happens when you boot from the rescue disk and do a verification check on the images which fail under Windows.

Any better ?
F.

 

I understood 1&2 earlier - an obvious test which I will do.
#3 is now clear, thank you very much, I'll report back.

Did you catch the fact from my 1st post that he error is always the same? Kinda weird, isn't it?

 

Well I guess it is good in that there is one consistent fault to concentrate on. It wouldn't surprise me if the error simply meant that checksum calculation of the file failed. I'm sure someone in the know can comment on that.

F.

 

That is exactly what it means and AFAIK there is no message that says where in the checking the checksum calculation failed.

For those who don't know, when TI validates and archive it does not compare the bits in the archive with the bits on the HD. This would not be possible from within Windows because a Windows C drive is always changing. It also allows an archive to be validated at any time, even months after creation, and on any machine.

So the validation process requires TI to read the file and perform a checksum calculation. At the time the archive was created, the same checksum calculation was being performed and the final value included in the archive file. If the checksum calculated when validating doesn't match the creation checksum included in the file the archive is declared corrupted.

Most checksum algorithms will give a vastly different checksum value even if only one bit is bad. So you have a file that is muli-gigabytes in size and all it takes is one bad bit to have it declared corrupt and useless! In other words your PCs hardware must be virtually perfect.

Lots of people will say they can't have a hardware problem because everything works every other time. You can have a bad RAM location and if non-critical data is loaded into it you will never realize it is there.

When TI is performing its operations it does put a heavy load on disk and memory. The CPU also comes into fray during validation and compression.

The complication is that a corrupt archive can be the failure of the TI software, bad hardware both in terms of a failure or design.

Some external USB chipsets do not handle very large files properly. If you have a marginal cable it may be fine for regular work but with a multi-giagabyte file that has to be perfect, the sheer number of bits and probability may get you.

RAM is a potential problem and one check is to use Memtest86+ available free at www.memtest.org and let it run overnight. The RAM test does not run in exactly the same environment as a TI operation so it is not totally guaranteed to catch every marginal failure.

Overclocked systems and aggressive RAM settings can cause failures when used with TI.

My hardware failure was a marginal SATA drive cable. It did make some entries in the XP Event log but other than that I didn't know there was a problem until I have validate failures with TI. A new cable fixed it up.

As you can see, trying to find the problem is a case of elimination and it can be very tricky. Problems that the TI methods may have with certain chipsets can well be another but without information from them it is very hard to pin that down.

 

Foghorne, I didn't get to #2 and #3. Perhaps no point.

I ran test 1 - Normal compression, local image of the local drive (AV/AS shutoff). Entire drive to a directory on the local machine. All USB ports disconnected, even network cable disconnected. VERIFICATION failed, image is corrupted says TI. I ran it once more, this time no compression. Same error code as before. All log entries are the same (except the one below). I already posted the Tag value. The error codes I see are 0x70020, 0x101f6, 0x640005. They have a decimal number to the left 32, 502, 5 - looks like they use just the three least significant digits?

Image sizes ended up as 10.3 for Normal, and 24.2 for uncompressed. 24 is a tad curious, since the used space at the moment was about 15gig. Recycle area might have been included.

New event - on second Validation trial of the same .tib file I got an C++ runtime error for TrueImageService.exe "This application has requested the Runtime to terminate it in an unusual way. Please contact the application support team for more information". No details. No debug window to be able to tell you more. Attempts to now close the application failed with "End program - Acronix True Image Home Trial" The program is not responding ... End now/Cancel. And the report wants to go straight to Bill Gates. The .hdmp dump is 11meg, the .mdmp is 265Kb, manifest provides no information other that the application hang - module=hungapp, version zero, offset zero.

With 6 days left on trial, I'm having a rough time deciding what to do. I really WANT this product, but not if I can't make it work here. Which version are you all using? Is there support for it?

seekforever, thank you for this good explanation. I'll read it again and again till it sinks in. I think I understand what you're telling me. Anything from program fault to my hardware is possible and I buy that. Thanks for the explanation of when the checksum is done. It makes sense. This is really one clever application, but I have problems.

 

Well I guess we can eliminate the USB drive.

Can you post details of your harddisk drive model, and configuration (e.g. RAID/Non RAID, SATA, SATA2, PATA) etc, and motherboard model.

Secondly, I suggest you download memtest (as given in seekforever's last post) and run that overnight (or for a few hours) so we can eliminate RAM problems.

Can you do test 3, just to see whether Linux has any better joy with verifying the image.

Alos, inspect your disk data cable, and ensure it is properly fitted at both ends.

F.

 

Have a look in the XP Event logger system log to see if anything unusual has been logged. This isn't usually a good source of info for these problems but it is easy to look. It helped me with my SATA cable.

 

Disable your write cache on the drive that you are saving the image to. I used to have the same problem in an old ver of Norton Ghost years ago even though that worked under dos. I went into windows, disabled write cache on the drive that will hold the backup file, after that all new backups verified fine. So disable write cache, do a backup, then verify again. Let me know if that works. If you don't know how to do this let me know.

 

seekforever, this is new to me, I need help.
I'll check the System error.
About memtest -
1. Do I use Memtest86+ V1.65 (10/01/2005) from memtest.org as opposed to memtest86-3.2 from the place referenced there, but dated 11/12/2004? Dates refer to the .ISO file.
2. I unzipped the file. I can burn a CD at work (it says CR-RW which my drive can read). It's a Roxio software and the option is Burn CD from ISO image, correct?
3. Then I boot from the CD somehow and hope to see the test run which will not kill my computer?

foghorne
I don't know what those abbreviations mean about disc drive. The local harddrive 60gig.
Motherboard is Toshiba's. It's all in a heavy duty laptop. It has 2 processors, Intel Pentium4. It has 2 memory things, each 512gig. That's my take on it.
Belarc Advisor says:
3.07 gigahertz Intel Pentium 4
16 kilobyte primary memory cache
1024 kilobyte secondary memory cache
TOSHIBA SATELLITE A75 PSA70U-004004
Board: TOSHIBA EDW10
BIOS: TOSHIBA V1.50 11/16/2004
IC25N060ATMR04-0 [Hard drive] (60.01 GB) -- drive 0, s/n <xxxxxxx>, rev MO3OAD4A, SMART Status: Healthy

I am not sure we can eliminate USB yet
Ok, I will do test 3, but the memory test comes first, unless cacheing solves the problem.

mm0659
I saw a "write cache" option someplace dealing with USB external, but don't recall where it was - drive properties? device properties?, give me exact location if you can, please.
Is your advice to be applied to the C harddrive as well? Or just USBs?

Once again, Thanks to all for help so far, it's outstanding

 

The drive is a 100MB/s PATA drive. This means that it is a conventional IDE drive and I wouldn't expect ATI to have any problems with it.
I see you have SMART enabled. Can anyone else comment one whether SMART can be an issue here? I have never ever run with it enabled.

Since the problem is not specific to the USB drive (i.e. you backed up from harddrive->harddrive and still had the problem) we can forget about it being the sole cause. The fewer components left in the system, the easier it is to locate the fault.

F.

 

Yes, you want V1.65. Yes, you want to burn an ISO image.
Don't worry it won't kill your computer.

 

I have it running on Auto on a P4P800 with 2 SATA drives which I think means if the drive supports it, do it. Manual is the usual brilliance where they list the options you have but not what they do.

I don't think SMART is a problem.

 

Thousands of RAM errors at 20+ addresses, and if I'm reading hex correctly, all in the upper 512meg. About a month ago I got extra 512 installed.
000 24d9 adxx (where x varies)
000 24d9 b8x4
000 24d9 b9x4
several went by fast starting at 000 25yy yyyy where I did not catch y.

Tests 0,9,10 passed. Of the failures, the worst 3 were Test 6,4,3.

People, if these are not false positives, I think Acronis TI should promote themselves as a RAM-problems indicator. I guess I have to fix the computer before I complain here anymore, and I'd like to thank you all for debugging this, as well as several other problems I've seen on this computer.

seekforever - event log does not have anything there other than a repeat of what TI screen said. And when it crashed there's a small dump. I don't think it'll help here.