[SPAM] - Re: Files are Different Problem - Found word(s) list error XXX in the Text body

[Jerome H. Fine]

 >Brian Wheeler wrote:

>Try running memtest86 on the machine.  It'll give the RAM a thorough
>workout and you'll b eable to isolate whether or not its the RAM which
>is the problem...
>  
>
Jerome Fine replies:

I attempted to search for any WXP programs named *mem*.type and 
*test*.type with
type being exe, com, bat or lnk.  I found only mem.exe which only seem 
to work for DOS.

Can anyone suggest a RAM testing option?

I left the rest of the information and my questions in case anyone else 
can help?

Tony, have you any suggestions?

Sincerely yours,

Jerome Fine

>Brian
>
>
>>On Mon, 2008-09-08 at 11:45 -0400, Jerome H. Fine wrote:
>  
>
>>I spent 3 hours this morning attempting to figure out where to start 
>>looking.
>>The problem shows up as a difference between files which are almost
>>certainly identical - except in one copy which I am confident is different
>>all of the time by the specified byte (caused at the time the copy was 
>>made).
>>
>>Rather than attempting to hide that this is current PC hardware, it is
>>probably best to list:
>>Hardware: Intel E8200 CPU (2.66 GHz), 2 * 2 GB memory in
>>ASUS P5B motherboard with 2 * Seagate 320 GB SATA II hard drives
>>Software: Windows XP  with probably SP3
>>
>>The problem shows up between 5% to 10% of the time with very
>>large files of greater than 1/2 GB to 2 GB in total size.  The command:
>>COPY  /B  D:*.GHO  G:*.GHx
>>was used to create 4 files each time with x = A,B,C,D,E
>>FC  /B  D:*.GHO   G:*.GHx
>>is used to compare the files 4 at a time.  It takes about 2 1/2 minutes to
>>compare the group of 4 files for a total of 5 GB being compared with
>>5 GB (which is why I said it must be current hardware).  The result
>>often (between 5% and 10% of the time) shows a single difference
>>between the files at byte xxxxx35A  (the xxxxx is random but the last
>>3 characters of the address are always the same) with the two hex
>>characters for each byte being different by 1 bit:
>>e.g. 22 vs 32 about 25% of the time with an extra bit 4
>>e.g. 94 vs 84 about 75% of the time with a missing bit 4
>>
>>I probably performed between 75 and 150 FC commands
>>during which about 200 comparisons were made.  I collected
>>about 15 cases when a difference was noted.
>>
>>I can also perform an MD5 valuation of each file.  So long
>>as the available memory is exceeded (relative to the size
>>of the previous files that were just tested), the MD5 valuation
>>takes about 40 seconds for a 2 GB file and the disk sense
>>light is on the whole time.  If the same file is repeated for
>>the MD5 valuation, the disk sense light is always off and the
>>MD5 valuation takes about 9 seconds.  The MD5 valuation
>>is probably incorrect between 5% and 10% of the time.  Since
>>repeating the MD5 valuation on a different copy of the same file
>>provides a cross check, when what seems like an incorrect MD5
>>valuation appears, checking with a different copy will almost always
>>(19 times out of 20) show the correct MD5 valuation, then when
>>the MD5 valuation is redone on the same file, the probably
>>correct MD5 valuation appears, i.e. different from the just previous
>>MD5 valuation on the same file.
>>
>>However, if the MD5 valuation is done again without flushing the
>>cached copy, then the same memory contents seem to be used
>>each subsequent time yielding the same (probably incorrect if
>>that was the situation) MD5 valuation from the last time that the
>>disk drive was actually read.  My assumption is that as the (now
>>incorrect) byte was read into memory, one of the bytes of RAM
>>(possibly the same one each time) gets an extra bit set or misses
>>one of the bits being set - always that same bit 4 of course.  Other
>>reasons may also have caused the byte in RAM to be incorrect.
>>However, once incorrect, it seems to stay the same until it is
>>modified again.  So it does not seem to be a problem with
>>reading RAM.
>>
>>So (FINALLY) this is my question:
>>
>>If the cached copy (probably incorrect) of a hard drive file (which
>>is used to perform the MD5 valuation) stays
>>the same, what is the probability that it is a problem with RAM
>>memory as opposed to a hard drive or controller error?  Since
>>the error suggests that it is a single bit causing the problem (the
>>same bit seems to be either on or off), my intuition would seem
>>to suggest that the RAM memory has a problem.  However, since
>>my hardware experience is minimal, I am asking for suggestions
>>as to what can be done and the order they should be attempted:
>>(a)  Replace the RAM memory
>>(b)  Replace the disk drive(s)
>>(c)  Replace the motherboard with the controller problem
>>(d)  Something else I have not thought of
>>
>>I know that Tony Duell would want to fix the component, but
>>I doubt that is even possible in this case.
>>
>>Does anyone have any different suggestions?
>>
>>Thank you for any help and please suggest any different tests
>>that might help to locate or better identify the cause of the problem.
>>
>>Finally, just to make sure, does this problem constitute a serious
>>difficulty which should (must?) be fixed before any actual use is made
>>of this new system?
>>