New
#1
BSOD random and rare but caught one finally
Hi people, unfortunately by the time I read the post on how to post on BSODs I had already created the below file in txt and deleted the minidump but anyway, I have been experiencing bsods rarely and intermittently. This time it really caught my attention as I was only uploading a gmail attachment when it happened. I have noticed these bsods occur when there is some kind of network traffic that's somehow strained either by my ISP throttling or sudden demand of out going request/uploads or incoming responses/downloads but is not always the case. This are the results, not entirely sure what is causing it but my suspicions are tied to a new modem device whose drivers I installed in order to access internet. That's just about when the BSODs begun but are very rare, thin and in between. So here are my results:-
I ran my antivirus but didn't catch anything, my system is stable and fully in my control. What is causing this rare BSOD ?Code:Windows 7 Kernel Version 7601 (Service Pack 1) MP (2 procs) Free x64 Product: WinNt, suite: TerminalServer SingleUserTS Built by: 7601.17514.amd64fre.win7sp1_rtm.101119-1850 Machine Name: Kernel base = 0xfffff800`0361b000 PsLoadedModuleList = 0xfffff800`03860e90 Debug session time: Thu Jan 3 16:47:04.605 2013 (UTC - 5:00) System Uptime: 0 days 2:51:14.244 ******************************************************************************* * * * 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: 0000000000000028, memory referenced Arg2: 0000000000000002, IRQL Arg3: 0000000000000000, 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: fffff800036e2628, address which referenced memory Debugging Details: ------------------ TRIAGER: Could not open triage file : e:\dump_analysis\program\triage\modclass.ini, error 2 READ_ADDRESS: GetPointerFromAddress: unable to read from fffff800038cc0e8 GetUlongFromAddress: unable to read from fffff800038cc198 0000000000000028 Nonpaged pool CURRENT_IRQL: 2 FAULTING_IP: nt!MiFindNodeOrParent+0 fffff800`036e2628 48f7412800ffffff test qword ptr [rcx+28h],0FFFFFFFFFFFFFF00h CUSTOMER_CRASH_COUNT: 1 DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULT BUGCHECK_STR: 0xA PROCESS_NAME: svchost.exe TRAP_FRAME: fffff88006f853b0 -- (.trap 0xfffff88006f853b0) NOTE: The trap frame does not contain all registers. Some register values may be zeroed or incorrect. rax=0000000000000000 rbx=0000000000000000 rcx=0000000000000000 rdx=0000000000000000 rsi=0000000000000000 rdi=0000000000000000 rip=fffff800036e2628 rsp=fffff88006f85548 rbp=0000000000000000 r8=fffff88006f85590 r9=0000000000000000 r10=fffffa8004deb950 r11=0000058000000000 r12=0000000000000000 r13=0000000000000000 r14=0000000000000000 r15=0000000000000000 iopl=0 nv up ei ng nz na po nc nt!MiFindNodeOrParent: fffff800`036e2628 48f7412800ffffff test qword ptr [rcx+28h],0FFFFFFFFFFFFFF00h ds:00000000`00000028=???????????????? Resetting default scope LAST_CONTROL_TRANSFER: from fffff8000369abe9 to fffff8000369b640 STACK_TEXT: fffff880`06f85268 fffff800`0369abe9 : 00000000`0000000a 00000000`00000028 00000000`00000002 00000000`00000000 : nt!KeBugCheckEx fffff880`06f85270 fffff800`03699860 : fffffa80`02d9f330 fffff880`00040004 00000000`00000000 fffffa80`04deb998 : nt!KiBugCheckDispatch+0x69 fffff880`06f853b0 fffff800`036e2628 : fffff800`036e4807 00000000`000007ff 00000000`000006b6 00000000`00000000 : nt!KiPageFault+0x260 fffff880`06f85548 fffff800`036e4807 : 00000000`000007ff 00000000`000006b6 00000000`00000000 00001f80`00000000 : nt!MiFindNodeOrParent fffff880`06f85550 fffff800`036e48dd : 00000000`00046eea 00000000`000034c9 fffff880`06f85770 fffff800`038226c0 : nt!MiLocateAddressInTree+0x17 fffff880`06f85580 fffff800`036e4958 : 00000000`00000002 fffffa80`04debab0 00000000`0000003a fffffa80`04debab0 : nt!MiGetSharedProtosAtDpcLevel+0xbd fffff880`06f855d0 fffff800`0363297b : 000067ee`6ae0cafc 00000000`00000000 fffff800`0380de00 fffff800`036bde4d : nt!MiGetSharedProtos+0x18 fffff880`06f85600 fffff800`037433bb : 00000000`00000000 02000000`0004c940 00000000`42506600 fffff800`03986c8f : nt! ?? ::FNODOBFM::`string'+0x938b fffff880`06f85630 fffff800`03743f3b : 00000000`00000000 00000000`00000004 fffffa80`01e858a0 fffffa80`01e84000 : nt!MiIdentifyPfn+0x39b fffff880`06f856d0 fffff800`03aa9c05 : fffffa80`01e84000 fffff880`06f85c60 fffff880`06f857a8 00000000`00000000 : nt!MmQueryPfnList+0xbb fffff880`06f85710 fffff800`039ebde8 : 00000000`00000006 00000000`00000000 fffffa80`01e84000 00000000`00000001 : nt!PfpPfnPrioRequest+0x115 fffff880`06f85760 fffff800`039a50d3 : 00000000`00000000 00000000`00000000 00000000`64496d4d 00000000`64496d01 : nt! ?? ::NNGAKEGL::`string'+0x48fbd fffff880`06f857f0 fffff800`039a5949 : 00000000`020bbd88 00000000`00000000 00000000`020bbde0 00000000`020bbda8 : nt!ExpQuerySystemInformation+0x1193 fffff880`06f85ba0 fffff800`0369a8d3 : 00000000`00000005 fffff880`06f85c60 00000000`06900df0 00000000`02f3fe20 : nt!NtQuerySystemInformation+0x4d fffff880`06f85be0 00000000`7720167a : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13 00000000`020bbcb8 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x7720167a STACK_COMMAND: kb FOLLOWUP_IP: nt!MiFindNodeOrParent+0 fffff800`036e2628 48f7412800ffffff test qword ptr [rcx+28h],0FFFFFFFFFFFFFF00h SYMBOL_STACK_INDEX: 3 SYMBOL_NAME: nt!MiFindNodeOrParent+0 FOLLOWUP_NAME: MachineOwner MODULE_NAME: nt DEBUG_FLR_IMAGE_TIMESTAMP: 4ce7951a IMAGE_NAME: memory_corruption FAILURE_BUCKET_ID: X64_0xA_nt!MiFindNodeOrParent+0 BUCKET_ID: X64_0xA_nt!MiFindNodeOrParent+0 Followup: MachineOwner ---------