BSODs - Motherboard or PSU?

Chrheff said:

Hello,

I checked the motherboard and there's no sign of any problems with the capacitors. The fact the RAM is failing in the 2,4 slots, though, means it might be the RAM as well, since I originally figured it wasn't because it would function there. In memtest86, the same area on the RAM fails each time - 960.2MB. Sort of dumb to only point this out now, but it's been a while since I've gone back to memtest testing. I can't remember the exact addresses but there're two that seem to have problems.

Next time it crashes I'll let it sit unplugged, but I'm going to run it on each stick individually for a few days and see if it crashes.

It could indeed be the RAM after all - is the failing address always in a particular test# ?

Dwarf said:

It's going to take some time, but when you run it on one stick, don't forget to repeat the test with the stick in each slot.

As tedious as this process is, it is one way of ruling out the RAM.

If you are going to format the HDD use Active@ Kill Disk Hard Drive Eraser. Low Level Format. and do a low level format and delete all partitions.

this has all the hallmarks of bad ram

Chrheff said:

The problem is memtest wasn't catching errors consistently. If I power off the system completely for a few hours, it stabilizes for a few days before crashes resume, and in that time I don't detect any memory errors on memtest86. I figured if it was the RAM, memtest would consistently detect problems rather than the random stuff I'm dealing with now. Still, not many other options at this point. I'm going to borrow some RAM from a friend first I think.

memtest won't in fact there isn't a totally definitive ram test that ever stresses and uses the ram like an O/S will ........

to quote since windows 95 Microsoft have stated about memory testing programs

Defective memory chips may not be detected by memory checking tools. Some memory checking programs are not adequate tests because they do not test RAM in the same way that Windows uses RAM. Most memory checkers use read/write cycles when scanning memory. Since Windows is executing code from memory, it uses execute cycles. Execute cycles are different from read/write cycles and are more vulnerable to parity errors. It is possible for memory checking programs to find parity errors if the memory is extremely faulty.

so bottom line is changing the hardware component is the best way of totally isolating it as a fault