22 lipca 2011

Nie ignoruj bluescreen'a

Analiza crush dump'a - podstway


Niedawno obejrzałem dosyć stary już webcast Windows Hang and Crash Dump Analysis, w którym Mark Russinovich (człowiek od Sysinternals Suite) udowodnił mi, że nie trzeba być geniuszem, żeby wykonać analizę crush dump'a (bluescreen przeważnie produkuje memory dumpa). Czytelników spragnionych szczegółów i dokładniejszych wyjaśnień odsyłam do obejrzenia w całości tego ciekawego webcast'u.

Bluescreen - zdarzy się, ale kto by się przejmował


Na szczęście na codzień w pracy nie muszę zajmować się środowiskiem serwerowym, zatem większość bluescreen'ów otrzymałem na moich stacjach roboczych (w pracy, w domu). Czasami efektem bluescreen'u może być niespodziewany restart. Niestety nigdy nie wpadłem na pomysł, żeby przeprowadzić bardziej wnikliwą analizę tego zjawiska. Podczas crash'u memory dump najpierw zapisywany jest do page file'a, a później generowany jest memory dump (mini-dumpy są zawsze generowany z datą w nazwie pliku, u mnie  lądują w folderze C:\Windows\Minidump\ ). W Windows 7 Microsoft zostawił tylko możliwość generowania zrzutów Kernel-memory lub Small memory dump, w sumie zrzut 8GB pamięci na dysk trochę by musiał trwać i wymagałby dodatkowego miejsca na dysku. (Aby dostać się do ustawień rodzaju zrzutu pamięci wybierz prawym Computer później Properties -> Advanced System settings -> Zakładka Advanced ->Wybierz dla Startup and Recovery przycisk Settings. ).





Jeżeli mamy do dyspozycji Wirtualną Maszynę to można sobie wygenerować bluescreena narzędziem NotMyFault (autor oczywiście   Mark Russinovich). Na własne ryzyko, zabawa uszkodzonym driverem  zawsze wiąże się z możliwością uszkodzenia np. danych. Przykład wygenerowania bluescreena na Windows Server 2008 R2 zamieszczam poniżej na potrzeby demo. Widać że na załączonym obrazku, że system jeszcze generuje crash-dumpa dla kernel-memory (zajmuję to trochę czasu bo to nie jest mini-dump i 256kb).



Jeżeli nie zdąrzyliśmy zarejestrować nazwy problematycznego drivera z bluescreen'a (jeżeli jest dostępny w używanej przez nas wersji Windows) to polecam  sciągnięcie Debugging Tools for Windows i odpalenie WinDbg. Zanim zaczenie się analizę memory dump'a warto ustawić ścieżkę do Microsoft Symbols Server aby pobrać pliki symboli pdb dla systemu Windows. Jeżeli lokalnie będziemy składować pliki w katalogu c:\symbols to dialog File->Symbol File Path (Ctrl+S) powinien wyglądać następująco.


SRV*c:\symbols*http://msdl.microsoft.com/download/symbols

Po uporaniu się z symbolami, możemy załadować memory dump'a (lub mini-dump'a) i "zabrać się" do analizy.


Po załadowaniu pliku i uruchomienieniu w WinDbg poniżeszj komendy powoduje dostarczenie bardziej dokładnych informacji o driverze który spowodował całe zamieszanie.

!analyze -v


Na powyższym obrazku widać problematyczny driver o nazwie myfault.sys. Można oczywiście uniknąć uruchamiania WinDbg i skorzystać ze strony Instant Online Crash Analysis i wrzucić swój mini-dump do analizy tego narzędzia.


Po zlokalizowaniu drivera (myfault.sys) trzeba niestety użyć Google'a aby wybadać co z tym fantem zrobić i określić przez które oprogramowanie z naszego systemu jest używany (u mnie kiedyś szwankował 3rd party firewall).

2 komentarze:

  1. 99% blue screenów to błędy driverów. Niestety to psuje obraz systemu. Mnóstwo ludzi pisze o jego awaryjności, o tym jaki to Bill jest zły itp. Nie wgłębiają się bardziej szczegółowo w powody, którymi w 99% jest właśnie jakiś 3rd party driver. Zdarza się niestety, że nawet podpisany cyfrowo przez MS driver powoduje crash. Ale i za to nie należy winić twórców systemu.
    windbg jest bardzo przydatnym narzędziem.

    OdpowiedzUsuń
  2. Mr Russinovich w prezentacji z 2006, którą wspominam na początku postu, twierdzi, że tylko 5% crashów to drivery MS. Mamy rok 2011, domyślam się, że tak jak napisałeś ten procent jeszcze spadł.

    OdpowiedzUsuń

Uwaga: tylko uczestnik tego bloga może przesyłać komentarze.