O stabilności Windows, czyli jak to Microsoft z Niebieskim Ekranem Śmierci walczył

Osoby, które „przesiadły” się z Windows XP na Windows7 i późniejsze wersje „okienek”, na pewno zauważyłyznacząco wyższą stabilność pracy tych systemów. Tak niegdyś częsteniebieskieekrany śmierci stały się zjawiskiem sporadycznym. Co prawdazłośliwi mogą powiedzieć, że w Windows 8 niebieski ekran śmiercizostał zastąpiony niebieskim ekranem śmieci (nawiązując do bałaganu,jaki szybko zaczyna panować na ekranie startowym interfejsu ModernUI), ale nie zmienia to faktu, że Windows stało się naprawdęstabilnym systemem, w desktopowej pracy stabilniejszym nawet odLinuksa. Jak udało się tak odmienić Microsoftowi wizerunek swoichsystemów operacyjnych?Kilka dni temu o pracachzwiązanych z błędami wywołującymi niebieskie ekrany śmierci (BSOD)opowiedzieli badacze z Microsoft Research Lab w Cambridge. Już 10 lattemu wiadomebyło, że zdecydowana większość (nawet 89%) tych kończących pracęsystemu awarii w Windows z jądrem NT wywoływana jest przez sterownikifirm trzecich. Odsetek BSOD-ów generowanych przez inne komponentysystemu był bardzo niski: przykładowo dla jądra, stosu sieciowego czyrejestru wynosił po 2%, a dla systemu plików zaledwie 0,5%. [img=bsod8]Rozwiązanie problemu wynikającegoz niskiej jakości kodu, nad którym nie tylko nie sprawuje się żadnejkontroli, ale też często nie ma się do niego dostępu, nie może byćłatwe. Sprawy nie ułatwiało też to, że liczba sterowników wekosystemie Windows rosła wykładniczo, a wiele z nich wchodziło wzłożone interakcje z innymi sterownikami. Jak stwierdził tymczasemByron Cook, jeden z badaczy Microsoft Research i menedżer grupyProgramming Principles and Tools, wszystkie te elementy muszą działaćw zgodzie z regułami systemu, w przeciwnym wypadku całość ulegnieawarii. Co więc robić? Microsoft poradziłsobie z tym dość pomysłowo. Całą operację rozpoczęto poprzezzbieranie wysyłanych przez użytkowników XP raportów o błędachzwiązanych ze sterownikami i ich kategoryzowanie wg producenta imożliwej przyczyny. Wykryto w ten sposób najbardziej problematycznesterowniki, jak również najbardziej typowe scenariusze, w którychwywoływały one niebieski ekran śmierci. Pierwszym było nieprawidłowewywoływanie przez sterownik funkcji API związanych z komunikacją zjądrem systemu. Drugim, niewłaściwe alokowanie pamięci dla strukturdanych wykorzystywanych przez sterownik, prowadzące do uszkodzeniapamięci. Trzecim zawieszenie systemu przez nieskończoną pętlę wkodzie sterownika.Cook wyjaśnił, że zamiasttestować wszystkie możliwe wypadki, liczbę wywołujących błędysterowników udało się ograniczyć dzięki modelowaniu ich jako systemówformalnych, a następnie automatycznemu dowodzeniu ich poprawności,korzystając z metod matematyki i logiki. W ten sposób powstały trzynarzędzia do automatyzacji procesu wykrywania błędów. Pierwsze znich, Slam, testowało, czy dany fragment oprogramowania poprawniewspółpracuje z wywoływanymi interfejsami systemowymi, drugie, Slayer,analizowało struktury danych powiązanie ze sterownikiem i sprawdzało,czy wykorzystywana przez sterownik pamięć została poprawniezainicjalizowana. Trzecie z narzędzi było jeszczeciekawsze – rozwiązywało w ograniczonym zakresie klasycznyproblemstopu Turinga (w którym chodzi o zbudowanie algorytmu, którybyłby w stanie ocenić, czy dowolny algorytm zakończy swoją pracę dlazadanych na wejściu wartości). Jak wiadomo, problem ten jest ogólnienierozstrzygalny, jednak szczególna natura sterowników sprawia, żemożliwe jest przetestowanie ich pod kątem kończenia pracy. Sterownikibowiem zwykle są małe, nie przekraczają 30 tys. linii kodu, nie mająteż zbyt wielu zagnieżdżonych pętli. Stworzony przez badaczyMicrosoftu Terminator pozwalał na analizowanie sterowników, którychkod nie przekraczał 35 tys. linii, sprawdzając, czy zakończą oneswoją pracę dla wszystkich możliwych danych wejściowych.Efekty wykorzystania tychnarzędzi przekroczyły oczekiwania. Nie tylko znaleziono wiele błędóww sterownikach firm trzecich, ale też i w sterownikach będącychczęścią Windows Driver Development Kit, które często były kopiowaneprzez producentów (wraz z ich usterkami) jako podkładki do utworzeniasterowników dla własnych urządzeń. Automatyczne testy pozwoliły nawykrycie takich nawet błędów, jak zawieszanie Windows XP przezodłączenie myszki w trakcie jej przesuwania (gdy system zapętlał sięw kolejce żądań I/O). Microsoft zdecydował się więc udostępnić jewszystkim producentom sprzętu, w nadziei, że będą w stanie samiodnajdywać błędy w sterownikach.Według Cooka stabilność Windows 7i 8 jest właśnie zasługą tych prac nad sterownikami. W kolejnychlatach udało się wyjaśnić, jakie reguły przy ich pisaniu powinny byćprzestrzegane, ale też jakie właściwości należy analizować woprogramowaniu przed jego wydaniem. Doszliśmy do etapu, w którymniebieski ekran śmierci w ogóle zniknął z Windows 8 – zamiastniego mamy raczej niebieski ekran żalu, pozbawionyniezrozumiałych dla większości użytkowników informacji, zastąpionychprzez smutny komunikat o potrzebie restartu komputera w wyniku błędu.Na pewno jednak widuje się go dziś znacznie rzadziej: jeśli już go spotykamy, to najprawdopodobniej problem dotyczy sprzętu, a nie oprogramowania.