Corrupt/Can't Verify Corrupt Archives: Let's uncover the problem!

No, my main computer is a five-year-old 2.8 GHz P4, single CPU, single thread, single core computer. It is very nicely "tuned," meaning that I have no background operations running (e.g., no anti-virus programs), and never do any Microsoft updates. It is essentially the same computer I was running four years ago.

However, because it was so cleverly designed, and the software has been kept so lean, it is far more responsive than any other computer I own (it was built by Polywell).

And yes, I have checked, and there are no spyware and no virus programs running (I do have one anti-virus program on one of my twelve computers and once or twice a year, I open up my C: drive to the local network and scan all the files. Also, I know where viruses "hide" and how to spot them.)

Acronis tech support has asked for -- and I have provided -- extensive information about my computer. I am hoping that perhaps we can finally uncover the problem, as I suggested we do in the subject heading of my first post in this thread. If Acronis can help me uncover something useful, I will obviously post the result here. If it is important enough, I will start a new thread so that more people can be made aware of a possible fix.

However, I am perhaps getting ahead of myself ...

 

Hello John,

Out of interest, what speed is the main bus set to on the motherboard - 100Mhz or 133Mhz? If it's set to 133Mhz, try reducing it to 100Mhz and see what happens when you create and verify a new image. This has been known to overcome the problem of corrupt images on certain systems.

Regards

Menorcaman

 

It is set to 133, I think. I'll check again and see.

I spent several hours on this today and was finally able to get back to where I was a month ago where I can create and validate images to my internal hard drive, using the older TI 9 (instead of TI 11). The key to getting back to that point was using System File Checker (SFC.EXE) which replaced several DLLs in the Sytem32 folder. I was able to narrow down the problem (of not being able to create ANY image backups that would validate, even to internal IDE drives) to one of two DLLs that probably were somehow conflicting with TI.

None of this discussion about memory or bus timings makes ANY sense to me. I have experienced memory timing failures, and believe me, the entire computer is pretty much unstable and hosed. By contrast, I have had this computer for almost five years, and it has never been unstable or had problems with anything else. Not once. Nor have I "diddled" with the BIOS or tried to overclock or anything like that. Never.

No, this is either simply bad programming, or it is a conflict with a system DLL. I suspect that Acronis may be dealing with the disk drives in some non-standard, low-level way in order to increase backup performance, and they are not dealing properly when bits are not read correctly from the drive. Remember that all media have errors, but the low-level drivers in Windows and in the disk hardware takes care of correcting those errors. I'll bet they are bypassing some of this and just not getting it right.

 

Obviously you are free to draw your own conclusions but take it from me, flaky memory addresses and bus timing issues have been responsible for TI image corruption, even though other applications remain unaffected. However, as you only encounter image corruption when creating/validating images to external drives whilst in Windows mode, then these are unlikely to be the cause in your case.

As your problem manifests itself across 3 completely different computer, 6 USB HDs and 1 Firewire HD, I'm surprised that you think a TI/.dll conflict is the likely culprit. Anyway, good luck with your continuing fault diagnosis.

Regards

Menorcaman

 

The lack of Microsoft updates may be part of your problem at least when running within Windows. The requirements for TI state XP with SP2.

 

Hey, I'm trying everything at this point, so I'll try this as well (the system is set for 133 right now, so I'll try it after I change the BIOS to 100).

I don't think that this is the main cause of the problem, but it definitely was the reason why my computer started to not validate even on internal drives. I used the SFC.EXE utility to check all DLLs and I was able to track what it did. Two DLLs were changed that are likely used by TI. I am now able to backup again to internal drives, but it's still a 50/50 proposition going to externals. Also, I gave up on TI 11 and went back to TI 9 (I did this about four days ago).

Also, tech support asked me to do an image backup using the rescue media, and this, of course, eliminates Windows completely. I got a corrupt archive, even when backing up to my second internal IDE hard drive. I also got a corrupt archive when trying to burn a DVD image of my C: drive.

This computer has been perfectly stable for five years, with all sorts of video and sound applications. This program is the only one that causes problems (which is what many other users have said). There is definitely something in the way Acronis programmed this product that is non-standard.

Well, as I just stated, I have problems even when doing a backup from the rescue media, so Windows is not the main culprit. Also, I'm having the problem even with TI 9. While it is true that TI 9 does specify SP2 for XP (and I have SP1), it is also true that it runs on Win98 and WinME, and of course SP1 is way beyond either of those.

 

Hello John,

Will you please boot from your Version 9 rescue CD and confim the build number shown in Help About ?

It would be useful to do this to truly confirm the build number that you are using. Early builds of Version 9 did indeed have software problems on the rescue CD. The main one being that verifications always failed! In fact there was nothing wrong with the images it was just the reporting that was in error.
It also was possible to install a later build on top of an early build and the build number did not change and the verification problems continued on the freshly burned CD.
So whatever V9 build you think you have on the CD it is just possible that the label does not show the actual contents.

There is a remote possibility that a SP1 installation could burn an imperfect rescue CD. I have no means to check this out but suggest that a rescue CD of the latest or penultimate build of Version 9 prepared on a SP2 computer or from a Support provided ISO would eliminate it.

Xpilot

 

It's Acronis*True*Image*Home® version 9.0 (build*3,854). This is the final build before version 10. Also, I created the build media just a few days ago.

Also, in answer to a previous poster, I tried to set my BIOS for a slower clock (100 MHz instead of 133), but 133 is the lowest the BIOS will accept and is what I have always had the computer set for. The BIOS help said something about 100MHz, but I think that is a generic help system that wasn't updated for this particular OEM build.

 

On some motherboards it's done via a switch or patchlink.

Regards

Menorcaman

 

A simple trick to restore 'bad' images

Let me tell you about a trick I applied the last time in my desperation for using the image that contained the OS I was requiring to restore.

Even after have got the famous "E00070020" error:


... I have been able to recover those "bad" images pretty simple, here goes the trick:

1) Delete the partition WHERE you will restore the image. It means the DESTINATION PARTITION. Just get rid of that but leave the unallocated space there. Do not touch that unallocated space, in any way!
2) With the restoration media placed in your CD/DVD drive boot your computer (I havent tried this trick from windows only booting from the restoration media).
3) Now just go through the restoration process and dump the image into the UNALLOCATED space. It will work. (Well @ least for me it has worked).

CLARIFICATION:
In the past before dumping an image to a partition, I was formatting first the partition with Acronis Disk Director using the filesystem (ReiserFS, NTFS, FAT32, etc.) that that partition originally had. But I realized that TI didnt require to have a previous 'prepared' partition (aka already formatted) to allow the successfully completion of the dumping process.

SO I CALLED IT A TRICK, dont know really if that's a trick or I was the one not using the product (TI) correctly.

I wrote this post basically to help as many people as possible by providing them a simple but working way to restore their previous saved images.

Good luck guys, I just hope this trick would be useful for lots of you.

PD: Hopefully Acronis Co. will solve the famous "E00070020" error someday ONCE FOR ALL.

 

Well, I am a little ahead. I am using Acronis 11.0 and I have developed the same problem. Corrupted image.

Some seem to suggested that go ahead and use the image to restore your C Drive. Ooops...what if you restore part of C Drive and the program stops to inform you that the image is corrupt? Lost the entire drive! I store three images on three separate hard drives. Same problem.

I went back to Acronis 8.0 with the latest build and had the same problem. I have in the past, used 8.0 to restore an image. Wonder if some how the latest Acronis has injected a problem that carries forward even with an uninstall and a reinstall.

I have Ghost 9.0--old one. Maybe I should try to migrate.

 

You are correct. If the restore finds the image corrupted the restored partition(s) will be deleted and show as unallocated space.

Your post indicates your machine was working properly with TI and now it doesn't. So something changed. Obviously putting on TI11 is a change (particularly if you never did a successful validate/restore with TI11) and also your hardware might have changed; either developed a problem, was changed, or you modified some BIOS settings.

Are you running the latest version of TI11?

You will know if you changed the BIOS or added different hardware.

For HW problems that have developed try:
Running memtest86+, V1.7 from www.memtest.org for a few hours (overnight is best). There must be no errors.

Run chkdsk X: /r on all your partitions. Substitute the letter of the drive being tested for X: Reboot required for C.

Take the image to another PC and try to validate it with the TI rescue CD.

Are the images stored on internal or external HDs?

 

i have this exact same problem. i was using acronis v10 build 4940 and everything worked fine and dandy. i never ran validation checks but i did use the recovery cd i made using the program. i never backed up while running windows. all my backups are saved on a separate internal drive. images restored fine with v10 but then recently(yesterday) i got v11 build 8053 and created a recovery disk and rebooted my computer to make a backup file. now no backup will restore because they are "corrupt." i tried using the v10 recovery disk again but now its saying the same error. i dont know if it makes any difference but im using windows vista. what can i do? ive been using acronis true image as my backup solution for years and would hate to resort to another software or even the built in vista backup software. i have also run tons of memory checks and have recieved no errors for hours.

 

Uninstall TI11 using this process (see last post by Acronis) and then put the TI10 version back and see if it works.
https://www.wilderssecurity.com/showthread.php?p=1117080#post1117080

The TI10 recovery CD is unable to read the TI11 format because it was changed.

Let us know if this worked or not.

 

after having virtually every backup fail validation I tried numerous things and
found a solution to my problem.
I found that the BIOS was reading my external usb2 drives as internal hard drives and seemed to be confusing Acronis.(although I can't seem to find out why the BIOS was doing this)
I had previously had norton ghost 10 installed and it would not recognize that I had external USB hdd either it kept coming up with a message that dvd/cd drive wasn't the best place for backups and to press refresh.After pressing refresh all I got was the same message.
I loaded "fail safe" BIOS settings and found everything now works perfectly.
I made a few changes to the BIOS since (regarding specific items ie disable on board sound ) etc.
I use a foxconn mb with sis usb chipset
hope this helps someone.

 

TIH_10 corrupted partitions when only READING them

I recall that corrupt partitions appearing in such cases are almost ever corrupted by TIH, and even when TIH is only reading the archives in the said partitions; so "chkdsk X: /r" will essentially consolidate the previous corruption and possibly make the rescue impossible, while it will NOT prevent from furthr corruptions.

Better would be Acronis really addressing the problem instead of throwing loads of ridiculous lies about it (like pretending, without laughing, that a faulty MEM would be the culprit).

First efficient help would be to identify which versions and builds of TIH don't corrupt existing archives (I knew one that apparently didn't, I think it was TIH_9 b2337 or b3633. TIH_10 b4942 did corrupt, when only reading them, the FS on the partitions where were the existing archives. I didn't test TIH_11 so far - too dangerous).

Versailles, Mon 19 Nov 2007 08:16:00 +0100

 

Re: TIH_10 corrupted partitions when only READING them

My response was for a person who apparently had been using TI sucessfully and now it has started giving errors. The steps were to try and rule in or out possible causes of the corruption error.

The /r switch on chkdsk implies the /f option and then does a scan of the unused surface. In effect, it checks the exisiting file structure and the remainder of the disk. Although I would say it is common, some file system errors have caused some strange things to happen when using TI and if the archive is written on a bad area of the destination disk then it can indeed be corrupted.

The validate process in TI is a checksum calculation and bad memory can influence the outcome. Does this mean it is always the cause, certainly not, but it something to be considered.

Given the issues with TI11, I would say it is likely it has caused the problem but a simple replacing the program didn't fix it which means that the HW is a possible candidate as the cause as well.

TI like most programs assumes your hardware is 100% reliable and it is also known that the very large amount of data processed at the highest possible speed puts an atypical strain on machines that often operate in a relaxed environment. IMO, running chkdsk at regular intervals is not a bad idea.

 

Re: TIH_10 corrupted partitions when only READING them

Hello Michel,

Ridiculous lies? I think not!! To save you the effort of trawling back through this forum, I can assure you that faulty RAM, or too aggresive RAM timing, has been confirmed as the reason for currupt images by a number of TI users.

Menorcaman

 

interestingly with v10 b4940, backing up and validating works perfectly fine in the safe mode version from the recovery cd. the full version refuses to validate whether in windows or from the recovery cd.perhaps it is a hardware error but i dont understand why only acronis is sensitive to this error.

 

TIH likely *main* cause of errors - don't dump fault 100% on other HW or SW

Thanks seekforever for replying (15:15 GMT).

First I should have written "that a faulty MEM would be the only culprit", and I regret (even if it was true - see correction above and explanations below) the "ridiculous lies" comment.

Second I keep my main issue: obviously there is a grave problem in some builds of TIH, and as often in such cases, the maker tends to try dump the entire fault onto other products, unduly since the PC running TIH, while in many cases a loaded one, has most often no such problems in other apps, and sometimes in certain other builds of TIH. This is why I think Acronis should spend less resources in dumping the problem and more in curing it.

About everyone following this thread is probably "a person who apparently had been using TI successfully and now it has started giving errors"; in my case see my posts of Wed 26 Sep 2007 18:36 GMT, Thu 27 Sep 2007 07:43 GMT, Sun 7 Oct 2007 14:58 GMT. While I agree (probably like most here) with most of your recalls, I don't entirely with a few:

As many others I am convinced (sure more tests would be needed to prove it to others) that in my case TI caused the errors in my FS, not the reverse, and that this is the most frequent case.

What do you mean "a simple replacing the program didn't fix it"? Replacing TIH_11 with another build of TIH_11? or with one of TIH_10 or TIH_9 or earlier? or do you imply a non-Acronis program? Have you examples on both sides (with problems and without)? Thx for making this clearer.

While ignoring their innards I think most programs test first the capabilities of the system (HW & SW), then stress it to a level compatible with a good reliability of the resulting whole process, not of the HW alone. In my case e.g. I built (in... 1977!) an FS to replace the existing with a more efficient and safer one on our little HP machines; this involved enough tests to make reasonably sure no problem would occur in any foreseeable circumstances - which I doubt was done correctly with TIH.

May be yes, may be no. I remember big "datastrophes" with ScanDisk (or old or recent CHKDSK); I twice lost an entire HD (fortunately correctly backed up) when ScanDisk "corrected" errors that, prior made by other programs (once Partition Magic 3, the other IE trying to handle web cache files with invalid names), should have been easy to fix another way; instead ScanDisk rewrote the "entry" in FAT for each of the folders and files, thus propagating the error in the whole FAT thus rendering the entire disk unusable.

With TIH the errors may be grave mostly by the facts that they hit entire archives, otherwise it seems they are relatively benign in nature, so they should be able to be fixed.

Versailles, Mon 19 Nov 2007 23:44:35 +0100

 

Discovery of MEM failures can as well be *consequences* of TIH corruption

Replacing your 3 links to posts alone with links to posts in their threads, and checking your 3 cases:

1. bob_rock Mon 11 June 2007 08:02 GMT
   bob_rock reported that his image created with True Image 10, that validated first, stopped validating after moving the image to any other HD or DVD; then on demand, he reported "tons of errors in memtest". But he didn't tell neither if or why such errors occurred only under TI and not under other apps, nor if or why they stopped in the same operations under TI after changing the RAM. So the most probable for me (and probably for anyone independent from Acronis) remains that this was just one more instance of corruption created by Acronis True Image (probably TIH). BTW nothing proves so far that MEM tests on randomly chosen PCs would show more failures on PCs having FS errors under TIH, than on others.
   
2. leblond23 Thu 11 Jan 2007 18:40 GMT
   leblond23's report again doesn't prove in any way that MEM failure is the culprit. However another does in the same thread: john316 Fri 9 Feb 2007 05:12 GMT.
   
3. MSprecher Fri 8 Dec 2006 22:22 GMT
   In this case like in john316's, yes the culprit was MEM failure (according to reports).

So it does appear (according to reports in the forum, and oppositely to my guess I admit) that in 2 of these 4 cases the corruption did not reproduce after the faulty MEM modules were replaced, so the culprit was most probably a MEM failure. Thanks for your useful pointing of these cases.

Remains however to find why these MEM faults affected only TI and not others apps, and what proportion of all the PCs have faulty MEM tests (it may be a high proportion, like 50%, of which only a very few will be detected when problems arise in a few applications like TI thus prompting the user to perform Memtest86+; as appropriately recalled in Wikipedia Memtest86+: "it can find otherwise hidden problems on machines that appear to work normally").

Other questions that should be tested: Does it happen with the same frequency under all versions and builds of TIH? Does it appear same way, same frequency with other flavors of TI in the SMB or LEB depts? An average PC, most often at the great surprise of his owner, has easily 100 main applications installed, many running, and even many more utilities, plugins, ActiveX controls, etc; why such problems arise only under a very few apps (Acronis this year)? The too wide number of possible hypothesis makes hard to select one, hence useful to search more before building too authoritative conclusions.

Versailles, Mon 19 Nov 2007 23:46:10 +0100

 

A possible reason that only Acronis is sensitive to the error can be due to probabilities. If you have a 10GB archive, it contains 80,000,000,000 bits of information. If only 1 bit is read transferred incorrectly, is not recorded in RAM correctly, or is dropped when reading the RAM then the archive will be declared corrupt.

TI writes a checksum for every 256K bytes of data which amounts to 4000 checksums per gigabyte which have to be faithfully reconstructed from the archive to have it declared validated.

What other applications do you run on your PC that do this to so much data at one time? If you read a regular data file like a jpg, it passes the disk controllers CRC check and then goes into a bad memory location, there is a good chance you won't even know about it.

The safe mode uses a DOS variant to provide the environment. It obviously isn't the same as the Windows environment of the Linux environment used in the Full recovery mode. It could be that the timing is a little easier on the system in the DOS mode. Normally, I'd say you might have a Linux driver incompatibility but you say it fails in Windows also.

Did you try the uninstall procedure for TI11 and then reinstall TI10 which used to work? Acronis has made some changes with TI11 and registry left-overs could be a problem.

 

Re: Discovery of MEM failures can as well be *consequences* of TIH corruption

See my response to zcubed. Yes, some of us think TI is a good memory diagnostic - not really that good, since who knows how much of the memory is being tested with a validation. However, it has shown memory problems that the PC owner didn't know were there.

 

What file system are you using guys to backup your images

I'm using Acronis Secure Zone, even so I'm still facing the famous "E00070020" error. But doing the trick I explained here, you can restore your images besides if your image is detected as "corrupted".

Anyway let me know what file system you set in the partition where you are storing your backup images.

 

I am glad that your trick worked for you. I do not understand the logic behind it and I will not try to .

I also use a Secure Zone for all my images. I can safely avoid ever running validations but have had some rare corrupt images when running restores in the past 18 months or so. Just recently I had two fail in a row shortly followed by a BIOS message that I had no hard drives connected.
This was the clue where to look. I opened the tower and saw that the lead to the hardrive controller was under a bit of tension. I re-seated the hard drive controller board and reconnected the cable to my drive rack after routing the cable for a bit more slack.

I am confident that my previous rare and random E00070020 reports and the recent failures were due to nothing more than a poor connection to my hard drives.
It also reinforces my belief that where faults appear on a system that has run TI sucessfully It is very unlikely to be anything wrong with the TI program itself.

Xpilot