I get inconsistent unRar checksum errors

Page 2 - Seeking answers? Join the AnandTech community: where nearly half-a-million members share solutions and discuss the latest tech.

redzo

Senior member
Nov 21, 2007
547
5
81
My 4x8GB Crucial memory outputs only one error in memtest86+ but only after at least 3 days of continuous memtest86+ running. That is why I always insist in running memtest86+ for as long as possible. But I admit that rarely in a few cases it fails to deliver. I had a few scenarios when the memory was the cull print, but memtest86+ still reported 0 errors after a very long run.
 
Dec 30, 2004
12,553
2
76
My 4x8GB Crucial memory outputs only one error in memtest86+ but only after at least 3 days of continuous memtest86+ running. That is why I always insist in running memtest86+ for as long as possible. But I admit that rarely in a few cases it fails to deliver. I had a few scenarios when the memory was the cull print, but memtest86+ still reported 0 errors after a very long run.

that's....insane. ha. and then how are you supposed to figure out which stick it was!!! ???
 
Last edited:

redzo

Senior member
Nov 21, 2007
547
5
81
FYI, 'culprit' :)

:p Chrome's spell checker has a mind of its own sometimes.

that's....insane. ha. and then how are you supposed to figure out which stick it was!!! ???

I do not know which one is it. It takes me too much time to figure it out. It could also be a scenario where the symptom manifests itself only when all of the modules are installed. After one week of troubleshooting I got pretty upset and applied a stupid fix that works: I've added "+ something" to all the stock ram timings and now everything runs fine. The irony is that they are stable when OC'ed and with more relaxed timings and unstable when running at stock SPD settings.
 

mikeymikec

Lifer
May 19, 2011
20,314
14,980
136
Test one module at a time. The less memory being checked, memtest86 will test it more quickly.
 

flexy

Diamond Member
Sep 28, 2001
8,464
155
106
What I would do, download some things off the net where you know the CRC checksum, say, some Windows ISO files or Linux distributions.

There is a tool called "hashtab", with it you can then, after you downloaded the file, check the hash of the locally downloaded file and compare to the official given hashes.

This could possibly show some problems with your SSD or even some weirdness with your network adapter (which is also a possibility)..... or maybe copy back and forth a large file like an ISO with a known hash...and then double check the hash with the hashtab tool after a few times copying . Just an idea...

Also..if he already ran memtest86 and it didn't throw errors we can halfway confidently say the memory should be fine. (Assuming he is not overclocking)
 
Dec 30, 2004
12,553
2
76
What I would do, download some things off the net where you know the CRC checksum, say, some Windows ISO files or Linux distributions.

There is a tool called "hashtab", with it you can then, after you downloaded the file, check the hash of the locally downloaded file and compare to the official given hashes.

This could possibly show some problems with your SSD or even some weirdness with your network adapter (which is also a possibility)..... or maybe copy back and forth a large file like an ISO with a known hash...and then double check the hash with the hashtab tool after a few times copying . Just an idea...

Also..if he already ran memtest86 and it didn't throw errors we can halfway confidently say the memory should be fine. (Assuming he is not overclocking)

Thanks for that, I'll try that on the SSD. I'm still skeptical of its reliability.

Ok I reran memtests all night--

it's the PNY RAM I got after rebate from tigerdirect on slickdeals. Both sticks, consistently in the same address ranges and on the same bits, and individually with no other RAM.

weird things from the memtest-- didn't matter which order (slots) the sticks were installed in in the motherboard, they were still addressed in the same order. These PNY sticks were always the last 16GB of address space. While I was testing all night I was trying to figure out why Memtest couldn't tell you "it's the stick in slot 4 because it's at 30-32GB address range when I discovered this.
 
Last edited:

Auric

Diamond Member
Oct 11, 1999
9,591
2
71
Confirm the specified RAM voltage is reported as supplied (not just set correctly) and if so replace under warranty if possible but otherwise (or anyway for giggles) try increasing. Less likely, but also a potential source of problems is the slot priority -which may be counter intuitive so check the manual (i.e. populate A2 & B2 first). Finally, to really minimise issues, use memory from the motherboard's supported or qualified vendors list.

I wonder how likely such errors can cause corruption to existing data (i.e. as read and written/updated)?
 

flexy

Diamond Member
Sep 28, 2001
8,464
155
106
>>
Both sticks, consistently in the same address ranges and on the same bits, and individually with no other RAM.
>>

Sry what, so the sticks throw errors in memtest?
 
Dec 30, 2004
12,553
2
76
>>
Both sticks, consistently in the same address ranges and on the same bits, and individually with no other RAM.
>>

Sry what, so the sticks throw errors in memtest?

yes, the PNY ones did last night. both of them. I didn't think PNY could suck THAT bad. These were rebate RAMs. maybe this is why
 

bononos

Diamond Member
Aug 21, 2011
3,928
186
106
Whats if its the problem with the memory controller on the cpu? Do you have another ram stick for testing?
 

flexy

Diamond Member
Sep 28, 2001
8,464
155
106
you running the memory at stock speed/timings? Try to increase voltage a notch?
 

redzo

Senior member
Nov 21, 2007
547
5
81
Thanks for that, I'll try that on the SSD. I'm still skeptical of its reliability.

Ok I reran memtests all night--

it's the PNY RAM I got after rebate from tigerdirect on slickdeals. Both sticks, consistently in the same address ranges and on the same bits, and individually with no other RAM.

weird things from the memtest-- didn't matter which order (slots) the sticks were installed in in the motherboard, they were still addressed in the same order. These PNY sticks were always the last 16GB of address space. While I was testing all night I was trying to figure out why Memtest couldn't tell you "it's the stick in slot 4 because it's at 30-32GB address range when I discovered this.

You're on the right track. At least you are now sure that RAM memory corruption is what's happening. Unfortunately, I believe you still can't eliminate the cpu since the memory controller is located on the cpu die.
From what I know, memtest errors are almost impossible to debug. I believe that the dev's themselves say so. Trying to identify which module is broken is also nasty. I think that it is easier for you to just rma the memory and let the service support guys do the "math" for you. Then you are left with the possibility that the cpu might be broken, but you should clarify that with additional testing after your rma'ed modules get back. Good luck!
 

Idontcare

Elite Member
Oct 10, 1999
21,110
59
91
You're on the right track. At least you are now sure that RAM memory corruption is what's happening. Unfortunately, I believe you still can't eliminate the cpu since the memory controller is located on the cpu die.
From what I know, memtest errors are almost impossible to debug. I believe that the dev's themselves say so. Trying to identify which module is broken is also nasty. I think that it is easier for you to just rma the memory and let the service support guys do the "math" for you. Then you are left with the possibility that the cpu might be broken, but you should clarify that with additional testing after your rma'ed modules get back. Good luck!
redzo, soccerballtux verified he doesn't get the same errors when using other ram sticks:
other ram sticks with same addressing and in same mobo slots are fine, so I think not
That would rule out everthing (mem controller, mobo pcb traces, etc) but the ram sticks which cause the errors, right?
 
Dec 30, 2004
12,553
2
76
You're on the right track. At least you are now sure that RAM memory corruption is what's happening. Unfortunately, I believe you still can't eliminate the cpu since the memory controller is located on the cpu die.
From what I know, memtest errors are almost impossible to debug. I believe that the dev's themselves say so. Trying to identify which module is broken is also nasty. I think that it is easier for you to just rma the memory and let the service support guys do the "math" for you. Then you are left with the possibility that the cpu might be broken, but you should clarify that with additional testing after your rma'ed modules get back. Good luck!

so, I was getting REALLY bizarre crashes and locks

  1. doing nothing at idle
  2. when I'd set up prime95 to use 20GB of RAM on a custom test, and
  3. sometimes when Speedfan would scan the ISA bus at $220 or some address

Since removing the offending sticks, no more problems at all.
BTW, it was different address ranges on the 2 sticks of RAM-- but it was consistently within the same range on both.

Yes, RMA'ing.

-PNY does not cross ship
-and is not interested in paying for me to ship it to them

the older I get the less I am tolerating this stuff as, honestly, it's completely unacceptable to have $150 worth of RAM be faulty straight from the factory. It's not that expensive to have someone run around plugging in sticks all day going around the room round robin and letting them warm up to operating temp before considering them 'good'. It's been years since I had to troubleshoot anything that wasn't overclocking related (and I've never overclocked RAM) and so I had to re-learn over again how to figure this stuff out. For example, I saw these errors 4 weeks ago and wrote it off as mobo issues because when I hard-power-cycled the motherboard, no more problems. I must have gone off to the bathroom or taken a shower when I did that because the offending variable was operating temperature, not power cycling. I had been focusing on instability and something wonky in the motherboard-- for example, using WakeOnLAN from suspend would destroy the CPU-voltage LLC functions and the night before I RMA'd the board when it booted into Windows it gave the CPU 1.6v after a prime95 run. Yikes!!!! Some other guy on an Intel motherboard reported the exact same issue after WakeOnLAN btw. Additionally, the VRM protecting code that throttles the CPU, would consistently cause the machine to lock up either immediately on throttle down, or if it made it, usually on return to non-throttled speeds. Ridiculous!!! Everything went down hill with UEFI bring back the blue screen with white/yellow font everything worked predictably and consistently back then :( :mad: :mad: :mad: ():) :)

what I'm saying is PNY was at fault and so was Asus on several levels for the motherboard, and between the two's shoddy testing standards I wasted a month figuring out their problems, so the least they should do is cover return shipping. I should bill them for the time discovering the defects.
 
Last edited:

Idontcare

Elite Member
Oct 10, 1999
21,110
59
91
the older I get the less I am tolerating this stuff as, honestly, it's completely unacceptable to have $150 worth of RAM be faulty straight from the factory. It's not that expensive to have someone run around plugging in sticks all day going around the room round robin and letting them warm up to operating temp before considering them 'good'.

Its happened to me before as well. No idea what the quality control is like, but sometimes there are good reasons why certain brands cost more $/GB for ram than other brands.

It isn't always because that brand wants to make more profit, the kits cost more because their cost structure is higher because they pay more expenses for a more robust QRA program.

The more you, the consumer, are willing to take on the burden of essentially owning a bigger portion of the QRA program (how much do you value your time versus your money), the memory is going to cost less to produce and get to your door. But at an elevated risk that you are going to be doing some QRA.