Osoby, które „przesiadły” się z Windows XP na Windows 7 i późniejsze wersje „okienek”, na pewno zauważyły znacząco wyższą stabilność pracy tych systemów. Tak niegdyś częste niebieskie ekrany śmierci stały się zjawiskiem sporadycznym. Co prawda złośliwi mogą powiedzieć, że w Windows 8 niebieski ekran śmierci został zastąpiony niebieskim ekranem śmieci (nawiązując do bałaganu, jaki szybko zaczyna panować na ekranie startowym interfejsu Modern UI), ale nie zmienia to faktu, że Windows stało się naprawdę stabilnym systemem, w desktopowej pracy stabilniejszym nawet od Linuksa. Jak udało się tak odmienić Microsoftowi wizerunek swoich systemów operacyjnych?

Kilka dni temu o pracach związanych z błędami wywołującymi niebieskie ekrany śmierci (BSOD) opowiedzieli badacze z Microsoft Research Lab w Cambridge. Już 10 lat temu wiadome było, że zdecydowana większość (nawet 89%) tych kończących pracę systemu awarii w Windows z jądrem NT wywoływana jest przez sterowniki firm trzecich. Odsetek BSOD-ów generowanych przez inne komponenty systemu był bardzo niski: przykładowo dla jądra, stosu sieciowego czy rejestru wynosił po 2%, a dla systemu plików zaledwie 0,5%.

Rozwiązanie problemu wynikającego z niskiej jakości kodu, nad którym nie tylko nie sprawuje się żadnej kontroli, 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 w ekosystemie Windows rosła wykładniczo, a wiele z nich wchodziło w złożone interakcje z innymi sterownikami. Jak stwierdził tymczasem Byron Cook, jeden z badaczy Microsoft Research i menedżer grupy Programming Principles and Tools, wszystkie te elementy muszą działać w zgodzie z regułami systemu, w przeciwnym wypadku całość ulegnie awarii.

Co więc robić? Microsoft poradził sobie z tym dość pomysłowo. Całą operację rozpoczęto poprzez zbieranie


wysyłanych przez użytkowników XP raportów o błędach związanych ze sterownikami i ich kategoryzowanie wg producenta i możliwej przyczyny. Wykryto w ten sposób najbardziej problematyczne sterowniki, jak również najbardziej typowe scenariusze, w których wywoływały one niebieski ekran śmierci. Pierwszym było nieprawidłowe wywoływanie przez sterownik funkcji API związanych z komunikacją z jądrem systemu. Drugim, niewłaściwe alokowanie pamięci dla struktur danych wykorzystywanych przez sterownik, prowadzące do uszkodzenia pamięci. Trzecim zawieszenie systemu przez nieskończoną pętlę w kodzie sterownika.

Cook wyjaśnił, że zamiast testować wszystkie możliwe wypadki, liczbę wywołujących błędy sterowników udało się ograniczyć dzięki modelowaniu ich jako systemów formalnych, a następnie automatycznemu dowodzeniu ich poprawności, korzystając z metod matematyki i logiki. W ten sposób powstały trzy narzędzia do automatyzacji procesu wykrywania błędów. Pierwsze z nich, Slam, testowało, czy dany fragment oprogramowania poprawnie współ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 poprawnie zainicjalizowana.

Trzecie z narzędzi było jeszcze ciekawsze – rozwiązywało w ograniczonym zakresie klasyczny problem stopu Turinga (w którym chodzi o zbudowanie algorytmu, który byłby w stanie ocenić, czy dowolny algorytm zakończy swoją pracę dla zadanych na wejściu wartości). Jak wiadomo, problem ten jest ogólnie nierozstrzygalny, jednak szczególna natura sterowników sprawia, że możliwe jest przetestowanie ich pod kątem kończenia pracy. Sterowniki bowiem zwykle są małe, nie przekraczają 30 tys. linii kodu, nie mają też zbyt wielu zagnieżdżonych pętli. Stworzony przez badaczy Microsoftu Terminator pozwalał na analizowanie sterowników, których kod nie przekraczał 35 tys. linii, sprawdzając, czy zakończą one swoją pracę dla wszystkich możliwych danych wejściowych.

Efekty wykorzystania tych narzędzi przekroczyły oczekiwania. Nie tylko znaleziono wiele błędów w sterownikach firm trzecich, ale też i w sterownikach będących częścią Windows Driver Development Kit, które często były kopiowane przez producentów (wraz z ich usterkami) jako podkładki do utworzenia sterowników dla własnych urządzeń. Automatyczne testy pozwoliły na wykrycie takich nawet błędów, jak zawieszanie Windows XP przez odłączenie myszki w trakcie jej przesuwania (gdy system zapętlał się w kolejce żądań I/O). Microsoft zdecydował się więc udostępnić je wszystkim producentom sprzętu, w nadziei, że będą w stanie sami odnajdywać błędy w sterownikach.

Według Cooka stabilność Windows 7 i 8 jest właśnie zasługą tych prac nad sterownikami. W kolejnych latach udało się wyjaśnić, jakie reguły przy ich pisaniu powinny być przestrzegane, ale też jakie właściwości należy analizować w oprogramowaniu przed jego wydaniem. Doszliśmy do etapu, w którym niebieski ekran śmierci w ogóle zniknął z Windows 8 – zamiast niego mamy raczej niebieski ekran żalu, pozbawiony niezrozumiałych dla większości użytkowników informacji, zastąpionych przez 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.