To już jest czwarta publikacja, która porusza tematykę zrzutów pamięci, które tworzone są po awarii systemu Windows i wyświetleniu niebieskiego ekranu (BlueScreen ) z informacjami o błędzie. Dane te zapisywane są do pliku a następnie istnieje możliwość jego przeanalizowania w narzędziu Microsoft Debugging Tools (WinDbg) w celu wykrycia a następnie usunięcia awarii. Przed przystąpieniem do badania zrzutu pamięci musimy określić jaki wariant jego zapisywania jest dla nas najlepszy Jak włączyć pełny zrzut pamięci dla Bluescreen (BSOD) podczas awarii systemu Windows 7?, zainstalować aplikację WinDbg oraz pomocne symbole przy badania informacji Jak zainstalować narzędzie do analizowania ekranów BlueScreen (BSOD) po awarii systemu Windows?. Więcej informacji o wariantach zapisywania zrzutu pamięci oraz sztuczne wywołanie ekranu BlueScreen znajduje się w poradzie Gdzie zapisywane są zrzuty pamięci po awarii systemu Windows oraz jak sztucznie wywołać Bluescreen?.
Przed wyciągnięciem informacji bezpośrednio z treści pliku z zrzutem pamięci w narzędziu WinDbg warto zapoznać się z programem WhoCrashed, który podsumuje w przejrzysty sposób informacje, prezentując najważniejsze, mające kluczowe znaczenie dla zlokalizowania i usunięcia awarii.
Po zainstalowaniu programów WinDbg (więcej informacji) oraz WhoCrashed, uruchamiamy oba z uprawnieniami administratora.
W aplikacji WinDbg klikamy w menu File na Open Crash Dump… i wczytujemy plik memory dump (więcej informacji).
Następnie minimalizujemy narzędzie WinDbg i przechodzimy do aplikacji WhoCrashed. Klikamy na przycisk Analyze a następnie w okienku na przycisk I have the right version of WinDbg installed, let me locate it …
Wskazujemy lokalizację, gdzie zostało zainstalowane narzędzie Microsoft Debugging Tools, domyślnie jest to C:\Program Files\Debugging Tools for Windows, zaznaczamy folder z nazwą programu i klikamy na przycisk OK.
Zamykamy okienko z informacją i przesuwamy suwakiem okna do informacji o przeprowadzonej analizie. Z tych danych odczytujemy najważniejsze, będące bardzo przydatne przy usuwaniu przyczyny awarii. (więcej informacji o oznaczeniach znajduje się poniżej w tekście).
Na samym końcu mamy podsumowanie wraz z poradami, wymagana jest znajomość języka angielskiego (aby zrozumieć sens tekstu możemy przetłumaczyć go np. w Google Translator).
Korzystanie z Debugging Tools for Windows
Z menu Start uruchamiamy narzędzie z folderu Debugging Tools for Windows o nazwie WinDbg.
Ustalamy lokalizację symboli (więcej informacji) i wczytujemy plik zrzutu pamięci z określonej lokalizacji (więcej informacji).
Gdy wcześniej ustalimy lokalizację symboli i wczytamy plik z zrzutem pamięci, w okienku Workspace ‘basic” (miejsce pracy) klikamy na przycisk No.
Najważniejsza informacja, którą możemy wyszukać w tekście to Probably caused by : czyli prawdopodobna przyczyna wystąpienia błędu. Z tego wpisu dowiemy się, co prawdopodobnie spowodowało awarię – może to być np. plik z rozszerzeniem EXE, sterownik z rozszerzeniem SYS, biblioteka DLL itd. Przykład: Probably caused by : ntkrnlmp.exe.
Polecenia możemy wpisywać na dole ekranu i zatwierdzać je klawiszem Enter np. !analyze –show, !analyze –v, lm N T.
Natomiast polecenie !analyze –show odpowiedzialne jest za wyświetlenie informacji o kodzie błędu zatrzymania wraz z jego parametrami.
Jeśli użyjemy polecenia lm N T to dowiemy się o załadowanych modułach, które zostaną wyświetlone jako lista.
Ważne informacje zawarte są w części oznaczonej jako !analyze –v, są to wszystkie dane wyjściowe. Poniżej uwidzimy kod błędu (STOP). Przykład: BugCheck E2, {0, 0, 0, 0}. Informacje o kodzie błędu i podobnych przypadkach, które mieli inni użytkownicy powinniśmy znaleźć np. w wyszukiwarce Google.
Bardziej szczegółowe informacje uzyskamy po kliknięciu na niebieski link analyze –v.
Więcej informacji uzyskamy w sekcji Debugging Details:. Nazwa BUGCHECK_STR: informuje o kodzie kontroli błędu np. BUGCHECK_STR: MANUALLY_INITIATED_CRASH – w tym przypadku zdarzenie (awaria) zostało wywołane ręcznie. W DEFAULT_BUCKET_ID: odczytamy z czym powiązany jest napotkany błąd np. DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT, czyli ze sterownikiem. W każdym przypadku, różne informacje mogą okazać się niezwykle przydatne, dlatego należy przyjrzeć się wszystkim danym i wyciągnąć z nich najbardziej logiczne i zrozumiałe dane, o których możemy poszerzyć wiedzę w różnych źródłach informacji, np. w wyszukiwarce internetowej.
PRZYKŁAD:
Debugging Details:
------------------
BUGCHECK_STR: MANUALLY_INITIATED_CRASH
DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
PROCESS_NAME: System
CURRENT_IRQL: 2
LAST_CONTROL_TRANSFER: from fffff88000df3dcf to fffff80002ac4740
SYMBOL_ON_RAW_STACK: 1
STACK_ADDR_RAW_STACK_SYMBOL: fffff80004134b98
STACK_COMMAND: dds FFFFF80004134B98-0x20 ; kb
STACK_TEXT:
fffff800`04134b78 04d1fea8
fffff800`04134b7c fffffa80
fffff800`04134b80 04d1fe02
fffff800`04134b84 fffffa80
fffff800`04134b88 03c71b20
fffff800`04134b8c fffff880
fffff800`04134b90 010efcc0
fffff800`04134b94 fffff880
fffff800`04134b98 00000000
fffff800`04134b9c 00000000
fffff800`04134ba0 0454f010
fffff800`04134ba4 fffffa80
fffff800`04134ba8 ffffff02
fffff800`04134bac 00000000
fffff800`04134bb0 04d1f050
fffff800`04134bb4 fffffa80
fffff800`04134bb8 03c8064f
fffff800`04134bbc fffff880
fffff800`04134bc0 04d1fea8
fffff800`04134bc4 fffffa80
fffff800`04134bc8 04d1f1a0
fffff800`04134bcc fffffa80
fffff800`04134bd0 04d20040
fffff800`04134bd4 fffffa80
fffff800`04134bd8 00000000
fffff800`04134bdc 00000000
fffff800`04134be0 00000000
fffff800`04134be4 00000000
fffff800`04134be8 00000000
fffff800`04134bec 00000000
fffff800`04134bf0 ffffffff
fffff800`04134bf4 00000000
FOLLOWUP_IP:
sptd+78cc0
fffff880`010efcc0 ?? ???
SYMBOL_NAME: sptd+78cc0
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: sptd
IMAGE_NAME: sptd.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 0
FAILURE_BUCKET_ID: X64_MANUALLY_INITIATED_CRASH_sptd+78cc0
BUCKET_ID: X64_MANUALLY_INITIATED_CRASH_sptd+78cc0
Followup: MachineOwner
---------
Każdy zrzut pamięci jest inny, jednak są stałe elementy (informacje), które pomagają w ustaleniu przyczyny błędu. Jeśli wyciągniemy z tekstu najważniejsze dane to możemy poszukać więcej informacji w wyszukiwarce Google – jest to najbardziej wydajna metoda wyszukiwania rozwiązania błędu. Samo narzędzie WinDbg może posłużyć nam do bardzo szczegółowego analizowania danych, więcej informacji uzyskamy wpisując w programie polecenie .hh.
Źródło: support.microsoft
REKLAMA
Najświeższe informacje o nowych publikacjach w profilu nswmo są na Twiterze - zapraszam.