Bluescreen – czyli to, co w informatyce lubimy najbardziej!

No właśnie, czy nie zdarzyło się Wam kiedyś otrzymać legendarny niebieski ekran śmierci w wyniku prostej czynności systemu Windows? Bluescreeny to chyba to, co za czasów 95, Windows Milenium było największą zmorą użytkowników tych że systemów. Cóż przypomnieć sobie można np. jedną z pierwszych prezentacji Windows 98, w której udział brał też Bill Gates jak to w zwyczaju bywa. Gdzie pierwsze co się ukazało oczom widzów słuchających o niezawodności tegoż systemu to był oczywiście bluescreen podczas ładowania się systemu. No cóż zdarza się każdemu. A w tym artykule chciałem opisać do czego mogą się one nam przysłużyć, jak je analizować oraz jak je wywołać.

Screen: Daniel 'zoNE’ Gabryś

Zacznijmy więc może od tego, co może spowodować owy komunikat? Powodów jak zwykle może być wiele, jednak najważniejsze z nich to:
– brak możliwości wykonania danego zadania sprzecznego z jego założeniami
– błędo-twórcze sterowniki firm trzecich (nie autora systemu)
– problemy sprzętowe (np. wina ramu lub dysku twardego)
– przegrzanie komputera
– sterowniki wykonane przez Microsoft (rzadko)
– specjalnie wywołany błąd przez użytkownika
– wciśnięcie przycisku NMI – Non Maskable Interrupt (już niestosowane przy komputerach PC)

To tylko niektóre z przyczyn, jednak najczęściej będzie to przyczyna sterowników firm trzecich działających w KMDF (Kernel-Mode Driver Framework). Niestety w odróżnieniu od UMDF (User-Mode Driver Framework) ten pierwszy ma prawo do nadpisywania pamięci innych aplikacji, a więc i może to powodować umyślne lub nieumyślne spowodowanie owego BSOD.

Przyczyny, czy też zawartości bluescreenów są zapisywane w tzw. minidumpach. I to właśnie dzięki nim możemy się dowiedzieć, co było przyczyną wystąpienia owego.

Wszystkie opcje dotyczące minidumpów możemy ustawić z pozycji:
Computer -> Properties -> Advanced system settings
Advanced -> Startup and Recovery -> Settings…

Czyli w przypadku polskich systemów:
Komputer -> Właściwości -> Zaawansowane ustawienia systemu
Zaawansowane -> Uruchamianie i odzyskiwanie -> Ustawienia…

Screen: Daniel 'zoNE’ Gabryś

Znajdują się tam m.in. taki opcje jak rozmiar pliku dump, czyli „Write debugging information: „, czy też na polski „Zapisywanie informacji o debugowaniu: „. Mamy tutaj do wyboru trzy (w przypadku niektórych systemów dwie) opcje:
– Small memory dump (64KB) – Mały zrzut pamięci (64KB)
– Kernel memory dump – Zrzut pamięci jądra
– Complete memory dump – cala zawartość pamięci fizycznej w czasie BSOD

Screen: Daniel 'zoNE’ Gabryś

Small jest niestety często niewystarczający, a Full nie jest zbyt funkcjonalny z powodów swojej wielkości (i często wymaga innych zmian w systemie, np. zwiększenie rozmiaru pagefile w systemie). Ale o tym nieco później.

Można też ustawić, czy po wystąpieniu bluescreena system ma automatycznie się resetować, czy nie. Służy do tego opcja: „Automatically restart„, czyli „Automatycznie uruchom ponownie„.

W czasie wywołania bluescreena dump jest tworzony dopiero po ponownym resecie systemu, gdyż system najpierw zapisuje te dane do pagefile. I tutaj ukazuje się nam, dlaczego nie powinno się robić Complete memory dump np. przy maszynach z dużą ilością RAMu, gdyż tyle danych, ile było zapisane w pamięci RAM, tyle przeniesione zostanie do pagefile – i nie może on być mniejszy. Dopiero później przy uruchomieniu systemu tworzy się plik *.dmp. Więc konieczne jest ponowne uruchomienie systemu (np. gdybyśmy chcieli uzyskać zdalny dostęp do minidumpa – ale o tym nie w tym artykule).

Co można zrobić, gdy już nam wyskoczy taki komunikat?

Patrząc na statystyki najpierw proponowałbym sprawdzenie sterowników firm trzecich. Najlepiej zaktualizować wszystkie takie sterowniki w celu zapewnienia pełnej ich kompatybilności z systemem.
Następnym krokiem jaki możemy wykonać jest test sprzętu, ale o tym napiszę w następnym artykule. W przypadku wystąpienia bluescreena pokazuje się często również nazwa sterownika, który mógł spowodować jego wywołanie – a dokładniej, w którym mógł wystąpić błąd. Można jego nazwę porównać np. z listą sterowników w [Komputer -> Właściwości -> Menedżer użądzeń] lub w rejestrze (gałąź -> HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServices).
Warto również zajrzeć do systemowego raportu błędów, jakie aplikacje ostatnio wywoływały problemy. Może okazać się, iż tam znajdziemy odpowiedź.
Jeżeli to nie pomogło, to trzeba będzie przejść do analizy pliku dump. I tutaj przechodzimy już do właściwej części artykułu, czyli analizy minidumpów.

Screen: Daniel 'zoNE’ Gabryś

Analiza minidumpów.

Do tych celów będzie nam potrzebny Windows Debugger z pakietu Debugging Tools Microsoftu. Można go pobrać z Debugging Tools prosto ze strony Microsoft’u, wraz z symbolami (które nam się przydadzą do rozszyfrowywania kodów błędów).
https://www.microsoft.com/whdc/devtools/debugging/default.mspx

Przy wystąpieniu bluescreena po uruchomieniu systemu najczęściej pojawi się nam raport o błędach widoczny na poniższym screenie.

Screen: Daniel 'zoNE’ Gabryś

Ścieżkę pliku dump można odczytać z prędzej wymienionych raportów o błędach, wystarczy kliknąć „View problem details” i w szczegółach na dole będzie ścieżka do pliku dump.
Standardowa ścieżka plików dump to najczęściej [Dysk_lokalny(np.C):WindowsMinidump] i tam najczęściej nazwa zaczynająca się od daty np. „062810”.., czyli plik był stworzony 28 czerwca 2010 roku lub od słowa Mini i następnie data w identycznej formie. Rozszerzenie takiego pliku, to *.dmp.

Screen: Daniel 'zoNE’ Gabryś

Gdy już odnajdziemy owy plik, to już bardzo łatwo możemy przystąpić do jego analizy.

Najpierw uruchamiamy WinDBG już z zainstalowanymi symbolami. Jeżeli jednak nie ściągaliśmy symboli (to ok. 200-350MB na system), to możemy podać do nich ścieżkę, by program porównywał z symbolami z serwera. Robimy to przy pomocy menu [File -> Symbol File Path…].

A oto ta okropnie wyglądająca ścieżka:
SRV*DownstreamStore*https://msdl.microsoft.com/download/symbols

czyli np.:
SRV*c:symbols*https://msdl.microsoft.com/download/symbols

Gdy już mamy przygotowany Windows Debugger do pracy, to przystępujemy to otworzenia pliku dump, który chcemy przeanalizować. Kolejno [File -> Open Crash Dump]. Gdy program zada pytanie „Save information for workspace?„, oczywiście odpowiadamy NO. I czekamy, aż program przeanalizuje cały monit o błędzie.

Naszym oczom winno ukazać się coś podobnego do tego:

Screen: Daniel 'zoNE’ Gabryś

I tutaj jak w niewielu przypadkach już na samym starcie mamy dosyć trafną informację:
„Probably caused by : myfault.sys ( myfault+579 ) „
Co oznacza nic innego, jak prawdopodobnie spowodowane przez sterownik myfault.sys. I oczywiście jest to prawda, gdyż do wywołania tego bluescreena użyłem aplikacji NotMyFault (ale o niej nieco dalej).

Jednak nie zawsze odpowiedź będzie tak szybko dostępna i dla Nas jasna.. Co zrobić w takim przypadku?
Np. możemy użyć komendy !analyze -v, co proponuje nam nawet sam program. Po jej użyciu otrzymamy więcej szczegółów na temat crashu.

Otrzymamy wtedy informacje podobne jak na kolejnym screenie:

Screen: Daniel 'zoNE’ Gabryś

I co możemy z tego wyczytać? Istotną sprawą, jaką możemy z takiej analizy wyczytać jest np. rodzaj błędu (w tym wypadku jest to DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1) ), rozszyfrowaną listę parametrów. Teraz na liście mamy cztery parametry:
Arg1: df312800, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: a959c579, address which referenced memory

Które mogą nas naprowadzić na problem. Następnie PROCESS_NAME: NotMyfault.exe, który znaliśmy już wcześniej, dokładny opis tego modułu, stos itd.

W tym wypadku to było oczywiście wysokie IRQL dla trybu jądra wywołane sterownikiem NotMyFault autorstwa Marka Russinovicha.

Jeżeli to za mało informacji możemy wywołać komendę lmvm, czyli informacje na temat tego procesu (wystarczy kliknąć w module name).
Poza tym mamy jeszcze do dyspozycji m.in. komendę !process 0 0 (zero zero), która wyświetli nam procesy, jakie były wtedy odpalone.

Może się też tak zdarzyć, iż nie otrzymamy w ogóle informacji nt. prawdopodobnego błędnego sterownika. W takim wypadku istnieje bardzo prosta w obsłudze aplikacja dołączona już w systemie, która pozwoli nam na śledzenie podejrzanych ruchów wybranych przez Nas lub wszystkich sterowników. Nosi ona nazwę Verifier i odpala się ją z pozycji command line (wiersza poleceń) [menu start -> uruchom.. -> cmd] komendą verifier. Wygląda ona mniej więcej tak:

Screen: Daniel 'zoNE’ Gabryś

Jest ona banalna w obsłudze i po kolei wybieramy „Create standard settings” – „Utwórz ustawienia standardowe” lub „Create custom settings” – „Utwórz ustawienia niestandardowe” i w tym wypadku zaznaczamy jedynie tickiem „standard settings” – „ustawienia standardowe„. Następnie „Select driver names from a list” – „Wybierz nazwy sterowników z listy” i zaznaczamy interesujące nas sterowniki (najlepiej zacząć jedynie od skanowania tych, które nie zostały wydane przez Microsoft). W tym celu możemy sobie je posortować wg dostawcy. I klikamy opcję Finish. Następnie restartujemy system i gdy następnym razem wyskoczy nam bluescreen – z tego samego lub innego powodu – tym razem będzie lepiej opisany w debuggerze.

Jak wywołać samodzielnie bluescreena?

Teraz może opowiedzmy o tym, jak wywołać owego bluescreena? Sposobów na wywołanie BSoD jest bardzo wiele – wymienię więc tylko niektóre z nich.

1. Pierwszym i chyba najłatwiejszym sposobem wywołania bluescreena w danym momencie jest program NotMyFault stworzony przez wcześniej wspomnianego Marka Russinovicha.
Jest to program, którego użyłem do wywołania bluescreena, którego analiza była opisana w powyższym artykule. Np. poprzez podniesienie poziomu IRQL.
Program można pobrać pod adresem:
https://download.sysinternals.com/Files/Notmyfault.zip

Screen: Daniel 'zoNE’ Gabryś

Razem z programem są dostępne źródła i oczywiście wersje dla systemu 32 i 64-bitowego.
W przypadku nowszych systemów może wymagać uruchomienia jako administrator.

2. Innym, ale równie prostym sposobem wywołania bluescreena jest klawiatura komputera. Aby wywołać go przy pomocy klawiatury należy w rejestrze zastosować kilka zmian.

W przypadku sterownika (systemowego) do klawiatury PS/2 w kluczu: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesi8042prtParameters
Odszukujemy wartości o nazwie CrashOnCtrlScroll, jeżeli nie istnieje tworzymy nowy wpis o takiej właśnie nazwie, typu REG_DWORD oraz wartości 1 (0 – wyłączone, 1 – włączone).

Gdy mamy do czynienia ze sterownikiem (systemowym) do klawiatury USB robimy to samo, ale na kluczu: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServiceskbdhidParameters
Czyli odszukujemy lub tworzymy nowy wpis o nazwie CrashOnCtrlScroll, typie REG_DWORD oraz wartości 1.

Po wprowadzeniu owych zmian, będziemy mogli wywołać niebieski ekran przy pomocy kombinacji klawiszy prawy CTRL + dwukrotne kliknięcie Scroll Lock.

Niestety nie zawsze to rozwiązanie działa w przypadku wirtualnych maszyn oraz klawiatur innych, niż PS/2.

3. Kolejnym sposobem wywołania sztucznego niebieskiego ekranu może być użycie komendy .crash w Windows Debuggerze. Wywołuje ona sztuczny ekran bluescreena. Można ją np. wywołać z pozycji drugiej maszyny wirtualnej na systemie w trybie /debug.

4. Za pomocą wcześniej wspomnianego przycisku NMI (Non Maskable Interrupt), który pojawia się na niektórych obudowach.

Poza tymi sposobami istnieje jeszcze wiele innych sposobów, ale myślę iż te cztery są wystarczające.

Zmiana koloru bluescreena..

No właśnie, czy bluescreen tak naprawdę musi być blue? Na koniec chciałem Wam pokazać, jak można w prosty sposób zmienić kolor BSOD. Bo bluescreen nie koniecznie musi być niebieski.

Aby tego dokonać należy odszukać pliku [%systemroot%/SYSTEM.INI] (np. uruchomić go przez polecenie uruchom..). Tam odszukać, a jeżeli nie istnieje to stworzyć sekcję [386enh] oraz nadać jej konkretne wpisy:
MessageBackColor= – tło bluescreena
MessageTextColor= – czcionka
I nadać im wartości konkretnego koloru z palety 16 kolorów w systemie szesnastkowym.
Czyli:

• 0 = black
• 1 = blue
• 2 = green
• 3 = cyan
• 4 = red
• 5 = magenta
• 6 = yellow/brown
• 7 = white
• 8 = gray
• 9 = bright blue
• A = bright green
• B = bright cyan
• C = bright red
• D = bright magenta
• E = bright yellow
• F = bright white

Dla przykładu wpis:
[386enh]
MessageBackColor=4
MessageTextColor=6

będzie powodował zmianę tła na czerwone i czcionki na kolor żółty.

Autor: Daniel 'zoNE’ Gabryś