Kompletný sprievodca analýzou BSOD a výpisov jadra v systéme Windows

Informatec Digital » Zdroje » Kompletný sprievodca analýzou BSOD a výpisov jadra v systéme Windows

Keď počítač so systémom Windows zamrzne s modrou obrazovkou, nie je to len nepríjemné: vo výpise pamäte sa často skrývajú cenné informácie , ktoré nám presne hovoria, čo sa stalo v jadre. Namiesto obviňovania pamäte RAM, systému BIOS alebo okamžitého preformátovania sa oplatí naučiť sa tieto údaje čítať.

S trochou cviku nám nástroje ako WinDbg a funkcie ako !analyze -v, .bugcheck alebo správne používanie symbolov umožňujú prejsť od stavu „Zobrazuje sa mi modrá obrazovka“ k stavu „Viem, ktorý ovládač, prostriedok alebo zariadenie spôsobilo BSOD“. V tomto článku si krok za krokom a podrobne rozoberieme, ako analyzovať BSOD pomocou jeho výpisu jadra, aké typy výpisov existujú, ako všetko pripraviť a ktoré príkazy použiť na dosiahnutie čo najväčšieho efektu analýzy.

Čo je to BSOD a aké informácie obsahuje?

Keď systém Windows narazí na stav, ktorý ohrozuje integritu systému a nie je možné ho bezpečne obnoviť, vykoná interné volanie jadra s názvom KeBugCheckEx . Toto volanie spustí neslávne známu modrú obrazovku smrti (BSOD).

Funkcia KeBugCheckEx vždy prijíma päť argumentov: kód STOP (kód kontroly chyby) a štyri ďalšie parametre , ktoré poskytujú technický kontext chyby. Tieto isté údaje potom môžeme nahliadnuť.

• Na modrej obrazovke klasický, ak systém nie je nakonfigurovaný na automatický reštart.
• V denníku udalostí systému Windowsv prehliadači udalostí (systémový denník).
• V súbore s výpisom pamäte (minidump, dump jadra alebo úplný dump), pomocou WinDbg a príkazov ako !analyze -v o .bugcheck.

Každý kód kontroly chýb má symbolický názov a priradenú hexadecimálnu hodnotu . Napríklad kód kontroly chýb DRIVER_POWER_STATE_FAILURE má kód 0x9F , zatiaľ čo RESOURCE_NOT_OWNED zodpovedá kódu 0xE3 . Tieto kódy a ich parametre sú zdokumentované v referenčnej príručke kódov kontroly chýb od spoločnosti Microsoft, ktorú by ste mali mať vždy poruke.

Okrem kódu sa na modrej obrazovke môže zobraziť aj názov potenciálne zapojeného ovládača .sys . Ak ide o ovládač tretej strany (antivírus, sieťová karta, grafická karta atď.), často máme jasného podozrivého. Ak sa zobrazí všeobecná systémová súčasť (ntoskrnl.exe, win32k.sys atď.) alebo ak sa nezobrazí vôbec nič, budeme musieť vykonať výpis pamäte a na ďalšie preskúmanie použiť WinDbg.

Typy výpisov pamäte v systéme Windows

Na dôkladnú analýzu BSOD potrebujeme, aby systém Windows v prípade chyby vygeneroval súbor s výpisom pamäte (DMP) . Tento súbor zachytáva stav systému v čase chyby a môže byť rôznych typov.

V možnostiach „Spustenie a obnova“ (kliknite pravým tlačidlom myši na „Tento počítač / Tento počítač“ → Vlastnosti → Rozšírené nastavenia systému → karta „Rozšírené“ → tlačidlo „Nastavenia“ v časti „Spustenie a obnova“) si môžete vybrať z niekoľkých typov výpisov. Každý má svoje výhody a nevýhody.

Malý výpis pamäte (Minidump)

Formát minidumpu je najmenší (približne 64 KB) a tiež najobmedzenejší pre pokročilé ladenie. Napriek tomu zostáva užitočný na získanie rýchlej diagnózy v mnohých scenároch BSOD.

Minidump uchováva okrem iného tieto údaje:

• Správa o zastavení, kód kontroly chýb a jeho parametre.
• Kontext procesora (PRCB) procesora, ktorý spôsobil poruchu.
• Informácie o procese jadra (EPROSS) aktívneho procesu v čase havárie.
• Informácie o vláknach v jadre (ETHREAD) vlákna, ktoré spôsobilo zlyhanie.
• Zásobník volaní v režime jadra pre dané vlákno (do 16 KB).
• Zoznam načítaných ovládačov v čase vydania rozsudku.
• Zoznam načítaných a stiahnutých modulov.
• Blok ladiacich dát so základnými informáciami o systéme.

Tento typ výpisu sa zvyčajne ukladá do priečinka %SystemRoot%\Minidump (napríklad C:\Windows\Minidump ). Pre mnohé základné prípady podpory alebo diagnostiky môže byť viac než postačujúci minivýpis dôkladne analyzovaný pomocou !analyze -v.

Pamäťová výpis jadra

Výpis pamäte jadra obsahuje obsah pamäte jadra v čase zlyhania, okrem pamäťových priestorov procesov používateľa. Ponúka cennú rovnováhu medzi veľkosťou a detailmi a často je odporúčanou možnosťou na diagnostiku väčšiny BSOD.

Tento výpis sa uloží ako MEMORY.DMP do %SystemRoot% (štandardne C:\Windows\MEMORY.DMP ). Jeho veľkosť závisí od pamäte používanej jadrom, ale zvyčajne je oveľa väčší ako minivýpis a oveľa lepšie spravovateľný ako úplný výpis.

Kompletný výpis pamäte

Úplný výpis pamäte uloží prakticky všetok obsah pamäte RAM v čase chyby: jadro, používateľské procesy atď. Je najpodrobnejší, ale zároveň zaberá najviac miesta a je najnáročnejší na konfiguráciu.

Aby bol kompletný výpis platný, musí byť splnených niekoľko požiadaviek:

• El stránkovací súbor musí byť v rovnaký oddiel, kde je nainštalovaný systém Windows.
• Musí byť miesto na disku aspoň rovnaké ako veľkosť fyzickej pamäte stroja.
• Ak sa chcete vyhnúť poškodeným výpisom, nepresúvajte stránkovací súbor na iný fyzický disk.

V produkčných prostrediach s veľkým množstvom pamäte RAM môže byť úplný výpis nepraktický, ale vo veľmi zložitých alebo občasných prípadoch môže znamenať zásadný rozdiel pri lokalizácii problému.

Konfigurácia systému Windows na zachytávanie a protokolovanie BSOD

Predtým, ako sa pustíme do práce s WinDbg, je nevyhnutné zabezpečiť, aby systém správne generoval výpisy a zaznamenával udalosť modrej obrazovky.

V okne „Štart a obnova“ nájdeme niekoľko relevantných možností:

• Zapísať udalosť do systémového denníka: musí byť povolené, aby sa kontrola chýb zaznamenala v prehliadači udalostí.
• Zapísať ladiace informácie: tu vyberieme Minidump, Kernel Memory Dump alebo Complete Memory Dump.
• cesta k súboru s výpisom: predvolené % SystemRoot% \ MEMORY.DMP pre jadro/plnú verziu.
• Reštartujte automaticky: je vhodné zrušiť začiarknutie, ak chceme pokojne sledujte modrú obrazovku a všimnite si, čo sa objaví.

Niektorí výrobcovia alebo oddelenia podpory, napríklad v prípade určitých sieťových adaptérov, vyžadujú od používateľa odoslanie súboru s výpisom . Zvyčajne sa nachádza v priečinku C:\Windows\memory.dmp a odporúča sa ho vyhľadať podľa dátumu/času, aby sa identifikoval súbor zodpovedajúci poslednej chybe.

Ak chceme mať možnosť vynútiť výpis, aj keď je systém zamrznutý (bez reakcie klávesnice alebo myši), existuje tiež veľmi užitočný trik pre klávesnice PS/2 (nie USB/Bluetooth), ktorý spočíva v konfigurácii registra tak, aby spúšťal výpis kombináciou klávesov.

Vynútiť výpis pomocou klávesnice v prípade zamrznutia

Ak chcete vygenerovať výpis pamäte, aj keď je obrazovka úplne zamrznutá, môžete na klávesniciach PS/2 použiť možnosť CrashOnCtrlScroll . Táto metóda nie je platná pre klávesnice s rozhraním USB alebo Bluetooth.

V registri musíme vytvoriť alebo upraviť nasledujúci kľúč:

HKEY_LOCAL_MACHINE
  System
    CurrentControlSet
      Services
        i8042prt
          Parameters

Nombre: CrashOnCtrlScroll
Tipo:   REG_DWORD
Valor:  1

Po reštarte môžete kedykoľvek (aj keď je obrazovka zamrznutá) spustiť kontrolované zlyhanie a nechať systém vygenerovať výpis pamäte stlačením pravého klávesu CTRL a potom dvojitým stlačením klávesu Scroll Lock . Toto je veľmi užitočné pri vyšetrovaní závažných zlyhaní, ktoré samy o sebe nezobrazujú BSOD.

Úvod do WinDbg na analýzu výpisov jadra

WinDbg je popredný nástroj od spoločnosti Microsoft na ladenie jadra a analýzu výpisu pamäte . Je k dispozícii zadarmo (momentálne aj v obchode Microsoft Store ako WinDbg Preview) a hoci sa to na prvý pohľad môže zdať náročné, na úvodnú analýzu BSOD potrebujete poznať iba niekoľko základných možností.

WinDbg môžeme nainštalovať na samotný postihnutý počítač alebo na akýkoľvek iný počítač ; súbor .dmp je možné skopírovať cez sieť, cez USB alebo dokonca komprimovať do súboru CAB. Procesor a verzia systému Windows, kde analyzujeme výpis, sa nemusia nevyhnutne zhodovať s procesorom a verziou systému Windows, ktorý havaroval.

Spustenie WinDbg s výpisom z príkazového riadku

Klasický spôsob otvorenia výpisu pamäte vo WinDbg je použiť príkazový riadok s parametrom `-z` , ktorý určuje cestu k súboru s výpisom. Toto je možné kombinovať s inými parametrami, ako je napríklad symbol alebo binárna cesta.

windbg -y <RutaSimbolos> -i <RutaBinarios> -z <RutaDump>

Modifikátor -v aktivuje podrobný režim , ktorý je veľmi užitočný na zobrazenie väčšieho kontextu. Okrem WinDbg existuje aj kd.exe , konzolový debugger, ktorý umožňuje robiť prakticky to isté, ale bez grafického rozhrania.

kd.exe -z "Ruta\al\volcado.dmp" -y "Ruta\simbolos" -i "Ruta\busqueda\binarios"

Otvorenie výpisu z grafického rozhrania

Ak je WinDbg už otvorený v pasívnom režime, môžete načítať súbor s výpisom stavu havárie pomocou ponuky Súbor → Otvoriť výpis stavu havárie alebo klávesovou skratkou Ctrl+D . Vyberte súbor .dmp (alebo dokonca súbor .cab, ktorý ho obsahuje) a WinDbg načíta informácie o havárii.

Ďalšou alternatívou je spustiť WinDbg a po jeho otvorení spustiť príkaz .opendump s uvedením cesty k súboru s výpisom a potom príkazom g (Go) spustiť ladenie výpisu:

.opendump C:\Windows\Memory.dmp
g

WinDbg dokonca umožňuje vyčistiť viacero skládok narazpridanie niekoľkých parametrov -z na príkazovom riadku alebo opakovaním .opendump s rôznymi trasami a riadením relácie s viacerými cieľmi.

Konfigurácia cesty k symbolom vo WinDbg

Bez symbolov WinDbg pracuje takmer naslepo. Symboly (.pdb) obsahujú ladiace informácie o funkciách, vnútorných štruktúrach, premenných, posunoch atď . a sú nevyhnutné pre spoľahlivú analýzu, najmä pri práci s jadrom.

Ak chcete používať verejné symboly spoločnosti Microsoft bez nutnosti ich manuálneho sťahovania, najlepším postupom je nakonfigurovať server symbolov smerujúci na oficiálny server spoločnosti Microsoft a lokálny adresár vyrovnávacej pamäte. Napríklad môžeme najprv vytvoriť priečinok C:\symbols a potom vo WinDbg nakonfigurovať cestu k symbolom takto:

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

Toto je možné vykonať z ponuky Súbor → Cesta k súboru symbolov alebo v programe WinDbg Preview z ponuky Súbor → Nastavenia → Nastavenia ladenia úpravou možnosti „Predvolená cesta k symbolom“. Pri prvej analýze výpisu z konkrétneho systému ladiaci program automaticky stiahne potrebné symboly z internetu, čo môže v závislosti od vášho pripojenia trvať niekoľko minút.

Je dôležité poznamenať, že verejné symboly spoločnosti Microsoft niekedy neobsahujú všetky interné informácie o type a môžu sa zobraziť upozornenia typu „Váš ladiaci program nepoužíva správne symboly“ alebo odkazy na nerozpoznateľné typy. Na základnú analýzu BSOD zvyčajne postačujú verejné symboly, ale ak potrebujete viac podrobností, budú existovať obmedzenia.

Prvá analýza: základné príkazy a kontrola chýb

Po načítaní výpisu a konfigurácii symbolov WinDbg zvyčajne zobrazí hlavičku so systémovými informáciami a upozornením, napríklad „Použite !analyze -v na získanie podrobných informácií o ladení.“ To je naša prvá zastávka pre počiatočnú analýzu.

Príkaz !analyze -v vykoná automatickú analýzu výpisu a zvyčajne poskytne:

• Kód na kontrolu chýb (napríklad 0xE3, 0xD1, 0x9F, 0x44…).
• Parametre Arg1, Arg2, Arg3 a Arg4 z kontroly chýb.
• Najpravdepodobnejší modul alebo ovládač príčina zlyhania (Probably caused by).
• Súvisiaci proces v danom okamihu (napríklad Teams.exe).
• Zásobník volaní (trasovanie zásobníka) vlákna, ktoré spustilo haváriu.
• Informácie o vedre a hashy zlyhaní, užitočné na koreláciu opakovaných chýb.

Napríklad v reálnom prípade kontroly chýb RESOURCE_NOT_OWNED (0xE3) môže analýza naznačovať, že vlákno sa pokúsilo uvoľniť zdroj, ktorý nevlastní , pričom ako proces zobrazuje Teams.exe a vo funkcii ako DrvEnumDisplaySettings odkazuje na win32kbase.sys . To naznačuje, že zlyhávajúce vlákno dotazovalo alebo manipulovalo s nastaveniami zobrazenia z používateľského priestoru prostredníctvom grafickej vrstvy systému Windows.

Aby sme sa hlbšie ponorili do detailov stop kódu a jeho parametrov, máme aj príkaz .kontrola chýbčo opäť zobrazí kontrolu chýb a štyri argumenty, čo je užitočné, ak chceme tieto informácie zopakovať bez toho, aby sme všetko museli znova spúšťať. !analyze -v.

Praktické prípady: hnacie sily a typické konflikty

Analýza BSOD sa zvyčajne zameriava na identifikáciu chybných alebo nefunkčných ovládačov , konfliktov ovládačov, nesprávneho prístupu k pamäti, nesprávneho spracovania IRP (paketov I/O požiadaviek) atď. Pozrime sa na niekoľko praktických príkladov z reálneho sveta, aby sme lepšie pochopili tento proces.

RESOURCE_NOT_OWNED (0xE3) priradený k Teams a win32kbase.sys

V scenári systému Windows 10, kde sa po niekoľkých dňoch prevádzkyschopnosti zobrazí BSOD s chybou bugcheck 0xE3 (RESOURCE_NOT_OWNED) , výpis minikernelu zobrazuje niečo podobné ako:

RESOURCE_NOT_OWNED (e3)
A thread tried to release a resource it did not own.
Arguments:
Arg1: <dirección recurso>
Arg2: <dirección thread>
Arg3: 0
Arg4: 0

PROCESS_NAME: Teams.exe

STACK_TEXT:
...
win32kbase!DrvEnumDisplaySettings+0x356
win32kbase!NtUserEnumDisplaySettings+0x59
win32k!NtUserEnumDisplaySettings+0x15
nt!KiSystemServiceCopyEnd+0x28
...

Tu ladiaci program indikuje, že kontrola chýb je spustená vláknom spojeným s Teams.exe , ale kód, ktorý sa v kritickom momente skutočne nachádza na zásobníku, patrí win32kbase.sys , konkrétne funkcii DrvEnumDisplaySettings . To nemusí nevyhnutne znamenať, že Teams je priamym vinníkom, ale skôr to, že Teams volá používateľské API , ktoré vedie k chybe synchronizácie alebo uvoľnenia zdrojov v grafickom subsystéme.

Pri týchto typoch diagnóz sa často dospeje k záveru, že ide o chybu v grafickej karte systému Windows, v konkrétnom ovládači videa alebo v interakcii medzi aplikáciou a ovládačmi. Skutočné riešenie môže zahŕňať aktualizáciu ovládačov grafickej karty, aktualizáciu služby Teams alebo dokonca použitie konkrétnych záplat systému Windows , a nie len čakanie na samoopravu.

DRIVER_IRQL_NOT_LESS_OR_EQUAL (0xD1) s NotMyFault

Nástroj NotMyFault od spoločnosti Sysinternals je vzdelávací nástroj, ktorý vám umožňuje kontrolovaným spôsobom generovať chyby jadra a naučiť sa analyzovať snímky obrazovky. Napríklad, ak v nástroji NotMyFault spustíte možnosť chyby High IRQL (režim jadra) a kliknete na tlačidlo „Vykonať chybu“, vynútite si chybu DRIVER_IRQL_NOT_LESS_OR_EQUAL (0xD1).

Na modrej obrazovke uvidíme niečo ako DRIVER_IRQL_NOT_LESS_OR_EQUAL a prípadne aj ovládač (napríklad MyFault.sys , ovládač používaný nástrojom). Po vygenerovaní výpisu a jeho otvorení pomocou WinDbg môže počiatočný výstup vyzerať približne takto:

Use !analyze -v to get detailed debugging information.
BugCheck D1, {e1071800, 1c, 0, f7cda403}
*** ERROR: Module load completed but symbols could not be loaded for myfault.sys
Probably caused by : memory_corruption
Followup: memory_corruption

Hoci ladiaci program poukazuje na poškodenie pamäte , vieme, že skutočná príčina súvisí s NotMyFault a jeho ovládačom. Aby sme to potvrdili, môžeme pokračovať v sledovaní pomocou príkazov ako !thread , aby sme zistili, aké volania vlákno vykonáva v čase zlyhania, a !irp , aby sme analyzovali príslušný IRP, ak kontrola chýb súvisí s I/O operáciami.

Napríklad pomocou príkazu `!thread <adresár_vlákno>` môžeme vidieť stopu zásobníka vlákna a nájsť inštrukciu, kde sa nachádza `myfault+0x403` , čo naznačuje, kde sa testovací ovládač pokazil. Odtiaľ môžeme preskúmať IRP, stav pamäte atď., rovnako ako by sme to urobili v prípade skutočnej chyby.

Konflikty MULTIPLE_IRP_COMPLETE_REQUESTS (0x44) a USB

Ďalším veľmi ilustratívnym prípadom je kontrola chýb. VIACERÉ_DOKONČENÉ_ŽIADOSTI_OD_IRP (0x44)Táto chyba sa vyskytuje, keď IRP (I/O Request Packet) sa dokončí viackrát, zvyčajne preto, že dvaja rôzni vodiči si myslia, že vlastnia rovnaký IRP a obaja volajú IoCompleteRequest().

Analýza s !analyze -v by mohla priniesť popis podobný tomuto:

MULTIPLE_IRP_COMPLETE_REQUESTS (44)
A driver has requested that an IRP be completed (IoCompleteRequest()), but
the packet has already been completed.
...
Arguments:
Arg1: <IRP_ADDRESS>
Arg2: 00000d75
Arg3: 00000000
Arg4: 00000000

Probably caused by : usbehci.sys

Spočiatku sa zdá, že podozrivým je súbor usbehci.sys , ovládač od spoločnosti Microsoft pre ovládače USB EHCI. Je však relatívne zriedkavé, aby chybu skutočne spôsobil natívny ovládač systému Windows bez akejkoľvek interakcie tretej strany. Aby sme sa dostali k veci, použijeme adresu IRP poskytnutú kontrolou chyby (Arg1) a spustíme príkaz !irp <ADRESA_IRP> :

!irp 87e5a490
Irp is active with 3 stacks 3 is current (= 0x87e5a548)
...
> [ f, 0] 0 c0 8a055618 00000000 b69de300-00000000 Success Error
  \Driver\usbehci ax88172
Args: b70989c0 00000000 00220003 00000000

V poslednom riadku jasne vidíme reťazec \Driver\usbehci ax88172 , čo naznačuje, že IRP prešiel cez súbor usbehci.sys aj cez ovládač s názvom ax88172.sys , ktorý je priradený ku konkrétnemu sieťovému čipsetu USB (AX88172). Preto môžeme usúdiť, že konflikt pochádza z tohto ovládača sieťovej karty USB od tretej strany , nie z generického ovládača EHCI od spoločnosti Microsoft.

V takom prípade riešenie zahŕňa aktualizáciu ovládača adaptéra USB, výmenu zariadenia alebo, ak je to potrebné, jeho odstránenie . Tento typ analýzy IRP je obzvlášť užitočný pre BSOD súvisiace s USB, úložiskom, sieťovými kartami a vo všeobecnosti s akýmkoľvek komponentom, ktorý využíva intenzívne I/O operácie.

Užitočné príkazy WinDbg v režime jadra

Okrem !analyze -v a .bugcheck existuje niekoľko rozšírení a príkazov WinDbg, ktoré sú veľmi užitočné, keď sa chceme hlbšie ponoriť do výpisu jadra.

Medzi najbežnejšie patria:

• !vláknoZobrazuje podrobné informácie o vlákne vrátane jeho zásobníka volaní, stavu, priradených IRP atď. Umožňuje zobraziť „posledné akcie“ vlákna, ktoré bolo spustené v čase zlyhania systému.
• !proces 0 0Toto zobrazuje zoznam všetkých aktívnych procesov v čase havárie. Je to užitočné na identifikáciu, či na počítači neboli spustené nejaké podozrivé procesy, služby, EDR, antivírus atď.
• !irpanalyzuje konkrétny IRP a zobrazuje stopa vodičov, ktorými prešlaI/O príkaz, príznaky atď. sú kľúčové pri chybách súvisiacich s MULTIPLE_IRP_COMPLETE_REQUESTS a ďalšie chyby I/O.
• !cpuinfo: poskytuje informácie o procesore (výrobca, MHz, podpisy, charakteristiky), užitočné na overenie hardvérového prostredia.
• !peb: zobrazuje podrobnosti o PEB (Process Environment Block), ako napríklad názov počítača, inštalačnú cestu systému Windows, počet procesorov atď.
• !token: poskytuje informácie o bezpečnostných tokenoch, povoleniach a bezpečnostnom kontexte procesu alebo vlákna.
• .cls: vymaže príkazové okno, ako v bežnej konzole.

Okrem toho, mnohé špecifické prípony súborových systémov (napr. pre PnP, NTFS atď.) vám umožňujú extrahovať ešte viac informácií z výpisov. V niektorých prípadoch WinDbg indikuje prítomnosť BLACKBOX* (BLACKBOXBSD, BLACKBOXNTFS, BLACKBOXPNP, BLACKBOXWINLOGON), čo sú ďalšie dátové bloky zachytené počas kontroly chýb na uľahčenie diagnostiky špecifických oblastí systému.

Použitie overovača ovládačov na vyhľadanie problematických ovládačov

Veľmi vysoký podiel chýb typu modrá obrazovka smrti (BSOD) systému Windows je spôsobený chybnými alebo zle naprogramovanými ovládačmi . Na proaktívnu detekciu týchto typov problémov systém obsahuje výkonný nástroj: Overovač ovládačov.

Verifikátor ovládačov beží v reálnom čase a podrobuje vybrané ovládače sérii testov a záťažových testov: kontroluje správne využitie pamäte, využitie fondu jadra, IRQL, IRP atď. Ak zistí, že ovládač sa správa nesprávne, môže vynútiť kontrolovanú BSOD , aby sme mohli analyzovať oveľa prehľadnejší výpis, kde sa vinník zvyčajne ľahko identifikuje.

Ak chcete spustiť správcu overovača ovládačov, jednoducho otvorte príkazový riadok s oprávneniami správcu a zadajte:

verifier

Odtiaľ si môžeme vybrať, ktoré ovládače chceme overiť. Je rozumné byť opatrný: Verifikátor pridáva systémovej záťaži a môže znížiť výkon , preto sa odporúča povoliť overovanie iba pre čo najmenej podozrivých ovládačov, namiesto bez rozdielu vyberať všetko.

Keď nástroj Verifier spustí BSOD po zistení nesprávneho správania, môžeme analyzovať výpis jadra pomocou WinDbg a dúfajme, že jasne vidíme, ktorý ovládač bol zachytený a čo urobil zle. Referenčné články spoločnosti Microsoft o nástroji Driver Verifier podrobne vysvetľujú rôzne možnosti a stratégie používania.

Praktické rady pre inžinierov a technikov

Či už ste vývojár ovládačov, vývojár softvéru, ktorý interaguje s jadrom, alebo jednoducho technik, ktorému sa zobrazujú všetky modré obrazovky smrti, existuje niekoľko pokynov, ktoré sa oplatí osvojiť si, aby ste sa nestratili v džungli modrých obrazoviek smrti.

Prvým krokom, keď chyba súvisí s vaším vlastným kódom, je systematické použitie ladiacej aplikácie jadra na reprodukciu a analýzu problému . Pripojením ladiacej aplikácie k cieľovému počítaču (prostredníctvom siete, sériového rozhrania atď.) kontrola chýb spôsobí, že systém sa zastaví v ladiacej aplikácii namiesto priameho zobrazenia modrej obrazovky. Odtiaľ môžete skontrolovať pamäť, zásobníky, štruktúry a opraviť kód.

V iných scenároch môžu byť kontroly chýb spôsobené ovládačmi, hardvérom alebo softvérom tretích strán , ktoré nekontrolujeme. V takýchto prípadoch sa cieľ presúva z „opravy kódu“ na izoláciu a zmiernenie problému.

• Identifikujte podozrivý ovládač alebo hardvérový komponent pomocou nástroja WinDbg a analýzy výpisu.
• Aktualizovať alebo vrátiť späť verzie ovládačov, BIOS, firmvér alebo súvisiace aplikácie.
• Odstrániť alebo vymeniť USB zariadenia, grafické karty, sieťové adaptéry konfliktné.
• Oprieť sa o Prehliadač udalostí, Sysinternals, nástroje na monitorovanie a analýzu siete pre ďalší kontext.

Mnohé zdanlivo záhadné problémy sa dajú vyriešiť základnými postupmi riešenia problémov : prehľadom dokumentácie, kontrolou verzií a dátumov súborov, preinštalovaním kľúčových komponentov alebo vypnutím konfliktných modulov. Analýza výpisu nám dáva jasný smer, kde hľadať, a často nám ušetrí hodiny pokusov a omylov.

Je tiež dôležité pamätať na to, že v prostrediach, ako je to, ktoré spôsobilo incident CrowdStrike Falcon a ďalšie EDR, sa najčastejšie otázky točia okolo toho, čo spustilo BSOD a ako ho rýchlo identifikovať . Správne nakonfigurovaný WinDbg so symbolmi a jasným postupom na otváranie a analýzu výpisov vám umožňuje v priebehu niekoľkých minút zúžiť okruh problémov, ktoré by inak mohli skončiť s chybou „naformátovať a preinštalovať“ bez skutočného pochopenia príčiny.

Stručne povedané, kombinácia dobrej konfigurácie výpisu pamäte, disciplinovaného používania nástrojov ako WinDbg, Driver Verifier a Sysinternals a zvyku metodického prezerania protokolov a zásobníkov premieňa modré obrazovky nepredvídateľného nepriateľa na veľmi presný zdroj informácií o tom, čo v jadre zlyhalo , čo nám pomáha robiť oveľa informovanejšie technické rozhodnutia.