Hello, I'm trying to troubleshoot a problem with my laptop and am stuck because I don't know how to read the information in the dump file. This is my situation: 1. In the last few weeks my laptop has been shutting down unexpectedly with the following error message when I restart again: BCCode : 1000007f BCP1 : 0000000D BCP2 : 00000000 BCP3 : 00000000 BCP4 : 00000000 OSVer : 5_1_2600 SP : 2_0 Product : 256_1 2. After using google on the above error, I figured out that this was possibly an issue with my RAM. It was at this time I realized that only 512 MB of my 1024 GB installed in my laptop was showing up in my system information 3. I took apart my laptop...and by testing each one individually...found out that one stick wasn't working at all. I kept this one out and put my laptop back together with the one that seemed to be ok 4. However, after restarting my laptop and working on it for about 20 minutes...I get the blue screen of death with the error outlined above resulting. 5. I researched some more and downloaded the memtest86 program. Burned the ISO image and booted my laptop. However, half way through the test sequence, my laptop shut off again (ok, at this point I'm pretty sure it is a problem with my last remaining RAM stick. As I said, the other one appeared to be completely dead) 6. Not wanting to accept the fate of having to buy new ram...I researched some more 7. Eventually figured out how to locate my minidump folder and accessed the last couple of dump files. 8. Downloaded Windows Support Tools for SP2 in order to gain access to the dumpchk.exe tool. 9. I was able to open the dump file...but then realized I had no idea what any of the information I was looking at meant. So that is where I'm at right now. I know it is probably an issue with my RAM, but I was wondering if someone could take a look at my dmp files to let me know if there could be anything else going wrong. I uploaded them to my webhost. Here are the links to the last 3 dump files: http://www.logicalinsanity.net/minidump/Mini091605-04.dmp http://www.logicalinsanity.net/minidump/Mini091605-03.dmp http://www.logicalinsanity.net/minidump/Mini091605-02.dmp Thanks in advance to anyone who can help me figure this out!

I'm sleepy at the moment, but figured I'd run the dump files through my debugger and see what popped out. I'll have to look through it deeper tomorrow. Below I posted what my analyzer showed (probable cause and analysis follows their respective url). And for your information, bad memory slots (yes, they do go bad) and bad memory can produce a variety of crashes/blue screens. I've seen it first hand (dimm slot 3 on my pc is bad). http://www.logicalinsanity.net/minidump/Mini091605-04.dmp Probably caused by : memory_corruption PFN_LIST_CORRUPT (4e) Typically caused by drivers passing bad memory descriptor lists (ie: calling MmUnlockPages twice with the same list, etc). If a kernel debugger is available get the stack trace. Arguments: Arg1: 00000007, A driver has unlocked a page more times than it locked it Arg2: 0001d7ee, page frame number Arg3: 0001b6ad, current share count Arg4: 00000000, 0 http://www.logicalinsanity.net/minidump/Mini091605-03.dmp Probably caused by : win32k.sys UNEXPECTED_KERNEL_MODE_TRAP_M (1000007f) This means a trap occurred in kernel mode, and it's a trap of a kind that the kernel isn't allowed to have/catch (bound trap) or that is always instant death (double fault). The first number in the bugcheck params is the number of the trap (8 = double fault, etc) Consult an Intel x86 family manual to learn more about what these traps are. Here is a *portion* of those codes: If kv shows a taskGate use .tss on the part before the colon, then kv. Else if kv shows a trapframe use .trap on that value Else .trap on the appropriate frame will show where the trap was taken (on x86, this will be the ebp that goes with the procedure KiTrap) Endif kb will then show the corrected stack. http://www.logicalinsanity.net/minidump/Mini091605-02.dmp Probably caused by : ntoskrnl.exe IRQL_NOT_LESS_OR_EQUAL (a) An attempt was made to access a pageable (or completely invalid) address at an interrupt request level (IRQL) that is too high. This is usually caused by drivers using improper addresses. If a kernel debugger is available get the stack backtrace. Arguments: Arg1: 82437190, memory referenced Arg2: 0000001c, IRQL Arg3: 00000001, value 0 = read operation, 1 = write operation Arg4: 804e163c, address which referenced memory

How to Gather Information After a Memory Dump in Windows XP http://support.microsoft.com/default.aspx?scid=kb;en-us;314084 Minidump Files http://msdn.microsoft.com/library/default.asp?url=/library/en-us/debug/base/minidump_files.asp In that article it says Microsoft® Office XP and Windows® XP create minidump files for the purpose of analyzing failures on customers' computers. It is used by technical people to find causes of problems.

Thanks for looking into this for me. I'll admit that a lot of what you wrote was like greek to me...but I really do want to understand. With that said...I feel like a putz for even asking (as you probably already made it clear in your reply but I'm just not getting it) ...but the main problem I'm having with my PC crashing is most likely bad RAM? I ordered new RAM this morning. Also, I ran memtest86 again and it was able to generate 81 errors in test 5 before my laptop shut off this time. On a different note...I find all of this stuff incredibly interesting and genuinely would like to learn more about how to do these types of things on my own. Is there a no-nonsense "debugging XP for dummies" type of resource out there somewhere? Specifically...something that tells me what the various numerical codes are I see in the dump file? Sorry if these are goofy questions...but I truly am a novice in this aspect of computing.