[]
Win 7'de mavi ekran hatası ve dump dosyaları yorumu
Selam herkese. Bilgisayarım 1 ay kadar bir süredir durup dururken mavi ekran ve "Driver_irql_not_less_or_equal" hatası vermeye başladı. Windows debuggerla aşağıdaki dump verilerine ulaştım ama nasıl yorumlayacağım hakkında hiçbir fikrim yok. Bilgili arkadaşlardan çok rica ediyorum, bi el atın nolur.
Microsoft (R) Windows Debugger Version 6.2.9200.20512 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.
Loading Dump File [C:\Windows\Minidump\New folder\070613-42229-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available
Symbol search path is: SRV*C:\Symbols*msdl.microsoft.com
Executable search path is:
Windows 7 Kernel Version 7601 (Service Pack 1) MP (8 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS Personal
Built by: 7601.18113.amd64fre.win7sp1_gdr.130318-1533
Machine Name:
Kernel base = 0xfffff8000344c000 PsLoadedModuleList = 0xfffff8000368f670
Debug session time: Sat Jul 6 20:30:17.456 2013 (UTC + 3:00)
System Uptime: 0 days 2:42:35.377
Loading Kernel Symbols
...............................................................
................................................................
...........................................................
Loading User Symbols
Loading unloaded module list
..........
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
Use !analyze -v to get detailed debugging information.
BugCheck D1, {28, 2, 0, fffff880016106fd}
Probably caused by : NETIO.SYS ( NETIO!RtlCopyBufferToMdl+1d )
Followup: MachineOwner
---------
4: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
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 kernel debugger is available get stack backtrace.
Arguments:
Arg1: 0000000000000028, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000000, value 0 = read operation, 1 = write operation
Arg4: fffff880016106fd, address which referenced memory
Debugging Details:
------------------
READ_ADDRESS: GetPointerFromAddress: unable to read from fffff800036f9100
GetUlongFromAddress: unable to read from fffff800036f91c0
0000000000000028 Nonpaged pool
CURRENT_IRQL: 2
FAULTING_IP:
NETIO!RtlCopyBufferToMdl+1d
fffff880`016106fd 448b5228 mov r10d,dword ptr [rdx+28h]
CUSTOMER_CRASH_COUNT: 1
DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULT
BUGCHECK_STR: 0xD1
PROCESS_NAME: System
TRAP_FRAME: fffff880035616f0 -- (.trap 0xfffff880035616f0)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=fffff88003561910 rbx=0000000000000000 rcx=0000000000000000
rdx=0000000000000000 rsi=0000000000000000 rdi=0000000000000000
rip=fffff880016106fd rsp=fffff88003561880 rbp=fffff880035619b0
r8=00000000ffffffbc r9=0000000000000044 r10=0000000000000000
r11=fffffa8007b61b00 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei pl zr na po nc
NETIO!RtlCopyBufferToMdl+0x1d:
fffff880016106fd 448b5228 mov r10d,dword ptr [rdx+28h] ds*00000028=????????
Resetting default scope
LAST_CONTROL_TRANSFER: from fffff800034c11a9 to fffff800034c1c00
STACK_TEXT:
fffff880035615a8 fffff800034c11a9 : 000000000000000a 0000000000000028 0000000000000002 0000000000000000 : nt!KeBugCheckEx
fffff880035615b0 fffff800034bfe20 : fffff880035629e8 fffff88003561768 fffffa8008950170 0000000000000044 : nt!KiBugCheckDispatch+0x69
fffff880035616f0 fffff880016106fd : 0000000000000075 fffff880018169ec 000000000000000a fffffa8004600bc8 : nt!KiPageFault+0x260
fffff88003561880 fffff880018a55fc : 0000000000000000 fffff88001874756 0000000000000000 0000000000000000 : NETIO!RtlCopyBufferToMdl+0x1d
fffff880035618e0 fffff88001872273 : fffffa8007b61b00 0000000000000000 fffffa80042b3840 000000008ed55a53 : tcpip! ?? ::FNODOBFM::string'+0x1cc2f
fffff88003561950 fffff88001863204 *03561e08 0000000000000029 fffffa80042b3840 00000000`00000000 : tcpip!TcpTcbCarefulDatagram+0x1aa3
fffff88003561b00 fffff8800186269a : fffffa8004fbea00 fffff8800185b544 fffffa8004f595b0 0000000000000000 : tcpip!TcpTcbReceive+0x694
fffff88003561cb0 fffff88001863c3b : fffff88009f7706c fffffa80050e9000 0000000000000000 fffff88003562000 : tcpip!TcpMatchReceive+0x1fa
fffff88003561e00 fffff8800185bbd7 : fffffa8004fbea00 fffffa8004fbd3eb fffffa800000199f 000000000000199f : tcpip!TcpPreValidatedReceive+0x36b
fffff88003561ed0 fffff8800185b74a : 0000000000000000 fffff88001969800 fffff88003562090 00001f8000a00049 : tcpip!IppDeliverListToProtocol+0x97
fffff88003561f90 fffff8800185ad49 : 0000000000000000 0000000000000000 0000000000000000 fffff88003562080 : tcpip!IppProcessDeliverList+0x5a
fffff88003562030 fffff880018589ef : 0000000000000000 0000000007505b00 fffff88001969800 fffff88001969800 : tcpip!IppReceiveHeaderBatch+0x23a
fffff88003562110 fffff88001857fc2 : fffffa8007506260 0000000000000000 fffffa8007505b00 0000000000000001 : tcpip!IpFlcReceivePackets+0x64f
fffff88003562310 fffff880018ca68a : fffffa8000000000 fffffa80085cdce0 fffffa8007505ba0 fffff88003562400 : tcpip!FlpReceiveNonPreValidatedNetBufferListChain+0x2b2
fffff880035623f0 fffff800034cd878 : fffffa80085cdce0 fffffa8004fabcec fffffa8004075730 0000000000000001 : tcpip! ?? ::FNODOBFM::string'+0x4e922
fffff88003562440 fffff88001857ae2 *01857310 fffffa800954cf10 fffffa800948f500 fffffa80`0537c501 : nt!KeExpandKernelStackAndCalloutEx+0xd8
fffff88003562520 fffff880017960eb : fffffa80075025f0 0000000000000000 fffffa800546b1a0 0000000000000000 : tcpip!FlReceiveNetBufferListChain+0xb2
fffff88003562590 0000000000000000 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : ndis!ndisMIndicateNetBufferListsToOpen+0xdb
STACK_COMMAND: kb
FOLLOWUP_IP:
NETIO!RtlCopyBufferToMdl+1d
fffff880`016106fd 448b5228 mov r10d,dword ptr [rdx+28h]
SYMBOL_STACK_INDEX: 3
SYMBOL_NAME: NETIO!RtlCopyBufferToMdl+1d
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: NETIO
IMAGE_NAME: NETIO.SYS
DEBUG_FLR_IMAGE_TIMESTAMP: 5034f6a0
FAILURE_BUCKET_ID: X64_0xD1_NETIO!RtlCopyBufferToMdl+1d
BUCKET_ID: X64_0xD1_NETIO!RtlCopyBufferToMdl+1d
Followup: MachineOwner
Şimdiden çok teşekkür ederim
Microsoft (R) Windows Debugger Version 6.2.9200.20512 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.
Loading Dump File [C:\Windows\Minidump\New folder\070613-42229-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available
Symbol search path is: SRV*C:\Symbols*msdl.microsoft.com
Executable search path is:
Windows 7 Kernel Version 7601 (Service Pack 1) MP (8 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS Personal
Built by: 7601.18113.amd64fre.win7sp1_gdr.130318-1533
Machine Name:
Kernel base = 0xfffff8000344c000 PsLoadedModuleList = 0xfffff8000368f670
Debug session time: Sat Jul 6 20:30:17.456 2013 (UTC + 3:00)
System Uptime: 0 days 2:42:35.377
Loading Kernel Symbols
...............................................................
................................................................
...........................................................
Loading User Symbols
Loading unloaded module list
..........
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
Use !analyze -v to get detailed debugging information.
BugCheck D1, {28, 2, 0, fffff880016106fd}
Probably caused by : NETIO.SYS ( NETIO!RtlCopyBufferToMdl+1d )
Followup: MachineOwner
---------
4: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
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 kernel debugger is available get stack backtrace.
Arguments:
Arg1: 0000000000000028, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000000, value 0 = read operation, 1 = write operation
Arg4: fffff880016106fd, address which referenced memory
Debugging Details:
------------------
READ_ADDRESS: GetPointerFromAddress: unable to read from fffff800036f9100
GetUlongFromAddress: unable to read from fffff800036f91c0
0000000000000028 Nonpaged pool
CURRENT_IRQL: 2
FAULTING_IP:
NETIO!RtlCopyBufferToMdl+1d
fffff880`016106fd 448b5228 mov r10d,dword ptr [rdx+28h]
CUSTOMER_CRASH_COUNT: 1
DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULT
BUGCHECK_STR: 0xD1
PROCESS_NAME: System
TRAP_FRAME: fffff880035616f0 -- (.trap 0xfffff880035616f0)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=fffff88003561910 rbx=0000000000000000 rcx=0000000000000000
rdx=0000000000000000 rsi=0000000000000000 rdi=0000000000000000
rip=fffff880016106fd rsp=fffff88003561880 rbp=fffff880035619b0
r8=00000000ffffffbc r9=0000000000000044 r10=0000000000000000
r11=fffffa8007b61b00 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei pl zr na po nc
NETIO!RtlCopyBufferToMdl+0x1d:
fffff880016106fd 448b5228 mov r10d,dword ptr [rdx+28h] ds*00000028=????????
Resetting default scope
LAST_CONTROL_TRANSFER: from fffff800034c11a9 to fffff800034c1c00
STACK_TEXT:
fffff880035615a8 fffff800034c11a9 : 000000000000000a 0000000000000028 0000000000000002 0000000000000000 : nt!KeBugCheckEx
fffff880035615b0 fffff800034bfe20 : fffff880035629e8 fffff88003561768 fffffa8008950170 0000000000000044 : nt!KiBugCheckDispatch+0x69
fffff880035616f0 fffff880016106fd : 0000000000000075 fffff880018169ec 000000000000000a fffffa8004600bc8 : nt!KiPageFault+0x260
fffff88003561880 fffff880018a55fc : 0000000000000000 fffff88001874756 0000000000000000 0000000000000000 : NETIO!RtlCopyBufferToMdl+0x1d
fffff880035618e0 fffff88001872273 : fffffa8007b61b00 0000000000000000 fffffa80042b3840 000000008ed55a53 : tcpip! ?? ::FNODOBFM::string'+0x1cc2f
fffff88003561950 fffff88001863204 *03561e08 0000000000000029 fffffa80042b3840 00000000`00000000 : tcpip!TcpTcbCarefulDatagram+0x1aa3
fffff88003561b00 fffff8800186269a : fffffa8004fbea00 fffff8800185b544 fffffa8004f595b0 0000000000000000 : tcpip!TcpTcbReceive+0x694
fffff88003561cb0 fffff88001863c3b : fffff88009f7706c fffffa80050e9000 0000000000000000 fffff88003562000 : tcpip!TcpMatchReceive+0x1fa
fffff88003561e00 fffff8800185bbd7 : fffffa8004fbea00 fffffa8004fbd3eb fffffa800000199f 000000000000199f : tcpip!TcpPreValidatedReceive+0x36b
fffff88003561ed0 fffff8800185b74a : 0000000000000000 fffff88001969800 fffff88003562090 00001f8000a00049 : tcpip!IppDeliverListToProtocol+0x97
fffff88003561f90 fffff8800185ad49 : 0000000000000000 0000000000000000 0000000000000000 fffff88003562080 : tcpip!IppProcessDeliverList+0x5a
fffff88003562030 fffff880018589ef : 0000000000000000 0000000007505b00 fffff88001969800 fffff88001969800 : tcpip!IppReceiveHeaderBatch+0x23a
fffff88003562110 fffff88001857fc2 : fffffa8007506260 0000000000000000 fffffa8007505b00 0000000000000001 : tcpip!IpFlcReceivePackets+0x64f
fffff88003562310 fffff880018ca68a : fffffa8000000000 fffffa80085cdce0 fffffa8007505ba0 fffff88003562400 : tcpip!FlpReceiveNonPreValidatedNetBufferListChain+0x2b2
fffff880035623f0 fffff800034cd878 : fffffa80085cdce0 fffffa8004fabcec fffffa8004075730 0000000000000001 : tcpip! ?? ::FNODOBFM::string'+0x4e922
fffff88003562440 fffff88001857ae2 *01857310 fffffa800954cf10 fffffa800948f500 fffffa80`0537c501 : nt!KeExpandKernelStackAndCalloutEx+0xd8
fffff88003562520 fffff880017960eb : fffffa80075025f0 0000000000000000 fffffa800546b1a0 0000000000000000 : tcpip!FlReceiveNetBufferListChain+0xb2
fffff88003562590 0000000000000000 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : ndis!ndisMIndicateNetBufferListsToOpen+0xdb
STACK_COMMAND: kb
FOLLOWUP_IP:
NETIO!RtlCopyBufferToMdl+1d
fffff880`016106fd 448b5228 mov r10d,dword ptr [rdx+28h]
SYMBOL_STACK_INDEX: 3
SYMBOL_NAME: NETIO!RtlCopyBufferToMdl+1d
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: NETIO
IMAGE_NAME: NETIO.SYS
DEBUG_FLR_IMAGE_TIMESTAMP: 5034f6a0
FAILURE_BUCKET_ID: X64_0xD1_NETIO!RtlCopyBufferToMdl+1d
BUCKET_ID: X64_0xD1_NETIO!RtlCopyBufferToMdl+1d
Followup: MachineOwner
Şimdiden çok teşekkür ederim
Ekran kartıyla ilgili olduğunu düşünüyordum ancak biraz inceleyince BIOS ayarlarınızla alâkalı bir tutarsızlıktan dolayı olduğunu gördüm. Bilgisayarınızı başlatırken BIOS'a girip varsayılan ayarları (Load Optimized Defaults) geri yükleyin, kaydederek çıkış yapın ve sistem açıldıktan sonra bir süre deneyin. Tekrar hata alırsanız (ki sanmıyorum, büyük bir ihtimalle düzelecektir) cep telefonunuzla mavi ekranın görüntüsünü almaya çalışın, daha sonra burada tekrar paylaşırsınız.
- omelette du fromage
(08.07.13 20:51:44 ~ 20:54:35)
Omelette, çok çok teşekkür ederim. Az önce varsayılan ayarlara geri getirdim, tekrarlarsa paylaşırım.
- ranta (08.07.13 21:15:18)
1
