Version 9 Corrupt images again

[DCM]

Acronis allowed me to make a second trial of Version 9 after I tried the old version and had many corrupt images.

One April 14, 2006, I made an image of my C: drive and selected DVD sized files. Verified the creation immediately after creating it and it verified OK. This was created and stored on one of my external hard drives and all files were in the same partition. It contained 4 files.

Verified again yesterday (April 15, 2006) and it again verified OK.

1. Today (April 16, 2006) I tried to restore a file from the images.

The message I received was "Please Insert Volume 1".

When I tried clicking on the first file in the set, assuming that it was "volume 1", it would not work nor would anything else that I tried. Could not "insert volume 1" because it was already there on the hard drive in the same place it was created. Retry did not work either and it was very difficult to get out of this cycle.

2. Next, I tried to "mount" the image. A message came back immediately saying "cannot assign a drive letter....".

3. Last, I tried to verify the image again. I assumed that it would verify since it already had been verified as being OK twice since it was created. This time, another error message popped up. It said "corrupt image" and blamed "poor media quality". This is ridiculous. The drive is working perfectly.

My machine will not run either Version 8 (wasted money) or Version 9.

Removed off topic comments - Ron

[Chutsman]

Create the bootable Rescue CD, boot with it and see if that works.

[Menorcaman]

Also would be worth downloading and running <Memtest86+> (http://www.memtest.org/) for a few hours just in case you have some flakey/too aggressively timed RAM. There should be no errors reported at the end of the test.

Regards

[DCM]

I just tried the boot disk that I made a while back. It would not work on those 4.3 gig files.

Gave a message saying that they were not Acronis True Images files although they clearly are and still have the tib
file extension.

Next, I went to 2 old Acronis Images that are also on external USB drives but the file sizes are 700 MB. They both checked out clearly and I can restore data from them.

The files that I have the most trouble with are those that are larger than 700 MB and I suspect that if Acronis will look at those closely, they will find the problem.

Off topic comment removed - Ron Not sure how I will know though because they allowed me a second trial period so that I could try version 3657. It only took 3 days to find out that something is still wrong.

Somehow, after the images are created, they will verify OK and then somehow get corrupted even though they are not being used.

[seekforever]

-{ Quote: "I just tried the boot disk that I made a while back. It would not work on those 4.3 gig files.

Gave a message saying that they were not Acronis True Images files although they clearly are and still have the tib
file extension.

... " }-

That may be your problem. If the files are created with the new build 3567 TI 9 Home the old version on your CD can't understand the new format. The new program (3567) can read old TI 8 and TI 9 images. Creat the B3567 rescure CD if you haven't.

[DCM]

seekforever

Thanks for the hint. After hearing about that, I created a new Version 9 boot disk and tried it. It did start out with the verification process but then gave an error and would no longer do anything. The error was

E0004000D "The file is corrupted".
Reason may be poor media quallity. Retry or Cancel.

Retry did nothing so I cancelled.

The media is a hard drive and yesterday and the day before, it verified OK. I was trying it every day because I have found that the images seem to deteriorate or get corrupted somehow as time goes on. I wanted to see if they had finally stabilized their images. Guess not.

Acronis Tech Support is excellent and I suppose that some day they will fix this.

Smaller file sizes seem to hold up but I am not sure enough of that over a long term to risk depending on them at this time.

[seekforever]

Does the drive you have the image stored on get defragged perhaps during the time the image is created to the time it fails to verify? Defragging shouldn't upset the image but it has been mentioned.

Humour me and download this program, XCSC.exe (V1.0.0), it is a free checksum calculator available at:
http://www.irnis.net/free.shtml

Create an image, verify it and if it verifies OK, run the checksum calculator program XCSC on the file and record the checksum. When (if) the verify fails, run XCSC again and see if the checksums are different. The MD5 checksum is a good one to record.

If the checksums are different then it means something "physical" has gone wrong with your file; if they are the same and the verify fails then it is something to do with TI.

If it is a split image file, run XCSC on each tib file of the set and record the checksums.

Edit: I now don't think I can say that identical checksums on an image that fails verification definitely shifts the blame to TI since the file reading and calculating of the checksum is not identical to the way TI does it. What I am saying is that TI's method of reading the file could stress the sub-system more than XCSC. The real benefit is seeing if something does cause the files to be corrupted as evidenced by a bad checksum.

[Acronis Support]

Hello DCM,

Thank you for your interest in Acronis Disk Backup Software (http://www.acronis.com/homecomputing/products/trueimage/).

As seekforever said above, you should run the eXpress CheckSum Calculator (http://www.irnis.net/files/xcsci.exe), specify any the .tib file on the external hard drive then click "Start" to create a MD5 checksum.
Then copy the same .tib file back to your internal HD and run the Checksum Calculator on the copied file to create another MD5 checksum, compare the two MD5 checksums and see whether they are the same.

Please also create the new image onto the internal hard drive (do not split it) and then verfiy it both in Windows and in rescue mode.

Please let us know the results.

Thank you.
--
Tatyana Tsyngaeva

[Menorcaman]

Hello DCM,

Ignoring True Image for the moment, there are a couple of well known reasons for image corruption that you should check out in the following order:

1) Bad or too aggressively timed memory. You can pretty well rule this out if your memory passes the Memtest86+ test that I mentioned in Post #3 above. If it does pass then move on to 2). However, If it doesn't pass then determine which memory module is faulty (assuming you have more than 1 stick), change it and retest with Memtest86+. Once the memory passes the Memtest86+ check, create another image on your external drive and see whether it verifies correctly. If it does then all well and good. If it doesn't then carry out the compatibility test in 2).

2) Incompatibility between your motherboard's USB subsystem and your external hard drive enclosure's USB to IDE bridge chipset. This can be checked by following the first part of Tatyana's advice i.e. create a MD5 checksum for a large .tib file on the external HD, copy the same .tib file back to your internal HD and create another MD5 checksum from that. If the two checksums are different then there is a hardware compatibility issue which needs addressing.

Regards

[DCM]

seekforever

I just shut off the Memtest program after 8 hours and 44 minutes. It made 9 passes with no errors and was still going.

Next, I am going to create some new images and then run the checksum program on them. It will take a few days because my experience has been that the images become corrupt after 2-3 days of sitting unused.

Thanks for helping and I will post again when I am done with the next stage. Hope that doing this will either fix my installation or provide data and a clue for Acronis to fix the program if it is broken.

[seekforever]

I await your results with interest! I was thinking it might be good to run the checksum calculator a couple of times on each file just to make sure you get a consistent reference checksum recorded (it should always produce the same checksum number).

[tachyon42]

Another couple of issues which I have found can cause problems:

(a) Hard drive cables.
Try swapping cables with another set of cables to reduce the likelihood of a faulty cable.
If you have IDE drives ensure that you are using 80 wire connector cables not 40 wire cables (count the wires not the pins).
Also the recommended maximum for IDE cable length is 18inch (45cm) - if you have longer cables try getting shorter ones. Longer cables may work most of the time but are a possible cause of occasional problems.

(b) Logical file structure
Run chkdsk /f , possibly more than once, until chkdsk reports "no problem".
If still have problems with TrueImage try chkdsk /r also.
Sometimes chkdsk fails to report (and consequently fix) some errors.
You might find that other utilities, e.g. PartitionMagic, might also experience problems. If so, then it might be worth re-creating your system on a new partition (or disk), reinstall all software and use Windows to copy all the data files. This way you get a 'clean' logical file structure. You might also find problem data you can't copy, null files, etc which might be the cause of some of your problems.

(c) Disk media
Run manufacturer's diagnostics on hard drives.
If using CDs or DVDs then try several different brands. Use best quality well known brands. Check out websites such as www.cdfreaks.com for reviews of disk media. Maybe they have a review of your CD/DVD drive, if so cdfreaks usually give detailed analysis of media they've tried with the drive. All brands (or disk media product in same brand) are NOT the same!

(d) Drivers
Ensure you have the latest reliable drivers and BIOS for your hardware. Search the web for info and other user comments. For example, you might find that there are known issues with your motherboard which might account for your problems.

[DCM]

seekforever

I encountered a problem. I have never run a checksum program before.

After downloading the checksum software and starting, I cannot figure out how to tell it to check specific files.

Had the same problem with several other checksum programs.

This is only happening because I don't know what I am doing but want to learn. Can you help?

Thanks

[Menorcaman]

Hi DCM,

Download the self extracting xcsc.exe file via seekforever's or Acronis Support's link and extract the xcsc checksum calculator.

After that, just run the xcsc.exe file and follow Steps 1 & 2 as per the Screenshot below.

Regards

[DCM]

Menorcaman

Thanks for the help. I was able to get it running after your explanation. Your program screen is much different than mine with that software.

Mine is supposed to be the latest version but is in black and white and has a grayed out box in the upper right hand corner for browsing.

Earlier, I looked at it but did not click on the grayed out buttong to browse for the files. If I had, it would have worked.

The first file I tried was in that corrupt image containing four files. It was created about a week ago and verified successfully on the day of creation and the next day. The third day, it verified as being corrupt.

I tried one file with 4.2 gig and the other with 7228 KB. They each came up with a message saying

"This file does not contain any known valid checksum information".

Next, I tried the program on an image that I created in November 2005. It has verified as OK many times in that period and I have restored some data from it from time to time. The files in this image are 700 MB each.

The checksum program came up with the same message on these files so I ran the Acronis verification again and it still verifies OK.

I do not know what this means but this is what happened to each of these images.

I am going to try to find another version of the checksum program too. Yours looks much nicer than mine.

[seekforever]

Perhaps you downloaded the checksum verifier program rather than the checksum calculator? The calculator program IIRC is below the verfier.

[DCM]

I did download the verifier instead of the calculator. After downloading and running the calculator on the four files that became corrupt after sitting for three days, it worked well.

Next, I ran the verifier and it said that two of the four dvd sized files had incorrect checksum values.

After that, I tried to run the calculator on the 10 smaller files (700 mb) in the image that has remained sound for the last five months. It seemed to run OK but never did create a "md5sum.lst" file like it did for the image with larger files. The verifier did not indicate that it had started but after trying to exit, I found that it was running in the background.

I exited and gave up on that until I figure out how to run these two programs properly.

I am going to create another image without any limitation on file sizes and see how it holds up.

[seekforever]

-{ Quote: "... I exited and gave up on that until I figure out how to run these two programs properly.

I am going to create another image without any limitation on file sizes and see how it holds up." }-

I don't know how the verifier operates. The checksum calculator calculates the checksum of a file and it should always get the same number if the file is intact. My intention was for you to run the calculator on each tib file of interest and write the checksums obtained on a piece of paper with the filename for later reference. To be certain, I would do it a couple of times on each file to make sure it is consistent. In other words forget about the checksum Verifier program you downloaded.

When the TI verify fails then you will run the calculator again on the failing image file(s) and see if you still get the same checksum.

You can also do as Acronis suggested and copy the files from the backup disk to another disk and compare the checksums of the original file and the copied file. They must be the same if the copy was good. This is a good test to do since it brings some extra parts of the disk sub-system into play.

The calculator calculates 3 different types of checksum for the file if all the boxes are ticked. You really only need one of them and the MD5 is probably a good one to record. Note that even a 1 bit change in the file will make a much larger change in the value of the checksum.

[tachyon42]

I can't remember which program it was but one of the checksum programs recommended by Acronis last year had a bug which caused it to calculate incorrect checksums for large files.
I found AccuHash 2.0.17 which seems to work OK for me.
I just downloaded it for free and used the feature limited version (didn't register). You can also buy the full version.
I haven't tried the latest 2.0.18 version.
Download from http://www.accuhash.com/download.html

[DCM]

I did another image of my c: drive tonight on my external USB 2.0 drive and ran the checksum calculator. Then, copied the image files to my internal hard drive.

The checksums are the same today. Will continue checking.

While waiting for the checksums to calculate, I had a thought. I was wondering if a poll might be in order to see where everyone is having this problem. It could ask about the drives ie: internal/external, usb/firewire/ ide/sata, file sizes in the image ie: CD size/DVD size, or unlimited, operating system etc. Maybe it would bring some common denominator to light.

I don't know how to set up a poll or I would try it. Someone more knowledgable might do a better job though.

[DCM]

This morning, I validated all my files. This included the ones on the external USB 2.0 drive and the internal hard drive. All verifed OK.

I expected this because in the past, this is what has always happened after creating an image. After the second day, the images begin to fail so I will try again tomorrow.

Validation is very time consuming because you have to be there to start the process for every file in the image. It would be nice to have a batch file or some other way to start the validation process and have it validate all the files in the folder so that we don't have to either sit and watch or come back every 15 minutes and start the cycle over on the next file in the image set.

[seekforever]

-{ Quote: "...

Validation is very time consuming because you have to be there to start the process for every file in the image. It would be nice to have a batch file or some other way to start the validation process and have it validate all the files in the folder so that we don't have to either sit and watch or come back every 15 minutes and start the cycle over on the next file in the image set." }-

I don't think that is correct. Just select backup1.tib and TI will verify the entire archive AFAIK. I don't think you have to select the first image file just any one in the set. The verification utility verifies the ARCHIVE.

[Menorcaman]

-{ Quote: "I don't think that is correct. Just select backup1.tib and TI will verify the entire archive AFAIK. I don't think you have to select the first image file just any one in the set. The verification utility verifies the ARCHIVE." }-Hi seekforever,

You are absolutely right. Select any .tib file from a particular archive set and TI will validate the whole image in one go. No need to repeat the validation for each individual .tib file in the set.

Regards

[seekforever]

Hi Menorcaman,

Thanks for the confirmation. It will be interesting to see what happens with his images in time but DCM certainly has given them a good dose of verifying by selecting each tib file! :)

[DCM]

I have been checking the two identical images every day. So far, neither of the images has corrupted as has happened in the past. Maybe the newest version has solved the problem of deteriorating images.

The original was created on an external USB 2.0 drive and after verification, copied to an internal hard drive (second of two IDE internal hard drives in computer).

[seekforever]

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.

[bobn27613]

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

[seekforever]

-{ Quote: "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?

[bobn1]

version 9.0;build 2302

[bobn1]

i can still have access from windows

[bobn1]

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

[DCM]

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.

[Acronis Support]

Hello bobn1,

Thank you for choosing Acronis Disk Backup Software (http://www.acronis.com/homecomputing/products/trueimage/).

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 (http://www.wilderssecurity.com/showthread.php?t=55317).

Please create an account (http://www.acronis.com/homecomputing/my/registration/), then log in (http://www.acronis.com/homecomputing/my/) and submit a request for technical support (http://www.acronis.com/homecomputing/my/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

[DCM]

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.

[seekforever]

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.

[DCM]

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

[seekforever]

-{ Quote: "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.

[[H]omer]

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.

[b00sfuk]

-{ Quote: "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).

[[H]omer]

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. :ouch:

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.

[DCM]

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.

[tachyon42]

-{ Quote: "I just ran a checksum calculator test and all three lines of the results were different than the original tib file." }-
Are you saying that the checksum on that tib file is different from the checksum done previously on the same file?

[seekforever]

-{ Quote: "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." }-

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).

[tachyon42]

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?

[[H]omer]

-{ Quote: "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." }-

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.

[DCM]

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

[b00sfuk]

-{ Quote: "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 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.

[DCM]

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.

[Menorcaman]

-{ Quote: "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> (http://oca.microsoft.com/en/windiag.asp), which is easy to use and might be worth trying. Also, I have heard that running the Mersenne prime generator <Prime95> (http://www.mersenne.org/freesoft.htm) is a really good test of your hardware but isn't so easy to set up/use and can take a long time.

Regards

[seekforever]

-{ Quote: "... TI9 just stresses the hardware more - though I would have thought that some type of error checking/correction could be used to compensate." }-

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.

[b00sfuk]

-{ Quote: "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.
Reply With Quote" }-

My system would pass Memtest for days on end with no problem. The only test I found that gave errors in parallel with TI9, as I said earlier, was Prime95 (under Windows). I ran the blend test and it would rarely get past 5-10 mins without a rounding error. I suggest you get Prime95 - you might need to run the custom test (instaed of blend) and reduce the memory usage parameter a little if you get disk paging with the default blend test. If you are unfamiliar with Prime95 then google is your friend as there are guides about - just remember to set priority to 10 (password 9876) and select tests via the torture test menu.

Best of luck.

[seekforever]

-{ Quote: "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." }-

Try the other ones suggested but you may be able to get a better test with Memtest86+ (possibly). My experience with marginal memory problems shows that the more often are seen when you do a random test rather than bit-walks, and fixed patterns.

Run memtest86+ again but limit the test to the random data. If you have 2 sticks, pull out one and let it really flog one stick at a time as well as both together.

I had a problem on my system with some new Corsair good stuff. The Memtest errors reported were very infrequent to say the least. Swapping the sticks around wouldn't even let the PC boot!

I put the memory in a different system and the error-rate probably increased 10 times. My point is that marginal memory errors can really depend on the operating environment.

While the tests are running think about external factors that may be causing a problem too. Things like it happens at peak electrical load times (supper time) when the line voltage may sag, noisy electrical equipment running near or on the same circuit as the computer (vacuum cleaners for example) etc. If there is a correlation to things like this then your power supply is probably poor.

[b00sfuk]

seekforever, I agree with everything you say. I was not really thinking though about error correcting at the hardware level. It was more with the software in the way that TI9 doublechecks what was written to the image file at the time of writing; it is just essentially a diskcopy and the software does not crash as a result of the memory problem. I guess there is a good technical reason behind the way it works - it might just be to avoid making the backup twice as long to complete!
Additionally it should be noted that the problem might not be because the RAM is faulty but instead that it is being run out of spec: either too fast or with too agressive timings. It is always worth testing by relaxing the memory timings, using a memory divider, upping the voltage to the DIMMS etc. (with the relevant disclaimer when adjusting any BIOS values).

[seekforever]

IIRC from what Acronis posted some time ago, the TI image verify does not compare contents of the image to the disk. If it did for one thing it couldn't compare C since the image is made from a snapshot and also you couldn't compare the contents of any drive say a week later because of changes. The TI verify by some scheme goes through the image file making sure it can read it and comparing checksum(s?) it calculates with the ones stored in the image file.

I agree that the problem could be RAM run out of spec but I think DCM said previously that was not the case. However, he could try relaxing the timings - it could be he is running the proper specs but the MB design is marginal and TI is pushing it. Interestingly, I stumbled across a Microsoft Knowledge Base article mentioning memory spec problems when random file copy errors.

A voltage increase might help as well. I am running an older Asus A7A266 with the memory pushed a little. It conveniently had a jumper that permitted an extra 0.1V on the DDR memory. Without the extra voltage it won't run reliably at my settings.

Since his system is old in computer terms he might be able to get some 2nd hand RAM pretty cheap to try. He hasn't said if he has 2 sticks; IMO it would a good thing to try one and then the other.

[x=y+z]

Certainly MemTest86+ is not only the memory test tool anyone should rely on. It is a very useful tool for initial memory testing before booting to Windows. I would not attempt to boot into Window if MemTest86+ failed as memory errors could corrupt files and registry. If MemTest86+ passes, it is reasonably safe to boot to Windows. However memory could still unstable in the Window environment. There is a Windows based memory test tool HCI Design Memtest. It could find memory errors in Windows where as Memtest86+ passed in the non-Windows environment.

When I overclocked my PC I always ran the following stress tests to check system stability after I changed FSB frequency, voltage, memory timing, etc.

1) MemTest86+ (at least 8 hours)
http://www.memtest.org/

2) HCI Design Memtest with “All unused RAM” option to avoid paging (at least 8 hours)
http://hcidesign.com/memtest/
While HCI Memtest is running to test memory, CPU is also fully utilized (100%).

3) Prime95 (at least 8 hours)
http://www.mersenne.org/freesoft.htm

To run Prime95, simply start Prime95 and select Torture Test with “Blend” option or custom option to stress CPU and Memory.

4) Super PI (select 32M calculation)
http://files.extremeoverclocking.com/file.php?f=36

[DCM]

Before removing Acronis, I thought it might be a good idea to "validate" all my remaining image sets. There are six of the image sets dating from April 4, 2006 back to November 16, 2005. All of them are OK according to Acronis True Image Validating tool.

The images are on internal and external drives as were the two recent images that failed after five days. I had two identical image sets on two different drives (one internal and one USB 2.0) and they both failed and the checksum program indicated corrupt files (so does Acronis).

The difference between these images and the two recent ones that failed (many others have failed too in the past) is that these images were split into 700 MB files while the ones that have failed have all been larger to fit on DVD's and just the default size with no splitting other that what they do by default.

The thing that bothers me about this is that these images that go back six months (November 2005) or so and continue up through the present (April 4, 2006) did not get corrupted while almost all of my recent images did corrupt after sitting a while. It seems like they too should get corrupted if I had a hardware problem or a software conflict.

One exception to the recent files corrupting is one that I did on April 4, 2006 but it is one that is broken up into 700 MB files and it also tested OK today and several other times over the last few weeks.

The ones going back to November 2005 have been tested many times without corrupting so I do not think that testing them is causing the problem.

Maybe there is something in the program that is not dealing properly with large file sizes.

[seekforever]

-{ Quote: "Before removing Acronis, I thought it might be a good idea to "validate" all my remaining image sets. There are six of the image sets dating from April 4, 2006 back to November 16, 2005. All of them are OK according to Acronis True Image Validating tool.

The images are on internal and external drives as were the two recent images that failed after five days. I had two identical image sets on two different drives (one internal and one USB 2.0) and they both failed and the checksum program indicated corrupt files (so does Acronis).

The difference between these images and the two recent ones that failed (many others have failed too in the past) is that these images were split into 700 MB files while the ones that have failed have all been larger to fit on DVD's and just the default size with no splitting other that what they do by default.

The thing that bothers me about this is that these images that go back six months (November 2005) or so and continue up through the present (April 4, 2006) did not get corrupted while almost all of my recent images did corrupt after sitting a while. It seems like they too should get corrupted if I had a hardware problem or a software conflict.

One exception to the recent files corrupting is one that I did on April 4, 2006 but it is one that is broken up into 700 MB files and it also tested OK today and several other times over the last few weeks.

The ones going back to November 2005 have been tested many times without corrupting so I do not think that testing them is causing the problem.

Maybe there is something in the program that is not dealing properly with large file sizes." }-

Hi DCM,
I am not totally clear on whether or not all 700MB images always test OK or not.

However, some comments on the above. The recent images that failed tested good by TI previously then failed. To me this would indicate they were done correctly but something has happened to either the system or them. Interestingly the checksums calculated by XCSC are also different which IMO rules out TI.

The bad checksums can be caused by the actual file getting damaged on disk but this is unlikely since it has happened to two copies on different disks. XCSC may not be calculating the checksum properly because of a hardware, likely memory, error. Since I don't know how the TI does its verify I shouldn't speculate but I could easily speculate that a big file might cause TI to set up a larger area in memory to verify the image or calculate a checksum - this might cause a bad location to be used only when doing a large file. Like I said, that is speculation.

I am not aware of reports on the forum complaining of bad verifies on large files and OK on small files. The fact that TI did verify the files as OK in the past doesn't really support that it has a coding error for large files. When this is combined with XCSC getting different checksums now than it did when the files were "good" also doesn't support a TI coding error.

When you run the XCSC program on the identical file but on different drives do you get the same checksum for each file but different from the original "good" checksum?

[DCM]

I cannot check the checksum on those two files because I deleted one of them.

Your explanation seems reasonable so I will probably just give up this program until I have a new computer or may keep creating small ones with a backup using Ghost.

Within the last few weeks someone on this forum said that their only stable files were the smaller ones and that is why I started creating both sizes. I was hoping that the solution would be that easy.

I would prefer larger ones but will take any size that is stable.

The only problem that I have encountered with the small ones happened a long time ago but recently with large files and that is the "Cannot find volume 1, insert media' or something similar to that. When that happens and the entire backup is in one folder on a hard drive, it doesn't leave much room to fix the problem. The program will not allow you to select another file to act as "Volume 1".