Evening all, I just recently built a custom computer and have been experiencing the dreaded BSoD. I just recently got the debugging tools so I can post the results of the memory dump. I can say I have been getting this BSoD since first installing, and have used common tools such as Intel Burn Test and Prime95 to verify hardware stability, not to entirely rule out hardware fault. Out of 4 build so far this year, this is the only one to be frequented by the BSoD. All drivers are up to date, motherboard came with the latest bios. Any and all help is greatly appreciated, thanks in advance =) Loading Dump File [C:\Users\Joey\Desktop\MEMORY.DMP] Kernel Summary Dump File: Only kernel address space is available Symbol search path is: SRV*f:\localsymbols*http://msdl.microsoft.com/download/symbols;D:\Symbols Executable search path is: Windows 7 Kernel Version 7600 MP (4 procs) Free x64 Product: WinNt, suite: TerminalServer SingleUserTS Built by: 7600.16617.amd64fre.win7_gdr.100618-1621 Machine Name: Kernel base = 0xfffff800`02e06000 PsLoadedModuleList = 0xfffff800`03043e50 Debug session time: Sun Oct 24 12:04:03.256 2010 (UTC - 4:00) System Uptime: 1 days 3:44:00.184 Loading Kernel Symbols ............................................................... ................................................................ .................................. Loading User Symbols PEB is paged out (Peb.Ldr = 000007ff`fffd7018). Type ".hh dbgerr001" for details Loading unloaded module list ........ ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* Use !analyze -v to get detailed debugging information. BugCheck A, {4a, 2, 1, fffff80002f28b1f} Probably caused by : memory_corruption ( nt!MiIdentifyPfn+26f ) Followup: MachineOwner --------- 1: kd> !analyze -v ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* 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: 000000000000004a, memory referenced Arg2: 0000000000000002, IRQL Arg3: 0000000000000001, bitfield : bit 0 : value 0 = read operation, 1 = write operation bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status) Arg4: fffff80002f28b1f, address which referenced memory Debugging Details: ------------------ WRITE_ADDRESS: 000000000000004a CURRENT_IRQL: 2 FAULTING_IP: nt!MiIdentifyPfn+26f fffff800`02f28b1f f0410fba6e481f lock bts dword ptr [r14+48h],1Fh DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT BUGCHECK_STR: 0xA PROCESS_NAME: svchost.exe TRAP_FRAME: fffff880063ee4f0 -- (.trap 0xfffff880063ee4f0) NOTE: The trap frame does not contain all registers. Some register values may be zeroed or incorrect. rax=0000000000000001 rbx=0000000000000000 rcx=0400000000000020 rdx=0000000000193916 rsi=0000000000000000 rdi=0000000000000000 rip=fffff80002f28b1f rsp=fffff880063ee680 rbp=fffffa8006f41280 r8=0000000000193a62 r9=0000000000000001 r10=0000000000000042 r11=0000058000000000 r12=0000000000000000 r13=0000000000000000 r14=0000000000000000 r15=0000000000000000 iopl=0 nv up ei pl nz na po nc nt!MiIdentifyPfn+0x26f: fffff800`02f28b1f f0410fba6e481f lock bts dword ptr [r14+48h],1Fh ds:00000000`00000048=???????? Resetting default scope LAST_CONTROL_TRANSFER: from fffff80002e75ca9 to fffff80002e76740 STACK_TEXT: fffff880`063ee3a8 fffff800`02e75ca9 : 00000000`0000000a 00000000`0000004a 00000000`00000002 00000000`00000001 : nt!KeBugCheckEx fffff880`063ee3b0 fffff800`02e74920 : 00000000`42506650 02000000`000da609 00000000`00000000 00000000`00000000 : nt!KiBugCheckDispatch+0x69 fffff880`063ee4f0 fffff800`02f28b1f : 00000000`00000000 02000000`0011f63c 00000000`000018c0 fffff800`0313d35b : nt!KiPageFault+0x260 fffff880`063ee680 fffff800`02f297cb : 00000000`00000000 00000000`00000004 fffffa80`07336d18 fffffa80`07336000 : nt!MiIdentifyPfn+0x26f fffff880`063ee720 fffff800`03288595 : fffffa80`07336000 fffff880`063eeca0 fffff880`063ee7f8 00000000`00000000 : nt!MmQueryPfnList+0xbb fffff880`063ee760 fffff800`031cd8b8 : 00000000`00000006 00000000`00000000 fffffa80`07336000 fffff800`02e06001 : nt!PfpPfnPrioRequest+0x115 fffff880`063ee7b0 fffff800`031743c3 : 00000000`00000000 fffff800`02e06000 fffffa80`08fdea50 fffffa80`09b1b701 : nt! ?? ::NNGAKEGL::`string'+0x472ad fffff880`063ee840 fffff800`031751e5 : 00000000`01a7b648 fffff800`02e83618 00000000`01a7b6a0 fffff880`063eec30 : nt!ExpQuerySystemInformation+0x11c2 fffff880`063eebe0 fffff800`02e75993 : 00000000`031fdd48 fffff880`063eeca0 00000000`03215970 00000000`01a7c520 : nt!NtQuerySystemInformation+0x4d fffff880`063eec20 00000000`777100ba : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13 00000000`01a7b578 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x777100ba STACK_COMMAND: kb FOLLOWUP_IP: nt!MiIdentifyPfn+26f fffff800`02f28b1f f0410fba6e481f lock bts dword ptr [r14+48h],1Fh SYMBOL_STACK_INDEX: 3 SYMBOL_NAME: nt!MiIdentifyPfn+26f FOLLOWUP_NAME: MachineOwner MODULE_NAME: nt DEBUG_FLR_IMAGE_TIMESTAMP: 4c1c44a9 IMAGE_NAME: memory_corruption FAILURE_BUCKET_ID: X64_0xA_nt!MiIdentifyPfn+26f BUCKET_ID: X64_0xA_nt!MiIdentifyPfn+26f Followup: MachineOwner ---------

A starting point here would be to check for bad DIMMs using memtest86+, and also verify that there are no file system inconsistencies with chkdsk. If any are found, you can attempt to repair them with chkdsk /r <drive> From there, can you also configure small memory dumps and upload them to skydrive if the crash recurs? it would help to diagnose this as a memory issue with multiple dumps, as IRQL_NOT_LESS_OR_EQUAL is usually more as a result of a bad driver than a memory error and I have seen issues where the dump does not consistently determine the causing driver. -- Mike Burr

Thanks for the quick response Mike, I went ahead and unchecked the overwriting of previous dumps option, so I will wait a few days to collect a few dumps. I will also go ahead and run memtest86, I had used the Windows memory diagnostic and it had came back error free, but I didn't think to run memtest86 as well. Thanks again for the heads up. =)