Polecenia debugera

Jeśli udało nam się załadować zrzut pamięci do debugera, możemy przystąpić do jego analizy. Będziemy używać dwóch poleceń !analyze -v oraz lmv. Pierwsze z nich wyświetla informacje opisujące stan systemu w chwili awarii, napotkany błąd i typuje głównego podejrzanego. Drugie wyświetla listę sterowników wraz ze ścieżkami, wersją i danymi o producencie. Często zawiera opis produktu.

Analiza - !analyze -v

Na zrzucie ekranu możemy zobaczyć działanie polecenia !analyze -v zastosowanego do analizy wygenerowanego przez Windows XP pliku typu minidump. Interesującą nas sekcją jest Debbugging Details.

Tam możemy znaleźć zapis DEFAULT_BUCKET_ID: określający ogólną kategorię błędu oraz wartość DRIVER_FAULT, wskazującą, że prawdopodobną przyczyną awarii był sterownik. Dalej znajdujemy IMAGE_NAME: atidrab.dll i już wiemy, że prawdopodobną przyczyną awarii systemu był problem ze sterownikiem atidrab.dll.

Więcej szczegółów o podejrzanym - lmv

Następnym krokiem jest zdobycie więcej informacji o wytypowanym już podejrzanym. Polecenie lm wyświetla załadowane moduły zaś dodanie v nakazuje debugerowi zwracanie rozbudowanych informacji (verbose modę) o modułach. Ponieważ polecenie lmv spowoduje wypisanie ogromnej ilości informacji, by odszukać interesujący nas fragment, warto skorzystać z polecenia find (CTRL+F lub menu edit|Find). W omawianym przykładzie okazało się, że przyczyną awarii systemu był sterownik karty graficznej ATI. Gdy już wiemy, jaki plik spowodował awarię i kto jest jego producentem, możemy poszukać w Internecie aktualizacji oprogramowania bądź informacji, jak rozwiązać problem.

Czasami jest trudniej

Z pomocą tego debugera znalezienie przyczyny problemu jest najczęściej proste. Niemniej jednak może okazać się, że WinDbg dostarczy nam informacje wprowadzające w błąd bądź niewystarczające do rozwiązania problemu.

Jeśli awarie powtarzają się często i za każdym razem dostajemy inną informację o przyczynie, warto przetestować pamięć komputera. W Internecie jest dostępnych wiele darmowych narzędzi, jak np. Memtest86.

Jeśli debuger mówi, że przyczyną problemu jest ntoskernl.exe (jądro systemu Windows) bądź plik win32.sys (sterownik odpowiedzialny za warstwę graficzną interfejsu systemu Windows), warto zastanowić się, czy źródłem problemu nie był jednak jakiś sterownik żądający od komponentu Windows wykonania nieprawidłowej instrukcji np. odwołania do nieistniejącego obszaru pamięci.

Antywirus winowajcą?

Czasami w wygenerowanym poleceniem !analyze -v raporcie pojawia się rekord IMAGE_NAME, zawierający nazwę sterownika używanego na komputerze programu antywirusowego. Program antywirusowy musi śledzić wszystkie otwarcia i zamknięcia plików. By móc to zrealizować, jego kod jest umieszczony w warstwie systemu operacyjnego i nieustannie pracuje, może pojawić się na stosie wywołań funkcji aktywnych w chwili awarii, a nie być jej przyczyną. Jednakże jako sterownik pochodzący od innego producenta zostanie wskazany jako winowajca.

Brak informacji o producencie

Niestety nie wszyscy producenci umieszczają informacje w sterownikach. Może się zdarzyć, że po wywołaniu polecenia lmv nawet nie poznamy nazwy producenta pliku. Możemy próbować przeszukać klucze rejestru zawierające ten plik, tudzież folder, w którym się on znajduje. Jeśli i tu nie znajdziemy takiej informacji, najsensowniej jest wtedy wpisać nazwę podejrzanego pliku do wyszukiwarki.

Podsumowanie

Po awarii systemu najwyższym priorytetem jest przywrócenie go do pracy. Niemniej jednak istotnym jest usunięcie przyczyny awarii, szczególnie jeśli maszyną, która jej uległa, jest pracujący non stop serwer . Jak widać debuger może okazać się w tym celu użyteczny i nie wymaga, jakby się na pierwszy rzut oka mogło wydawać, wiedzy programistycznej.