Dual-Channel RAM causes BSOD?

[Mike]

A couple weeks ago I built a computer with the Asus A8n-E (nForce 4
Ultra based) motherboard, an Athlon 64 3200+, and 2x512 sticks of OCZ
DDR400 Value Series RAM, set up for Dual-Channel. I installed Windows
without problems, but after a few days I got a blue screen error (I
think it was IRQL_NOT_LESS_OR_EQUAL, or something similar). After this I
could not longer boot into Windows, and I tried to reinstall. I got an
error that "Setup was unable to copy <filename>", and this gave
different files each time I tried to install. Eventually I got a tip
online that it might work if I removed one stick of RAM.
It worked, but now I'm left with 512 megs installed and 512 megs sitting
on a shelf. Can anybody give me any advice on how to fix this, or at
least why it happens?
Just to preempt one of the things that is sure to come, I have already
run memtest86 with no errors.

Thanks in advance.

 

[Guest]

Add 2 more sticks of 512,giving you 4 total and dual channel will start
to work for you.

 

[DL]

Called/mailed OCZ? their support is supposed to be reasonable.
You may need to manually amend bios memory settings, and OCZ are the best
people to advise.

 

[cquirke (MVP Windows shell/user)]

Add 2 more sticks of 512,giving you 4 total and dual channel will start
to work for you.

Hint: Must use slots in same bank, else not dual-channel. No need to
fill all the slots; just two of the right ones

Did you run MemTest86 on all tests, overnight?

Memory test software tests how the CPU access RAM. There's a
possibility that something other than the CPU may access RAM (via DMA)
slightly differently, either in terms of timing, or distance to the
nearest electrolytic cap. All it takes is a square pulse edge that
takes too long to slew from one state to another, and the ball is
dropped. Do that 1 in a million times, crash every day at least.

But the other possibility is that the flaw isn't in the RAM at all.
RAM and HD are the only really testable things, so we tend to look
there, but it good be flaky mobo, hot processor, unggood SVGA, etc.

Check for bad caps and make sure you are not overclocking.

I'd also verify that your installation disk is OK, and that the axis
through which it reaches the HD is OK. One way to do this, is to get
another exact-same CD (same OS version and edition). Copy each of
these to the HD, twice. Run an FC on them vs. thier own copies, vs.
the CD, vs. each other. State chart the results.

I'd use FC C:\Blah1\*.* C:\Blah2\*.* > C:\FC.TXT
....and then I'd Edit C:\FC.TXT, highlight the recurring "no changes
were found" text, go replace, and replace with nothing. That makes
the file a lot easier to quicly scan for mismatches.

I wish there was an FC that simply noted which files didn't match -
I'm not interested in the differences, just that they are different.
I'd want it to recurse into subdirs as well.

Finally, consider and exclude malware activity. Malware can often
look like a hardware issue, given how flaky much of it is, how it
intends to avoid being noticed, and how it runs all the time.

------------------------ ---- --- -- - - - -

Forget http://cquirke.blogspot.com and check out a
better one at http://topicdrift.blogspot.com instead!

 

[Mike]

Hint: Must use slots in same bank, else not dual-channel. No need to
fill all the slots; just two of the right ones




Did you run MemTest86 on all tests, overnight?

Memory test software tests how the CPU access RAM. There's a
possibility that something other than the CPU may access RAM (via DMA)
slightly differently, either in terms of timing, or distance to the
nearest electrolytic cap. All it takes is a square pulse edge that
takes too long to slew from one state to another, and the ball is
dropped. Do that 1 in a million times, crash every day at least.

But the other possibility is that the flaw isn't in the RAM at all.
RAM and HD are the only really testable things, so we tend to look
there, but it good be flaky mobo, hot processor, unggood SVGA, etc.

Check for bad caps and make sure you are not overclocking.

I'd also verify that your installation disk is OK, and that the axis
through which it reaches the HD is OK. One way to do this, is to get
another exact-same CD (same OS version and edition). Copy each of
these to the HD, twice. Run an FC on them vs. thier own copies, vs.
the CD, vs. each other. State chart the results.

I'd use FC C:\Blah1\*.* C:\Blah2\*.* > C:\FC.TXT
...and then I'd Edit C:\FC.TXT, highlight the recurring "no changes
were found" text, go replace, and replace with nothing. That makes
the file a lot easier to quicly scan for mismatches.

I wish there was an FC that simply noted which files didn't match -
I'm not interested in the differences, just that they are different.
I'd want it to recurse into subdirs as well.

Finally, consider and exclude malware activity. Malware can often
look like a hardware issue, given how flaky much of it is, how it
intends to avoid being noticed, and how it runs all the time.





Forget http://cquirke.blogspot.com and check out a
better one at http://topicdrift.blogspot.com instead!

Thanks a lot for the help, I think I've got it figured out.