Centrum informacji o Windows XP/2000/2003/2008/Vista/7 - Strona nieoficjalna  
Cofnij Do przodu XP.net.pl Forum Artykuły Szukaj Downloads Drivers Redakcja i info Redakcja i info

 

   

 

 
Analiza crash dumpów





Wstęp

Systemy Windows, choć już naprawdę stabilne, potrafią czasem sprawić psikusa w postaci niebieskiego ekranu. Badania pokazują, że ponad 70% tego typu przypadków spowodowanych jest przez sterowniki urządzeń firm trzecich. W poniższym artykule w kilku prostych krokach pokazane jest jak wywnioskować, który sterownik należy wymienić (a w skrajnym przypadku urządzenie), a także która aplikacja może przyczyniać się do powstania problemu.

Konfiguracja zrzutów pamięci

W systemach Windows XP domyślnie zapisywany jest tzw. minidump (Small memory dump 128KB), natomiast w Windows Vista i Windows 7 zrzut jądra (Kernel memory dump). W systemach serwerowych jak Windows Server 2003 czy Windows Server 2008/R2 zapisywany jest pełny zrzut pamięci (Complete memory dump). Więcej informacji na ten temat można znaleźć w artykule bazy wiedzy MS KB254649.

Ustawienie to można zmienić przechodząc do: Komputer -> prawy -> Właściwości -> Zaawansowane -> sekcja Uruchamianie i odzyskiwanie -> Ustawienia (My Computer -> Properties -> Advanced (system settings) -> Startup and recovery -> Settings).


Rys. Ustawienia zrzutów pamięci

Rekomendowane ustawienie to Kernel memory dump (Zrzut pamięci jądra). Plik MEMORY.DMP jest zawsze nadpisywany, więc możliwa jest analiza tylko ostatniego crasha (chyba, że będziemy te pliki samodzielnie archiwizować).

Instalacja narzędzi 

W celu debugowania zrzutów pamięci należy zainstalować pakiet Debugging Tools for Windows (32-bit, 64-bit), które zawierają debugger WinDbg z graficznych interfejsem użytkownika.

 
Rys. WinDbg

Analiza zrzutu pamięci

0. Po crashu uruchomić jako administrator debugger WinDbg.


1. Wybrać File->Symbol File Path i ustawić:
SRV*c:\symbols*http://msdl.microsoft.com/download/symbols


2. Otworzyć crash dump przez File->Open crash dump:

- C:\Windows\MEMORY.DMP (Kernel/Complete - Windows Vista/7, Windows Server 2003/2008)
- C:\Windows\Minidump\mmddyy-nnnnn-nn.dmp (Minidump - Windows 2000/XP)


3. Poczekać na wyniki wstępnej analizy:

Loading Dump File [c:\windows\MEMORY.DMP]
Kernel Summary Dump File: Only kernel address space is available

Symbol search path is: SRV*c:\symbols*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows Server 2003 Kernel Version 3790 (Service Pack 2) MP (4 procs) Free x64
Product: Server, suite: Enterprise TerminalServer SingleUserTS
Built by: 3790.srv03_sp2_gdr.100216-1301
Machine Name:
Kernel base = 0xfffff800`01000000 PsLoadedModuleList = 0xfffff800`011d4140
Debug session time: Mon Sep 27 15:37:54.784 2010 (GMT+2)
System Uptime: 11 days 6:41:09.921

Loading Kernel Symbols
...............................................................
........................................................
Loading User Symbols

Loading unloaded module list
.....
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck D1, {18, 2, 0, fffffade587465f2}

*** ERROR: Module load completed but symbols could not be loaded for bxnd52a.sys
*** ERROR: Module load completed but symbols could not be loaded for bxvbda.sys
Probably caused by : bxnd52a.sys ( bxnd52a+bc34 )

Wstępna analiza wskazuje na sterownik bxnd52a.sys.
Szybkie szukanie w Google i wychodzi na to, że jest to sterownik firmy Broadcom do kart sieciowych z serii NetXtreme II. Można się więc pokusić wyszukanie aktualizacji sterownika w sieci.


4. W celu przeprowadzenia szczegółowej analizy w kd> należy wpisać:

!analyze –v

2: 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: 0000000000000018, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000000, value 0 = read operation, 1 = write operation
Arg4: fffffade587465f2, address which referenced memory


Debugging Details:
------------------


READ_ADDRESS: 0000000000000018

CURRENT_IRQL: 2

FAULTING_IP:
tcpip!FreePartialRB+30
fffffade`587465f2 8b4618 mov eax,dword ptr [rsi+18h]

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0xD1

PROCESS_NAME: Idle

TRAP_FRAME: fffffade5be2af70 -- (.trap 0xfffffade5be2af70)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=00000000000005a8 rbx=0000000000000000 rcx=fffffade6d3e45b0
rdx=00000000ffffc564 rsi=0000000000000000 rdi=0000000000000000
rip=fffffade587465f2 rsp=fffffade5be2b100 rbp=00000000ffffbfbc
r8=fffffade6b6175a0 r9=5bcda8619c000000 r10=5bcda8619d7201fc
r11=fffffade5be2afd8 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei ng nz na pe nc
tcpip!FreePartialRB+0x30:
fffffade`587465f2 8b4618 mov eax,dword ptr [rsi+18h] ds:00000000`00000018=????????
Resetting default scope

LAST_CONTROL_TRANSFER: from fffff8000102e5b4 to fffff8000102e890

STACK_TEXT:
fffffade`5be2ade8 fffff800`0102e5b4 : 00000000`0000000a 00000000`00000018 00000000`00000002 00000000`00000000 : nt!KeBugCheckEx
fffffade`5be2adf0 fffff800`0102d547 : 00000000`00000000 00000000`00000000 fffffade`6c476400 fffffade`6c6fa4f0 : nt!KiBugCheckDispatch+0x74
fffffade`5be2af70 fffffade`587465f2 : 00000000`000005a8 fffffade`6d3e45b0 fffffade`6bcf9538 fffffade`6bcf9530 : nt!KiPageFault+0x207
fffffade`5be2b100 fffffade`58752024 : fffffade`58751950 fffffade`6bcf9530 00000000`00000000 fffffade`6d3e45b0 : tcpip!FreePartialRB+0x30
fffffade`5be2b130 fffffade`58748c80 : 00000000`00000000 fffffade`00001080 00000000`00000033 fffffade`ffffc564 : tcpip!IndicateData+0x997
fffffade`5be2b200 fffffade`58757b19 : fffffade`ca11970a fffff800`0458970a fffffade`6e4700a2 fffffade`6d3ebd01 : tcpip!TcpFastReceive+0x4c9
fffffade`5be2b2b0 fffffade`58754681 : fffffade`6fe01530 fffffade`ca11970a 00000000`0458970a fffffade`6d3e24d0 : tcpip!TCPRcv+0xf75
fffffade`5be2b500 fffffade`5877c3be : fffffade`00000000 fffffade`6cc454d0 00000000`00000000 fffffade`6e474b01 : tcpip!DeliverToUser+0x367
fffffade`5be2b600 fffffade`5875e021 : 00000000`ca11970a fffffade`6cc454d0 fffffade`6e3c8b18 fffffade`6e3c8b18 : tcpip!DeliverToUserEx+0x1201
fffffade`5be2b780 fffffade`58754275 : fffffade`00000000 fffffade`00000001 fffffade`000005c8 fffffade`6f282b10 : tcpip!IPRcvPacket+0xabf
fffffade`5be2b8a0 fffffade`587540db : 00000000`00000002 00000000`00000300 00000000`00000000 00000000`00000002 : tcpip!ARPRcvIndicationNew+0x228
fffffade`5be2b940 fffffade`5ae8128a : fffffade`6f34d690 fffffade`6d59e230 fffffade`6d59e1c0 00000000`00000000 : tcpip!ARPRcvPacket+0x3be
fffffade`5be2b9f0 fffffade`59406c34 : fffffade`000005ea fffffade`6e5f4578 00000000`00000001 fffffade`5be2bba0 : NDIS!ethFilterDprIndicateReceivePacket+0x465
fffffade`5be2bac0 fffffade`59406dea : fffffade`6e5f4010 00000000`00000001 fffffade`6d59e230 fffffade`5afabb41 : bxnd52a+0xbc34
fffffade`5be2bb20 fffffade`5afa4691 : fffffade`6cebf040 fffffade`5be2bc80 fffffade`6e5f1000 fffffade`5afabf5f : bxnd52a+0xbdea
fffffade`5be2bb80 fffffade`5afa495a : fffffade`5be2bc80 00000000`0000000c fffffade`6ff81d01 00000000`00000000 : bxvbda+0x7691
fffffade`5be2bbe0 fffffade`5afac19c : fffffade`6e5f1000 fffffade`6ff7e668 00000000`00000000 fffffade`6ff82228 : bxvbda+0x795a
fffffade`5be2bc60 fffffade`5afac805 : fffffade`6ff7e010 00000000`00010000 00000000`00010000 00000000`00000000 : bxvbda+0xf19c
fffffade`5be2bcc0 fffffade`5afaca25 : fffffade`6ff7e010 00000000`00000000 000008dc`dd55db3e 00000000`00000000 : bxvbda+0xf805
fffffade`5be2bcf0 fffff800`010285a1 : 00000000`00000000 00000000`00000000 fffffade`5afac970 00000000`00000000 : bxvbda+0xfa25
fffffade`5be2bd20 fffff800`01067b90 : fffffade`5babb180 fffffade`5babb180 00000000`00000000 fffffade`5bac3680 : nt!KiRetireDpcList+0x150
fffffade`5be2bdb0 fffff800`014151d1 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiIdleLoop+0x50
fffffade`5be2bde0 00000000`fffffade : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemStartup+0x1bf
fffffade`5babd640 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00680000`00000000 : 0xfffffade


STACK_COMMAND: kb

FOLLOWUP_IP:
bxnd52a+bc34
fffffade`59406c34 488b5c2460 mov rbx,qword ptr [rsp+60h]

SYMBOL_STACK_INDEX: d

SYMBOL_NAME: bxnd52a+bc34

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: bxnd52a

IMAGE_NAME: bxnd52a.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 4b390dbc

FAILURE_BUCKET_ID: X64_0xD1_bxnd52a+bc34

BUCKET_ID: X64_0xD1_bxnd52a+bc34


5. W celu odnalezienia wątku powiązanego z crashem w kd> należy wpisać:

!thread

2: kd> !thread
THREAD fffffade5bac3680 Cid 0000.0000 Teb: 0000000000000000 Win32Thread: 0000000000000000 RUNNING on processor 2
Not impersonating
Owning Process fffff800011b4940 Image: Idle
Attached Process N/A Image: N/A
Wait Start TickCount 62366036 Ticks: 39 (0:00:00:00.609)
Context Switch Count 201361545
UserTime 00:00:00.000
KernelTime 11 Days 02:23:02.921
Stack Init fffffade5be2bde0 Current fffffade5be2bd70
Base fffffade5be2bfe0 Limit fffffade5be25fe0 Call 0
Priority 16 BasePriority 0 PriorityDecrement 0
Child-SP RetAddr : Args to Child : Call Site
fffffade`5be2ade8 fffff800`0102e5b4 : 00000000`0000000a 00000000`00000018 00000000`00000002 00000000`00000000 : nt!KeBugCheckEx
fffffade`5be2adf0 fffff800`0102d547 : 00000000`00000000 00000000`00000000 fffffade`6c476400 fffffade`6c6fa4f0 : nt!KiBugCheckDispatch+0x74
fffffade`5be2af70 fffffade`587465f2 : 00000000`000005a8 fffffade`6d3e45b0 fffffade`6bcf9538 fffffade`6bcf9530 : nt!KiPageFault+0x207 (TrapFrame @ fffffade`5be2af70)
fffffade`5be2b100 fffffade`58752024 : fffffade`58751950 fffffade`6bcf9530 00000000`00000000 fffffade`6d3e45b0 : tcpip!FreePartialRB+0x30
fffffade`5be2b130 fffffade`58748c80 : 00000000`00000000 fffffade`00001080 00000000`00000033 fffffade`ffffc564 : tcpip!IndicateData+0x997
fffffade`5be2b200 fffffade`58757b19 : fffffade`ca11970a fffff800`0458970a fffffade`6e4700a2 fffffade`6d3ebd01 : tcpip!TcpFastReceive+0x4c9
fffffade`5be2b2b0 fffffade`58754681 : fffffade`6fe01530 fffffade`ca11970a 00000000`0458970a fffffade`6d3e24d0 : tcpip!TCPRcv+0xf75
fffffade`5be2b500 fffffade`5877c3be : fffffade`00000000 fffffade`6cc454d0 00000000`00000000 fffffade`6e474b01 : tcpip!DeliverToUser+0x367
fffffade`5be2b600 fffffade`5875e021 : 00000000`ca11970a fffffade`6cc454d0 fffffade`6e3c8b18 fffffade`6e3c8b18 : tcpip!DeliverToUserEx+0x1201
fffffade`5be2b780 fffffade`58754275 : fffffade`00000000 fffffade`00000001 fffffade`000005c8 fffffade`6f282b10 : tcpip!IPRcvPacket+0xabf
fffffade`5be2b8a0 fffffade`587540db : 00000000`00000002 00000000`00000300 00000000`00000000 00000000`00000002 : tcpip!ARPRcvIndicationNew+0x228
fffffade`5be2b940 fffffade`5ae8128a : fffffade`6f34d690 fffffade`6d59e230 fffffade`6d59e1c0 00000000`00000000 : tcpip!ARPRcvPacket+0x3be
fffffade`5be2b9f0 fffffade`59406c34 : fffffade`000005ea fffffade`6e5f4578 00000000`00000001 fffffade`5be2bba0 : NDIS!ethFilterDprIndicateReceivePacket+0x465
fffffade`5be2bac0 fffffade`59406dea : fffffade`6e5f4010 00000000`00000001 fffffade`6d59e230 fffffade`5afabb41 : bxnd52a+0xbc34
fffffade`5be2bb20 fffffade`5afa4691 : fffffade`6cebf040 fffffade`5be2bc80 fffffade`6e5f1000 fffffade`5afabf5f : bxnd52a+0xbdea
fffffade`5be2bb80 fffffade`5afa495a : fffffade`5be2bc80 00000000`0000000c fffffade`6ff81d01 00000000`00000000 : bxvbda+0x7691
fffffade`5be2bbe0 fffffade`5afac19c : fffffade`6e5f1000 fffffade`6ff7e668 00000000`00000000 fffffade`6ff82228 : bxvbda+0x795a
fffffade`5be2bc60 fffffade`5afac805 : fffffade`6ff7e010 00000000`00010000 00000000`00010000 00000000`00000000 : bxvbda+0xf19c
fffffade`5be2bcc0 fffffade`5afaca25 : fffffade`6ff7e010 00000000`00000000 000008dc`dd55db3e 00000000`00000000 : bxvbda+0xf805
fffffade`5be2bcf0 fffff800`010285a1 : 00000000`00000000 00000000`00000000 fffffade`5afac970 00000000`00000000 : bxvbda+0xfa25
fffffade`5be2bd20 fffff800`01067b90 : fffffade`5babb180 fffffade`5babb180 00000000`00000000 fffffade`5bac3680 : nt!KiRetireDpcList+0x150
fffffade`5be2bdb0 fffff800`014151d1 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiIdleLoop+0x50
fffffade`5be2bde0 00000000`fffffade : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemStartup+0x1bf
fffffade`5babd640 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00680000`00000000 : 0xfffffade


6. W celu poznania procesu powiązanego z crashem w kd> należy wpisać:

!process fffff800011b4940 0

2: kd> !process fffff800011b4940 0
PROCESS fffff800011b4940
SessionId: none Cid: 0000 Peb: 00000000 ParentCid: 0000
DirBase: 00147000 ObjectTable: fffffa8000002c80 HandleCount: 943.
Image: Idle




Crash Dump Analysis @ MSDN >

Strona główna serwisu XP.net.pl >>


Na podst. : materiałów dostępnych na witrynie www.microsoft.com oraz własnych doświadczeń z analizy carsh dumpów
Wersja artykułu : 1.1
Ostatnia aktualizacja : 06.10.2010
Wydanie oryginalne: wersja 1.0 (29.09.2010)

Autor : GreGM © 2010
Dodane przez : GreGM © 2010

 


 
 
All rights reserved. XP.net.pl © 2010 ^Do góry^