Ahh, If the system is able too the memory dump should be stored by default %SystemRoot%\ (
http://maximumpcguides.com/windows-7/set-windows-7s-memory-dump-file-location/ ). *Sometimes* the system may not be able to create a memory dump (usually its configuration like not enough page pool to hold the memory content etc, or sometimes a hardware based error where it just can not be completed.)
If you RMA'd a part and its not happening now cool, you can probably move on
🙂 otherwise I tried to explain a little bit below of what to look for etc. And memory check, is a seperate thing, this is instructions for a Memory Dump analysis or basic forensics on a crash. For something to test memory like RAM you would probably want to use
http://www.memtest86.com/ (You burn a boot disk, boot into the tests.) Or you can grab something like
http://www.ultimatebootcd.com/ UMBCD has a memory test option.
---Checking out the .dmp ---
If you see the files in there you just open windbg ( usually found at c:\program files\debugging tools for windows ) start it, set the symbol path to the MS symbols or download them for your OS on msdn or the same area you got windbg and point the symbol path there ( I like http so it grabs what it needs / dump file ).
Then run .reload /f; !analyze -v :
It will spit out a wall of text - The junk under **** Bugcheck Analysis **** will be what your looking for, "Probably caused by : ntkrnlmp" (This is just an example)
and at the bottom it will do: "MODULE_NAME: ntkrnlmp" that gives you an idea of the faulting module. It might be a link in blue click it and get more info etc. So in that short example we know its a OS item ntkrnlmp so the next step would be to check for hotfixes / updates for the OS.
I hope that clears it up.