Version 9 Corrupt images again

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.

 

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.

 

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

 

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.

 

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

 

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?

 

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