New
#21
I have the exact opposite experience, just fyi. But yes, testing isn't a bad idea anyway. Given there are really a very small number of major DRAM manufacturers in the world (less than 10, and only the top 3 or 4 supply most of the world's DRAM), it's possible to get bad RAM from just about every manufacturer that makes RAM sticks.
Well, the worst that could happen would be to have defective RAM and have to RMA it. Otherwise, you'll find your RAM is fine, and at least it will be ruled out.
so where does go to properly learn to to troubleshoot like you guys do?
i would absolutely hate to learn to read a .dmp the hard way...
Well, debugging takes (generally speaking) knowledge of the product being debugged, the ability to read and understand native code in C or C++ (and also managed code, if debugging a .net application), and then, practice and research. There are books that are available that can help you along the way - books like Advanced Windows Debugging, Advanced .NET Debugging, and Windows Debugging:Practical Foundations, Windows Internals 4th and 5th editions (soon to be a 6th), and books like Programming Windows and Programming .NET. Also, being a regular visitor of sites like Dmitry Vostokov's Crash Dump Analysis, Alex Ionescu's Blog, Scott Noone's Analyze-V blog, the ASKPERF site, ntdebugging, Mark Russinovich's blog, and Raymond Chen's Old New Thing are also good once you start down this road.
However, without prior knowledge of the subject matter, development, and practice, it is indeed like doing it "the hard way". It's not so much a science as an art that has defined structure that you can practice and get better at, really.
I am not entirely sure the problem is fixed, but I removed one of my 4gig sticks of ram and haven't crashed in the past 27 hours, I am not positive it is fixed. I will keep you posted, thanks for the help thus far!
Fair enough - if you can go a week without crashing, I think it would be safe to consider that you've found the problem.