Driver Verifier

Kiedys, mój ówczesny szef, przedstawiajac mnie wspólpracownikom powiedzial, ze uzywam wyszukiwarek tylko po to, zeby znalezc cos, co juz na pewno opisalem na blogu. Pomijajac juz to, jak takie stwierdzenie lechce ego (czego dowodem jest, ze je po latach pamietam), to mysle, ze tak naprawde, takie podejscie nie jest obce nikomu, kto prowadzi bloga dluzej niz kilka miesiecy. No bo o ile nowosci na pewno nigdy opisywane wczesniej nie byly, o tyle jakiestam mniej lub bardziej zaawansowane szczególy i szczególiki czasem tak dlugo ma sie w glowie na liscie "do opisania", ze potem czlowiek naprawde mocno sie dziwi, gdy chce znalezc linka do swojego artykulu a tu okazuje sie, ze on nigdy nie powstal... Ja mialem tak wczoraj, gdy próbowalem znalezc przepis na postepowanie w przypadku wystepowania BSOD z kodem 0x19 BAD_POOL_HEADER.

Blad ten jest nietrywialny do przeanalizowania, poniewaz powstaje w sytuacji, gdy sterownik siegnie do puli pamieci, której naglówek zostal przez kogos popsuty. Podstawowa analiza wskazuje wiec "ofiare" a nie winnego calej sytuacji.  Prawdziwym winnym jest ten, kto popsul, a w momencie pojawienia sie blue screena nie mamy zadnych wyraznych sladów kto to byl i kiedy to zrobil ani dlaczego. Biorac pod uwage, ze prawie 80% blue screenów spowodowane jest przez sterowniki firm trzecich, mozemy strzelac w ciemno i próbowac aktualizowac oprogramowanie do karty graficznej czy sieciowej, jednak nie ma to wiele wspólnego z rzetelnym naukowym podejsciem do tematu. Analiza dumpa wiele nam nie da, bo wskaze ofiare. Co wiec pozostaje? Otóz trzeba zlapac winnego na goracym uczynku, w momencie, gdy próbuje modyfikowac nie swoje obszary pamieci. Nie jest to az takie trudne, poniewaz mamy do dyspozycji potezne narzedzie, które (z nie do konca dla mnie zrozumialych powodów) lezy i czeka na dysku kazdego komputera wyposazonego w system Windows. Mowa o Driver Verifier.

Generalnie rzecz ujmujac, Driver Verifier sprawia, ze mechanizmy dzialajace w jadrze systemu i wspólpracujace ze sterownikami zaczynaja byc nieco mniej ufne i szczególowo przygladaja sie kazdej czynnosci. Czy aby na pewno sterownik zwalnia cala pamiec, gdy przestaje dzialac? Czy pracujacy w trybie jadra sterownik nie siega w brzydki sposób do pamieci w trybie uzytkownika? Czy to, czego sterownik próbuje uzyc jako uchwytu, faktycznie jest uchwytem?

Jedna z mozliwosci jadra jest na przyklad takie alokowanie zadanych puli pamieci, aby nie dalo sie do nich wejsc przypadkiem. Wiekszosc bledów zwiazanych z zamazaniem przez zle napisany sterownik cudzych obszarów pamieci bierze sie stad, ze sterownik taki, zapisujac bajt po bajcie, w któryms momencie wyjdzie poza swój obszar. Jezeli nastepny obszar nalezy do kogos innego, to katastrofa gotowa a winnego po fakcie moze byc trudno wskazac. Zabezpieczenie przed tym nie jest bardzo zlozone – wystarczy, zamiast umieszczac jeden blok pamieci za drugim, rozdzielic bloki obszarem ziemi niczyjej. Celowo nikt tam nie wejdzie a przypadkowy dostep zostanie natychmiast zauwazony i wywola BSOD o numerze 0xCD PAGE_FAULT_BEYOND_END_OF_ALLOCATION. Jaki mamy efekt w przypadku opisanym na poczatku? Zamiast bledu 0x19 pojawia sie blad 0xCD. Nie brzmi to moze szczególnie atrakcyjnie, bo w koncu blue screen to blue screen, ale róznica jest niezwykle istotna: identyfikujemy winnego a nie ofiare! A to juz nienajgorszy start do skutecznego wyeliminowania lobuza z naszego systemu.

Wrócmy do narzedzia. Poniewaz Driver Verifier stosowany bywa przez programistów do badania poprawnosci dzialania pisanych przez nich sterowników, jego funkcjonalnosc jest znaczaco wieksza niz to, czego potrzebuje uzytkownik walczacy z trudnym BSOD. Dlatego, najlepiej podejsc do niego z precyzyjna instrukcja:

• Uruchomic aplikacje verifier.exe. Lezy w folderze system32 i musi byc uruchamiana z uprawnieniami administratora.
  
• Mozna uzyc "Standard Settings" – ten zestaw ustawen (opisany dokladnie w MSDN) pozwala na wykrycie typowych problemów i jest bardzo dobrym punktem wyjscia.
• Korzystamy z opcji "Select driver names from a list"
• Sortujemy sterowniki po kolumnie "Provider" i na poczatku i koncu listy zaznaczamy wszystkie te, które nie sa dostarczone przez Microsoft. I tak nie powinnismy weryfikowac dzialania wszystkich sterowników na raz, a statystyki mówia, ze znalezienie czegokolwiek jest znaczaco bardziej prawdopodobne w kodzie firm trzecich.
  
• Jezeli w dumpie daja sie znalezc sterowniki (polecenie "lmof" w WinDbg moze byc tu pomocne), których nie ma na liscie Verifiera, bo nie sa w momencie jego uruchamiania zaladowane, mozna je dodac manualnie.
• Klikamy "Finish" i restartujemy komputer.

Wydajnosc komputera jest nieco ograniczona (dlatego praca z Verifierem stale aktywnym nie jest polecana) ale wszystko dziala. A gdy zdarzy sie blad, dowiemy sie o nim natychmiast a jego analiza nie powinna juz byc trudna. Po znalezieniu winnego i wyeliminowaniu problemu, nalezy ponownie uruchomic verifier.exe i korzystajac z opcji "Delete existing settings" i restartu, przelaczyc system w normalny tryb pracy.

Do pelni obrazu, dodalbym jeszcze kilka waznych uwag koncowych:

• Jezeli chcemy sie czegos nowego nauczyc, pobawic Verifierem a uparcie nie pojawiaja nam sie BSODy, to polecam uzycie aplikacji NotMyFault. Na maszynie wirtualnej a nie na produkcyjnym systemie! Nawet, jezeli cos sobie popsujemy, to snapshoty pomoga nam oszczedzic sporo czasu. W przypadku NotMyFault, konieczne bedzie weryfikowanie sterownika myfault.sys – jezeli nie ma go na liscie, to przycisk "Add currently not loaded driver(s) to the list..." w opcjach Verifiera na pewno sie przyda.
• Jezeli mamy pecha, to "ratowniczy" blue screen pojawi sie zanim bedzie mozliwe zalogowanie sie do systemu. Zeby móc opanowac system czy zainstalowac zaktualizowany sterownik, musimy jednak jakos Verifiera odpalic. Pomoze nam w tym Safe Mode, ale warto wiedziec, ze ten tryb potrafimy wlaczyc zanim pierwszy raz uruchomimy verifier.exe.
• Uwazajmy zanim komus "zyczliwemu" wyslemy nasz dump do analizy. Sa w nim poufne informacje (na przyklad hasla) i beztroskie publikowanie dumpów na forach niekoniecznie jest najlepszym podejsciem.
• Pamietajmy, ze przyczyna istotnej czesci BSOD sa problemy sprzetowe. Niestety nie jest to proste do wykrycia i czesto tracimy wiele czasu na walke z przedziwnymi objawami. Poszukujac przyczyn klopotów, nie wolno o sprzecie zapominac.

A tak naprawde, to nikomu nie zycze potrzeby uzywania takich narzedzi.

Autor: Grzegorz Tworek [MVP]

PS sprawdzajac szybko czy zamiast pisac sam, nie znajde gdzies gotowego do polecenia przepisu na poradzenie sobie z BSOD 0x19 trafilem na jeden wyjatkowo kuriozalny. Chyba nie polecam.

Comments

• Anonymous
  December 13, 2013
  Dzieki wielkie naprawde ciekawy artykul