Version 9 Corrupt images again

Hi DCM,

I was wondering how the test was going. Glad to hear your images are intact but I wonder why they are remaing good now since your images were initially verified well before.

If you are now using a newer build I would speculate that the verify process may not be stressing some part of your hardware as much. Is there any program such as a defragger that you haven't run recently?

Keep us posted.

 

if it help, i have the same problem. create image and then loaded new build.
could not read the tib files

 

DCM's problem isn't the same. He created images and they verified OK but after a few days they would no longer verify. This happened with the previous build.

What version does your program show in Help About?

B3567 is supposed to be able to read tib files created with the previous version but the old version cannot read tib files created with B3567.

Does this happen within Windows and with the B3567 (which I assume is the latest version you mention) rescue CD?

 

version 9.0;build 2302

 

i can still have access from windows

 

i downlaoded and re-installed. but keepgettin error message that proper serial number cannot be found and to re-install. get same error. help

 

I am running the same programs that I have used for years and am not sure that any version of Acronis ever ran right because I never had to do a restore.

My programs include a defragger and a couple of registry cleaners.

The one program that I am wondering about now is the latest version of Zone Alarm Pro. I had to take it off this weekend because it got to where I could not get Windows update to work unless it was turned off. It has done that for over a week.

I downloaded and installed the current Zone Alarm Free Version (6.1.xxxx) and it seems to be running fine.

It may not be the Zone Alarm program doing it though because the old version was still on my computer and some images were verified with it installed. Just mentioned it because it is the only program that I have had any trouble with recently.

 

Hello bobn1,

Thank you for choosing Acronis Disk Backup Software.

Please uninstall any previously installed build by following Start -> Settings -> Control Panel -> Add or Remove Programs -> Acronis True Image, prior to installing build 3567.

If that does not help, please do the following in order to install the latest build (3567) of Acronis True Image:
- Uninstall Acronis True Image 9.0 (build 2302);
- Open Registry Editor (Start -> Run -> regedit);
- Find the following branches:
o HKEY_LOCAL_MACHINE\Software\
o HKEY_LOCAL_MACHINE\Software\Acronis\
o HKEY_LOCAL_MACHINE\Software\Acronis\TrueImage
- Set Full Control permission for SYSTEM and current accounts for these branches;
- Install Acronis True Image 9.0 (build 3567).

If that does not help then please do the following:

- Launch the product installation file;

- Right-click on the "Install Acronis True Image" button and select "Extract";

- Select the path for extracting the component and click "Save";

- Go to the Run prompt (Start -> Run) and issue the following command:

msiexec /i msi-name /l*v log-name

Where msi-name is the name of the file you extracted in steps 2-3 and log-name is the path and the name to the log file you want to save the output to;

- Collect the log file created during the installation.

Please create Windows System Information as it is described in Acronis Help Post.

Please create an account, then log in and submit a request for technical support. Attach all the collected files and information to your request along with the step-by-step description of the actions taken before the problem appears and the link to this thread. We will investigate the problem and try to provide you with the solution.

Thank you.
--
Tatyana Tsyngaeva

 

Both of my drive images failed today. They have verified every day and I did not try to verify them today but neither one would allow recovery of a file.

The images are identical and located on an internal hard drive and an external USB 2.0 drive.

When I went through the process of recovering a file, a message popped up saying "Please Insert the Media marked Volume 1".

Of course, there is no way to insert any media and all three files in each image are located in the same folder. Files could be recovered from both of these images less than a week ago.

This message is frustrating because there is absolutely nothing that can be done to continue the operation. I will leave these images on my drives for a few days and then will remove the program and all images that are now stored because they are useless in this condition.

I am going to try to verify each of these image files just to try to isolate the problem for Acronis if that will help.

Just finished trying to verify both image sets and both failed and were called "corrupt" by the Acronis program.

The only thing that I have done in the last day was to remove Norton Ghost 9, try to install Norton Ghost 10 (it failed) and then reinstalled Norton Ghost 9.

I must have Ghost on the computer because to date, it is the only truly reliable image program that I have on hand.

 

Now is the time to run XCSC checksum calculator and see if you get the same checksums as you recorded. If these checksums are still the same then the files have not been altered.

The fact that the files in both locations went wrong at the same time seems to point that you have something wrong with the PC, either HW or conflict - not that the backup files are going bad I would think.

 

I will run the checksum again but am wondering why Ghost images are never corrupted like this?

 

Do you have System Restore enabled on your C drive? It might be interesting to go back to a point (if it exists) before you removed Ghost 9. I don't think your images are going bad but the TI verify process isn't working right due to some conflict is my guess. Unfortunately, that is all I can say it is - a guess. If you get the correct checksums then they would substantiate that theory.

I think there were some threads quite a while ago suspecting a Ghost conflict but I don't think any hard evidence to support the theory was given.

 

Just my 2p worth...

IMHO your hardware is flaky, as it is exhibiting the usual signs of files being falsely reported as corrupt. I have seen this phenomenon hundreds of times before in the course of building and repairing systems.

This is extremely typical of bad memory, particularly when DMA transfers are involved, due to the higher than normal load DMA places on the memory bus. Another area you should consider investigating, is the voltage variances across the 3.3v, 5v and 12v rails. It could be that your PSU is either underpowered, shorting, or poorly earthed. Do not believe for one moment that faulty PSUs cannot cause strange software anomalies - they can and do ... very often.

False "file corruption" problems also very commonly occur when there are I/O conflicts (usually matched to IRQ sharing) between the ide/scsi/usb host and either AGP or any other shared device.

I have not reviewed your system specs, but unless it is a very old motherboard, then the latter explanation is quite unlikely, due to modern solutions such as APIC.

Conclusion: You need to replace your memory, (and/or possibly your PSU).

Also IMHO, MemTest86 is an extremely unreliable gauge of memory integrity, since (from extensive experience) I can tell you that many known faulty systems that I have worked on in the past, have passed the MemTest test, but subsequently failed stress testing by other means. I suspect this may be because MemTest does not sufficiently stress DMA transfers, and indeed, it does not seem to access the disk subsystems at all, IIRC.

The most reliable stress test known to date, is a Linux Kernel Compile test, looped infinitely, until it causes a segfault. This is a very harsh test of memory, DMA, and disk host subsystems, all occurring simultaneously. Usually damaged memory modules will cause a segfault within seconds of such a test, but I invariably leave my tests to continue for up to 24 hrs to be sure. If after that time there has been no segfault, I am reasonably confident of the integrity of the memory.

If you can obtain a free Linux distro (Fedora?) and try installing it, perhaps you could confirm for certain if the memory is corrupt or not, but please don't rely on MemTest86. Incidentally, if you receive "file not found" type errors, while trying to install a large Linux distro from DVD, then that is another good indicator of corrupt memory, since the process of verifying, unpacking and installing a large set of (sometimes) massive archives, will also stress all three relevant systems considerably.

I can't stress enough, that you must check your memory; you will be banging your head against a brick wall forever until you do, since there is no software solution to damaged hardware.

 

Speaking from personal experience I cannot agree more with this. I had a system that would pass Memtest+ for days on end and in everyday use was 100% stable - but it would almost always produce corrupt images. I slackened the memory timings (even though I was running within stated spec before) and upped its voltage and not had a corrupt image since. The only stress testing program I could find that did show any issues up (apart from True Image 9 itself) was Prime95 (with blend test).

 

Precisely.

Off the top of my head, I would say that of all the faulty systems I've ever worked on, about 90% of the faults were with memory modules; 5% PSU faults, and the remaining 5% were any one of HD head crash/bearing failure, toasted CPUs, bad flashes, and BIOS settings (of which memory timing and voltages featured heavily).

The one exception was a problem that always sticks in my mind, which was a system that was so unstable that it immediately powered down only a few seconds after power on. Closer inspection revealed the cause ... dust.

Incredible but true ... too much dust ... around the PSU fan, the CPU fan ... everywhere. It caused the BIOS fan RPM monitor and CPU and PSU temperature sensors to instantly power off the machine.

Moral of the story is ... keep it clean, and look after your hardware.

 

I just ran a checksum calculator test and all three lines of the results were different than the original tib file. Only did it on one file because if it is corrupt, the other two would be useless anyway.

If I have a memory problem, shouldn't something else be corrupting or failing to run?

This is the only program that is giving me problems. My Norton Ghost program works fine and so do my backups along with all other software that I run daily.

I am going to try to find Linux Kernel Compile test software and see what happens though.

Thanks for your responses. If these don't give me a clue, I will just remove the program and agree to disagree with the Acronis program for a while.

 

Are you saying that the checksum on that tib file is different from the checksum done previously on the same file?

 

I would say the wrong checksum indicates that there is nothing wrong with the Acronis software. An independent program shows either the file has changed or something like a bad memory location is causing an incorrect checksum to be calculated by XCSC.exe Did you check the file on the internal or the external drive? You should check both.

How severe a bad memory location is to your system depends on where it is. If it is somewhere in memory that rarely gets accessed and is likely to contain a data file you can run for a long time without even realizing it. A bad location in a jpg file might mean an off-color dot in an image, scarcely earth shattering. If TI uses the bad location then one bad it in the byte give a fatal verification error. Remember that the images are very large and are likely to use large amounts of memory when being processed. Norton can work if it doesn't happen to use the bad area.

Memtest86+ is a good memory diagnostic but the weak thing is that is all it is and it doesn't necessarily test memory in the manner it get used in real life. Also, voltage levels are more likely to slightly fluctuate when you have a lot of disk activity going on and there is also more electrical "noise" floating around. A small drop in voltage or increased noise to a marginal memory stick can cause problems to show up even though the voltage is still within spec. This is why swapping memory for good memory and seeing how it performs with the actual application and OS running.

This has been going on for a while now and I can't remember what has been tried and not tried. I would measure my power supply voltages but you may not have a voltmeter. Some machines have monitoring of voltages in the BIOS or a monitoring program that comes with the motherboard. Unfortunately, I don't know how accurate they are.

If you have more than one stick of memory try running with only one or the other if possible.

One thing is bothering me and that is the fact the files are good for a number of days and then go "bad". If the problem is intermittent memory or whatever, then one would expect after a number of days the problem would go away and the files would check out good. If this doesn't happen then maybe there is a problem like a disk controller screwing up the files. However, you should see it only on one drive, either the internal or external (at least in the simple sense).

 

I agree with seekforever.
It's probably a hardware fault of some kind.
Definitely run exhaustive hardware checks.
Try using the checksum program several times during the day - immediately after a cold boot and after working for some hours.
Try using Windows to copying the tib to another filename and run checksum on the copied file - does the checksum agree with any of the previous checksum calculations?
Have you checked that you've got 80 wires in the IDE cables?

 

Linux uses hardware resources (including memory) much more aggressively than Windows, not because it is less efficient, but actually for the opposite reason. Therefore Linux will reveal weaknesses in hardware very quickly, that might take much longer to manifest under Windows.

Of course, the above is just a generalization, and in fact the differences lie between applications as much as between different kernels, HALs and APIs.

So it is not inconceivable that one application (Norton Ghost) uses a different set of resources (or uses some of the same resources in a different way - i.e. less aggressively) than another (TrueImage).

From what I have seen, I suspect that there is rather more Linux methodology in TrueImage, than Windows methodology (e.g. the boot disk is essentially a mini Linux distro).

So frankly I am not surprised that TrueImage is revealing weaknesses in your hardware.

You know, the situation can be easily resolved: memory is cheap. Simply buy replacement memory, and if it doesn't turn out to be the culprit, then sell it.

 

I will probably just wait for my next computer which I will either build or buy in the next month. Then, I will reinstall Acronis and see what happens.

My present computer is a Pentium III that is about 6 years old and probably not worth the cost of the memory.

I would like to do the Linux test of my memory but cannot figure out how to do it. I have been doing Google searches and so far have not found a Linux program for this.

Thanks

 

I agree with [H]omer, I ran a my PC for 12months with Driveimage and never a single corrupt image. Change to TI9 and get regular corrupt images. After extensive testing found it was a memory problem, fixed it and now 100% success with TI9. TI9 just stresses the hardware more - though I would have thought that some type of error checking/correction could be used to compensate.

 

b00sfuk

How did you check your memory? I ran Memtest from the floppy for almost 9 hours with no errors reported.

I would use something else to test my memory but do not know another program that might do a better job.

 

Hi DCM,

Memtest86+ has always worked for me in the past but that's not to say it's infallible. Microsoft provide the free <Windows Memory Diagnostic>, which is easy to use and might be worth trying. Also, I have heard that running the Mersenne prime generator <Prime95> is a really good test of your hardware but isn't so easy to set up/use and can take a long time.

Regards

 

It's called ECC (Error Correcting Code) memory. It has some additional bits for each location and a number is written into the the additional bits such that when the original data is presented it is combined with the additonal bits and bad data will be corrected within limitations.

It obviously is more expensive and needs the ECC circuitry to handle it. Usually used only in high-end servers.

In the early days of PCs Parity memory was fairly common. In this case an extra bit was added to the memory and if the data was wrong within limits the parity bit comparison would flag the operating system. As memory got more reliable it faded away as a cost-saving initiative.

If memory is flakey it is difficult to do much about it outside of ECC. You are trying to fix a bad hardware problem by using bad hardware! TI's verify function does give notice of a problem but unfortunately can't do anything to fix it.