Diagnostika a řešení bluescreenu, 2. část

V předchozím článku jsem stručně popsal co to je bluescreen1, naznačil že je možné ho řešit a popsal jak si ověřit, že je systém správně nakonfigurovaný pro generování dumpů. Dnes bych rád představil nástroj, který lze použít pro jejich analýzu, a prošel řešení dvou konkrétních bugchecků.

Utilitka kterou chci ukázat se jmenuje BlueScreen View od Nira Sofera. Je ke stažení dokonce v češtině, ačkoliv o pár verzí starší. Já budu v ukázkách používat anglickou. BlueScreen View není třeba instalovat, stačí rozbalit a spustit. Sám si pak najde adresář s minidumpy (ve výchozím stavu C:\Windows\Minidump) a zobrazí jejich seznam.

Aplikace BlueScreen View

Aplikace BlueScreen View

V horní části okna je seznam záznamů o pádu systému (crash dumpů) a základních informací k nim. Mezi nejzajímavější sloupečky patří:

  • Crash time – Datum vytvoření minidumpu (a tedy i zároveň datum popsaného pádu systému).
  • Bug Check String – Popisný kód chyby, která způsobila pád systému. Přestože jejich pochopení vyžaduje hlubší znalosti kernelu Windows, přeci jen jsou srozumitelnější než samotný Bug Check Code. Jsou jedním z výchozích bodů pro vyhledání příčiny problému.
  • Parameter 14 – Používají se pro podrobnější analýzu.
  • Caused By Driver – Pravděpodobný původce chyby. Často může stačit tato jediná položka k nalezení viníka, ačkoliv já bych doporučoval k jeho usvědčení ještě kouknout do výpisu driverů.

V dolní části okna se po vybrání konkrétního crash dumpu zobrazí seznam driverů aktivních v okamžik pádu systému. Většina ze zobrazených ovladačů jsou pro nás irelevantní, a proto jsou potenciální viníci (obvykle 1-2) podbarveni růžově. Tady se vyplatí kouknout alespoň na sloupečky:

  • Filename – Jméno souboru ovladače.
  • Product Name a File Description – K jakému produktu ovladač patří a jaká je jeho funkce.
  • Full Path (úplně na konci) – Umístění souboru.

Už v tuto chvíli za pomoci pouze selského rozumu a Googlu budete schopni identifikovat velkou část zdrojů problémů. Osobně doporučuji postupovat v krocích:

  1. Zkontrolovat seznam driverů, které mohly problém způsobit (růžově podbarvených).
    Pokud je jich víc, tak ntoskrnl.exe a hal.dll lze obvykle omilostnit. Jedná se o nejniternější kernel Windows, který proto často bývá u chyby přítomen, ale málokdy sám způsobuje pád. Stejně tak i v ostatních Microsoftích driverech bych hledal zdroj chyby až nakonec.
    Pokud zůstal jediný driver, tak obvykle Product Name a File Description napoví co je zač a viník je nalezen. Pokud se ovšem chcete do problému ponořit hlouběji, nebo se zdá že chyba je v ntoskrnt.exe, je potřeba pokračovat na Bug Check String.
  2. Koukněte na Bug Check String. Pokud je vám z něj jasné kde je chyba, tak máte vyhráno. 🙂 Pokud ne, tak zkuste Google. Ovšem i Bug check string může často znamenat mnoho věcí, takže nezbývá než zkontrolovat Parametry.
  3. Jako poslední možnost otvírám MSDN Bug Check Code Reference, kde je přehledný seznam všech možných Bug checků a, co je důležité, k nim i popis parametrů. Tady nejde doporučit nic obecně, prostě si pročtěte co je tam napsáno a je dost možné, že to pomůže.

Příklad 1 – Chybný driver

Jako první k vyřešení jsem vybral tento problém:

DRIVER_Bug Check IRQL_NOT_LESS_OR_EQUAL

Bug Check DRIVER_IRQL_NOT_LESS_OR_EQUAL

Abych postupoval podle kroků které jsem nastínil výše, tak nejprve se podívám na seznam potenciálních viníků – vidím ntoskrnl.exe a WpsHelper.sys. Kernel vynechám, protože v něm chybu nepředpokládám (a stejně by nebylo jak ji řešit), takže zbývá WpsHelper.sys. Ovšem nedokážu určit co je zač, protože u něj nevidím Product Name a File Description. To proto, že tyto informace nejsou obsažené v minidumpu, ale dotahují se z metadat souboru. Když se nic nezobrazí, znamená to že soubor (už) v systému není, nebo je přemístěn. V tomto případě to lze očekávat, jelikož tento minidump je z jiného stroje, než na jakém ho analyzuji. Nezbývá tedy než zkusit Google, který záhy odhalí, že se jedná o součást Symantec Endpoint Protection. Dobrá tedy, původce chyby jsme našli, ale pojďme dál a zkusme vyhledat Bug Check String DRIVER_IRQL_NOT_LESS_OR_EQUAL na MSDN. Jedná se o jednu z obvyklých chyb špatných (nebo nekompatibilních s verzí systému) driverů. V podstatě to znamená, že driver běžel v prioritnějším kontextu2 a vyžadoval služby někoho, kdo běžel v méně prioritním kontextu.3 Podrobnější zkoumání parametrů a jejich srovnání s MSDN odhalí, že driver se snažil volat funkci, která nebyla v paměti (možná funkci jiného driveru, který nebyl nahraný). To už je ale detail. Důležité je, že máme viníka, že víme, že to je jeho chyba a ne hardwaru, a že jako řešení můžeme zkusit Symantec aktualizovat na novější verzi, nebo ho (a jemu podobné malwary4) úplně odinstalovat.

Příklad 2 – Malware nebo paměť

Jako druhý příklad jsem vybral náročnější problém:

Bug Check CRITICAL_OBJECT_TERMINATION

Bug Check CRITICAL_OBJECT_TERMINATION

Tady je situace o poznání složitější v tom, že krom kernelu není na koho chybu svést. Nezbývá tedy než rovnou zabrouzdat na MSDN pro CRITICAL_OBJECT_TERMINATION. Dozvíme se, že byl nečekaně ukončen systémový proces nebo vlákno. Ne že by to bylo nic neříkající, ale v řešení to stále nepomáhá. Bohužel i první pohled na parametry pomůže jen zúžit pole kandidátů na procesy (Parameter 1 je 0x3). Ostatní parametry slibují, že by se dalo zjistit, o jaký proces šlo, ale k tomu bohužel už nestačí BlueScreen View. Přestože zjistit přesně komponentu Windows, která spadla je těžší5, jejich výčet je relativně krátký. Pro zájemce mezi ně patří smss.exe, csrss.exe, lsass.exe, wininit.exe, services.exe a některé z svchost.exe. Ovšem stále nevíme, co pád mohlo způsobit a upřímně řečeno se to možná ani nikdy nedovíme. Může to být chyba pamětí, malware, který proces ukončil, nebo jen šťouravý uživatel s admin právy a Task managerem (Správcem úloh). Pokud se chyba opakuje, tak nezbývá než udělat kernel dump (viz předchozí článek) a společně s informacemi o systému předat někomu zkušenějšímu.

Takto bych mohl pokračovat s dalšími příklady, ale myslím, že jako úvod to postačí. Každopádně doufám, že vám můj článek pomohl trochu lépe porozumět Windows a snad i pomůže někdy vyřešit praktický problém. Pokud se tak stane, budu nesmírně rád, když necháte zprávu v komentářích.

A ještě upoutávka na příště – k článkům o vnitřnostech Windows bych se rád v budoucnu vrátil s mimořádně zajímavým tématem – správou paměti. Předtím ale musím dokončit několik rozpracovaných, víc developersky zaměřených, článků.


1 Opět budu zcela náhodně používat termíny bluscreen, bugcheck, modrá smrt a zkratky BS a BSOD kterými myslím vždy to samé.
2 Správně bych měl mluvit o interrupt levelech, ale rozhodl jsem se zanevřít na technickou přesnost ve prospěch snadnější pochopitelnosti – přece jen je velká šance, že kdo zná IRQL, bude o jádře Windows vědět víc než já a můj článek mu nepomůže. 🙂
3 Zdaleka nejčastěji driver běžel na takzvaném dispatch interrupt levelu (můžeme podle Parameter 2 ověřit, že je to tak i v tomto případě) a snažil se sahat do paměti, která nebyla přítomna v RAM. Takovou situaci by normálně vyřešil memory manager, ovšem jeho vyvolání vyžaduje také dispatch interrupt (stejné IRQL), který se neobslouží dokud svou činnost driver neukončí, protože přerušení může přijít pouze z vyššího interrupt levelu.
4 Berte mě prosím s nadhledem 🙂 Ale rozhodně je pravda, že antiviry obecně jsou jedním z nejčastějších důvodů bluescreenů.
5 Ve WinDbg bychom zjistili, že v tomto případě šlo o csrsc.exe, což je Windows subsystem, zajišťující velkou část user mode WinAPI – prakticky každá aplikace na vašem stroji ho využívá pro svůj chod. (Tím nenápadně naznačuji, že tento blog nesmíte číst z Linuxu a MACu 🙂 )

Zanechat odpověď

Vyplňte detaily níže nebo klikněte na ikonu pro přihlášení:

Logo WordPress.com

Komentujete pomocí vašeho WordPress.com účtu. Odhlásit /  Změnit )

Google photo

Komentujete pomocí vašeho Google účtu. Odhlásit /  Změnit )

Twitter picture

Komentujete pomocí vašeho Twitter účtu. Odhlásit /  Změnit )

Facebook photo

Komentujete pomocí vašeho Facebook účtu. Odhlásit /  Změnit )

Připojování k %s