Kompletan vodič za analizu BSOD-ova i kernel dumpova u Windowsu

Informatec Digital » Resursi » Kompletan vodič za analizu BSOD-ova i kernel dumpova u Windowsu

Kada se Windows računar zamrzne s plavim ekranom, to nije samo dosadno: u memoriji se često kriju vrijedne informacije koje nam govore šta se tačno dogodilo u kernelu. Umjesto da krivimo RAM, BIOS ili odmah ponovo formatiramo, vrijedi naučiti kako čitati te podatke.

Uz malo vježbe, alati poput WinDbg-a i funkcije poput !analyze -v, .bugcheck ili ispravna upotreba simbola omogućavaju nam da pređemo sa "Dobijam grešku plavog ekrana" na "Znam koji je drajver, resurs ili uređaj uzrokovao BSOD". U ovom članku ćemo korak po korak i detaljno objasniti kako analizirati BSOD koristeći njegov kernel dump, koje vrste dumpova postoje, kako sve pripremiti i koje naredbe koristiti da biste izvukli maksimum iz analize.

Šta je BSOD i koje informacije sadrži?

Kada Windows naiđe na stanje koje ugrožava integritet sistema i ne može se sigurno oporaviti, on upućuje interni poziv kernelu pod nazivom KeBugCheckEx . Ovaj poziv pokreće zloglasni Plavi ekran smrti (BSOD).

KeBugCheckEx uvijek prima pet argumenata: STOP kod (kod za provjeru grešaka) i četiri dodatna parametra koji pružaju tehnički kontekst greške. Upravo te iste podatke možemo zatim konsultovati.

• Na plavom ekranu klasičan, ako sistem nije konfigurisan za automatsko ponovno pokretanje.
• U zapisniku događaja sistema Windows, unutar Preglednika događaja (sistemski dnevnik).
• U datoteci sa stanjem memorije (minidump, kernel dump ili full dump), koristeći WinDbg i naredbe poput !analyze -v o .bugcheck.

Svaki kod za provjeru grešaka ima simbolično ime i pridruženu heksadecimalnu vrijednost . Na primjer, kod za provjeru grešaka DRIVER_POWER_STATE_FAILURE ima kod 0x9F , dok RESOURCE_NOT_OWNED odgovara 0xE3 . Ovi kodovi i njihovi parametri dokumentirani su u Microsoftovoj referenci koda za provjeru grešaka, koju biste uvijek trebali imati pri ruci.

Pored koda, plavi ekran može prikazati naziv potencijalno uključenog .sys drajvera . Ako se radi o drajveru treće strane (antivirus, mrežna kartica, grafička kartica itd.), često imamo jasnog sumnjivca. Ako se pojavi generička sistemska komponenta (ntoskrnl.exe, win32k.sys itd.) ili ako se uopće ništa ne pojavi, morat ćemo izvršiti analizu memorije i koristiti WinDbg za daljnju istragu.

Vrste memorijskih dumpsova u Windowsu

Da bismo detaljno analizirali BSOD, potrebno je da Windows generira datoteku s podacima o stanju memorije (DMP) kada dođe do greške. Ova datoteka bilježi stanje sistema u trenutku greške i može biti različitih tipova.

U opcijama "Pokretanje i oporavak" (desni klik na "Ovaj računar / Moj računar" → Svojstva → Napredne postavke sistema → kartica "Napredno" → dugme "Postavke" pod "Pokretanje i oporavak"), možete birati između nekoliko vrsta dumpa. Svaki ima svoje prednosti i nedostatke.

Mali memorijski dump (Minidump)

Format minidumpa je najmanji (oko 64 KB) i ujedno najograničeniji za napredno otklanjanje grešaka. Međutim, ostaje koristan za brzu dijagnozu u mnogim BSOD scenarijima.

Minidump, između ostalih podataka, pohranjuje:

• Poruka zaustavljanja, kod za provjeru grešaka i njegovi parametri.
• Kontekst procesora (PRCB) procesora koji je uzrokovao kvar.
• Informacije o procesu jezgra (EPROSS) aktivnog procesa u trenutku pada sistema.
• Informacije o nitima u kernelu (ETHREAD) niti koja je uzrokovala pad sistema.
• Stek poziva u kernel modu za tu temu (do 16 KB).
• Lista učitanih drajvera u vrijeme donošenja presude.
• Lista učitanih i preuzetih modula.
• Blok podataka za otklanjanje grešaka sa osnovnim sistemskim informacijama.

Ova vrsta dumpa se obično sprema u %SystemRoot%\Minidump (na primjer, C:\Windows\Minidump ). Za mnoge osnovne slučajeve podrške ili dijagnostike, minidump temeljno analiziran pomoću !analyze -v može biti više nego dovoljan.

Kernel Memory Dump

Izvještaj o memoriji kernela sadrži sadržaj memorije kernela u trenutku pada sistema, isključujući memorijske prostore korisničkih procesa. Nudi vrijednu ravnotežu između veličine i detalja i često je preporučena opcija za dijagnosticiranje većine BSOD-ova.

Ovaj dump se čuva kao MEMORY.DMP u %SystemRoot% (podrazumevano, C:\Windows\MEMORY.DMP ). Njegova veličina zavisi od memorije koju koristi kernel, ali je obično mnogo veći od minidumpa i mnogo lakši za upravljanje od punog dumpa.

Kompletna memorija

Potpuni memorijski dump sprema gotovo sav sadržaj RAM-a u trenutku greške: kernel, korisničke procese itd. To je najdetaljniji, ali i onaj koji zauzima najviše prostora i najzahtjevniji je u smislu konfiguracije.

Da bi potpuni dump bio validan, mora biti ispunjeno nekoliko uslova:

• El datoteka stranične stranice mora biti u ista particija na kojoj je instaliran Windows.
• Mora biti prostor na disku barem jednak veličini fizičke memorije mašine.
• Nemojte premještati datoteku stranice na drugi fizički disk ako želite izbjeći oštećene dump datoteke.

U produkcijskim okruženjima s puno RAM-a, potpuni dump može biti nepraktičan, ali za vrlo složene ili povremene slučajeve može napraviti veliku razliku u lociranju problema.

Konfigurišite Windows da snima i evidentira BSOD-ove

Prije nego što se bacimo na posao s WinDbg-om, bitno je osigurati da sistem ispravno generira dumpove i bilježi događaj plavog ekrana.

U prozoru "Pokretanje i oporavak" nalazimo nekoliko relevantnih opcija:

• Zapišite događaj u sistemski dnevnik: mora biti omogućeno da bi se provjera grešaka snimila u Pregledniku događaja.
• Zapisivanje informacija o otklanjanju grešaka: ovdje biramo Minidump, Kernel memory dump ili Complete memory dump.
• putanja datoteke za ispis: zadano %SystemRoot%\MEMORY.DMP za kernel/punu verziju.
• Automatski se ponovo pokrenipreporučljivo je da to poništimo ako želimo mirno gledajte plavi ekran i obratite pažnju na ono što se pojavljuje.

Kod nekih proizvođača ili odjela za podršku, kao što je slučaj s određenim mrežnim adapterima, od korisnika se traži da dostavi datoteku s podacima . Obično se nalazi u C:\Windows\memory.dmp , a preporučuje se lociranje po datumu/vremenu kako bi se identificirao onaj koji odgovara posljednjem kvaru.

Ako želimo moći prisilno pokrenuti dump čak i kada je sistem zamrznut (bez reagiranja tastature ili miša), postoji i vrlo koristan trik za PS/2 tastature (ne USB/Bluetooth), koji se sastoji od konfiguriranja registra da pokrene dump kombinacijom tipki.

Prisilno kreiranje dumpa pomoću tastature u slučaju zamrzavanja

Da biste generirali memoriju čak i ako je ekran potpuno zamrznut, možete koristiti opciju CrashOnCtrlScroll na PS/2 tastaturama. Ova metoda ne vrijedi za USB ili Bluetooth tastature.

U registru moramo kreirati ili izmijeniti sljedeći ključ:

HKEY_LOCAL_MACHINE
  System
    CurrentControlSet
      Services
        i8042prt
          Parameters

Nombre: CrashOnCtrlScroll
Tipo:   REG_DWORD
Valor:  1

Nakon ponovnog pokretanja, u bilo kojem trenutku (čak i sa zamrznutim ekranom) možete pokrenuti kontrolirani pad sistema i natjerati sistem da generira memoriju pritiskom na desnu tipku CTRL , a zatim dva puta tipku Scroll Lock . Ovo je vrlo korisno za istraživanje ozbiljnih padova sistema koji sami po sebi ne prikazuju BSOD.

Uvod u WinDbg za analizu kernel dumpova

WinDbg je Microsoftov vodeći alat za otklanjanje grešaka u kernelu i analizu memorijskog dumpa . Dostupan je besplatno (trenutno i u Microsoft prodavnici kao WinDbg Preview) i, iako se na prvi pogled može činiti zastrašujućim, za početnu analizu BSOD-a potrebno je razumjeti samo nekoliko osnovnih opcija.

WinDbg možemo instalirati na sam pogođeni računar ili na bilo koji drugi računar ; .dmp datoteka se može kopirati preko mreže, putem USB-a ili čak komprimirati u CAB datoteku. Procesor i verzija Windowsa na kojoj analiziramo damp ne moraju nužno odgovarati onima na računaru koji se srušio.

Pokrenite WinDbg sa dump-om iz komandne linije

Klasičan način otvaranja datoteke s podacima o memoriji u WinDbg-u je korištenje komandne linije s parametrom `-z` , kojim se određuje putanja do datoteke s podacima o memoriji. Ovo se može kombinirati s drugim parametrima kao što su putanja simbola ili binarne datoteke.

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

Modifikator -v aktivira verbose mod , što je vrlo korisno za pregled više konteksta. Pored WinDbg-a, postoji i kd.exe , konzolni debugger koji vam omogućava da uradite praktično istu stvar, ali bez grafičkog interfejsa.

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

Otvorite dump iz grafičkog interfejsa

Ako je WinDbg već otvoren u pasivnom režimu, možete učitati datoteku sa informacijama o padu sistema koristeći meni Datoteka → Otvori pad sistema ili prečicu Ctrl+D . Izaberite .dmp datoteku (ili čak .cab datoteku koja je sadrži) i WinDbg će učitati informacije o padu sistema.

Druga alternativa je pokretanje WinDbg-a, i kada ste unutra, pokrenite naredbu .opendump navodeći putanju do datoteke s dump datotekama, a zatim naredbu g (Go) za pokretanje sesije otklanjanja grešaka u dump datotekama:

.opendump C:\Windows\Memory.dmp
g

WinDbg čak dozvoljava čišćenje više deponija odjednomdodavanje nekoliko parametara -z na komandnoj liniji ili ponavljanjem .opendump s različitim rutama i upravljanjem sesijom s više odredišta.

Konfigurišite putanju simbola u WinDbg-u

Bez simbola, WinDbg radi gotovo naslijepo. Simboli (.pdb) sadrže informacije o otklanjanju grešaka u funkcijama, internim strukturama, varijablama, pomacima itd . i neophodni su za pouzdanu analizu, posebno pri radu s kernelom.

Da biste koristili Microsoftove javne simbole bez potrebe za njihovim ručnim preuzimanjem, najbolja praksa je konfigurirati server simbola koji upućuje na službeni Microsoftov server i lokalni direktorij predmemorije. Na primjer, prvo možemo kreirati mapu C:\symbols , a zatim u WinDbg-u konfigurirati putanju simbola na sljedeći način:

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

To se može uraditi iz menija Datoteka → Putanja do datoteke simbola ili, u WinDbg Pregledu, iz Datoteka → Postavke → Postavke otklanjanja grešaka podešavanjem "Zadane putanje simbola". Prvi put kada analizirate damp sa određenog sistema, program za otklanjanje grešaka će automatski preuzeti potrebne simbole sa interneta, što može potrajati nekoliko minuta, ovisno o vašoj vezi.

Važno je napomenuti da Microsoftovi javni simboli ponekad ne uključuju sve interne informacije o tipu i da možete vidjeti upozorenja poput "Vaš program za otklanjanje grešaka ne koristi ispravne simbole" ili reference na nerazrješive tipove. Za osnovnu analizu BSOD-a, javni simboli su obično dovoljni, ali ako vam je potrebno više detalja, postojat će ograničenja.

Prva analiza: osnovne komande i provjera grešaka

Nakon što se damp učita i simboli konfigurišu, WinDbg obično prikazuje zaglavlje sa sistemskim informacijama i upozorenjem kao što je "Koristite !analyze -v da biste dobili detaljne informacije o otklanjanju grešaka." To je naša prva stanica za početnu analizu.

Naredba !analyze -v vrši automatsku analizu dumpa i obično pruža:

• Kod za provjeru grešaka (na primjer, 0xE3, 0xD1, 0x9F, 0x44…).
• Parametri Arg1, Arg2, Arg3 i Arg4 iz provjere grešaka.
• Najvjerovatniji modul ili upravljački program uzrok kvara (Probably caused by).
• Povezani proces u tom trenutku (na primjer, Teams.exe).
• Stack poziva (trag stacka) niti koja je izazvala pad sistema.
• Informacije o kanti i hešovi grešaka, korisni za korelaciju ponovljenih grešaka.

Na primjer, u slučaju provjere grešaka iz stvarnog svijeta RESOURCE_NOT_OWNED (0xE3) , analiza bi mogla ukazivati ​​na to da je nit pokušala osloboditi resurs koji ne posjeduje , prikazujući Teams.exe kao proces i pokazujući na win32kbase.sys u funkciji kao što je DrvEnumDisplaySettings . Ovo sugerira da je nit koja nije uspjela ispitivala ili manipulirala postavkama prikaza iz korisničkog prostora putem grafičkog sloja Windowsa.

Da bismo malo dublje zašli u detalje stop koda i njegovih parametara, imamo i naredbu .bugcheckšto ponovo prikazuje provjeru grešaka i četiri argumenta, što je korisno ako želimo ponoviti te informacije bez ponovnog pokretanja svega. !analyze -v.

Praktični slučajevi: pokretači i tipični konflikti

Analiza BSOD-a se obično vrti oko identifikacije neispravnih ili nepravilno funkcionišućih drajvera , konflikata drajvera, nepravilnog pristupa memoriji, nepravilnog rukovanja IRP-ovima (I/O Request Packets) i tako dalje. Pogledajmo neke praktične primjere iz stvarnog svijeta kako bismo bolje razumjeli proces.

RESOURCE_NOT_OWNED (0xE3) povezano s Teamsima i win32kbase.sys

U scenariju Windowsa 10 gdje se, nakon nekoliko dana rada, pojavi BSOD sa greškom provjere grešaka 0xE3 (RESOURCE_NOT_OWNED) , minikernel dump prikazuje nešto slično:

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
...

Ovdje, debugger pokazuje da je provjera grešaka pokrenuta niti povezanom sa Teams.exe , ali kod koji se zapravo nalazi na steku u kritičnom trenutku pripada win32kbase.sys , tačnije funkciji DrvEnumDisplaySettings . To ne znači nužno da je Teams direktni krivac, već da Teams poziva korisnički API koji rezultira greškom u sinhronizaciji ili oslobađanju resursa u grafičkom podsistemu.

U ovakvim vrstama dijagnoza, zaključak je često da se radi o grešci u Windows grafičkom steku, određenom video drajveru ili interakciji između aplikacije i drajvera. Stvarno rješenje može uključivati ​​ažuriranje GPU drajvera, ažuriranje Teamsa ili čak primjenu određenih Windows zakrpa , umjesto jednostavnog čekanja da se problem sam popravi.

DRIVER_IRQL_NOT_LESS_OR_EQUAL (0xD1) sa NotMyFault

Sysinternalsov uslužni program NotMyFault je edukativni alat koji vam omogućava da generirate greške kernela na kontroliran način kako biste naučili analizirati snimke ekrana. Na primjer, ako pokrenete opciju High IRQL fault (kernel mode) iz NotMyFault-a i kliknete na "Do Bug", prisilit ćete grešku DRIVER_IRQL_NOT_LESS_OR_EQUAL (0xD1).

Na plavom ekranu ćemo vidjeti nešto poput DRIVER_IRQL_NOT_LESS_OR_EQUAL i moguće kandidat za upravljački program (na primjer, MyFault.sys , upravljački program koji koristi alat). Nakon što se generira ispis i otvori pomoću WinDbg-a, početni izlaz može izgledati ovako:

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

Iako debugger ukazuje na oštećenje memorije , znamo da je pravi uzrok povezan s NotMyFault i njegovim drajverom. Da bismo to potvrdili, možemo nastaviti praćenje pomoću naredbi poput !thread da bismo vidjeli koje pozive nit upućuje u trenutku kvara i !irp da bismo analizirali uključeni IRP ako je provjera grešaka povezana s I/O operacijama.

Na primjer, sa `!thread <dir_thread>` možemo vidjeti trag steka niti i locirati instrukciju gdje se pojavljuje `myfault+0x403` , što ukazuje na to gdje je testni drajver pogriješio. Odatle možemo ispitati IRP, status memorije i tako dalje, baš kao što bismo to učinili sa pravom greškom.

MULTIPLE_IRP_COMPLETE_REQUESTS (0x44) i USB konflikti

Još jedan vrlo ilustrativan slučaj je provjera grešaka. VIŠE_ZAHTJEVA_ZA_VRŠENJE_IRP-a (0x44)Ova greška se javlja kada IRP (I/O Request Packet) je završen više puta, obično zato što dva različita vozača vjeruju da posjeduju isti IRP i oba pozivaju IoCompleteRequest().

Analiza sa !analyze -v mogla bi dati opis sličan ovome:

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

U početku se čini da je sumnjivi usbehci.sys , Microsoftov drajver za USB EHCI kontrolere. Međutim, relativno je rijetko da grešku zapravo uzrokuje izvorni Windows drajver bez ikakve interakcije treće strane. Da bismo došli do poente, koristimo IRP adresu koju je dao bugcheck (Arg1) i pokrećemo !irp <IRP_ADRESA> :

!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

U posljednjem redu jasno vidimo niz \Driver\usbehci ax88172 , što otkriva da je IRP prošao i kroz usbehci.sys i kroz drajver pod nazivom ax88172.sys , povezan sa specifičnim USB mrežnim čipsetom (AX88172). Stoga možemo zaključiti da konflikt potiče od ovog USB NIC drajvera treće strane , a ne od Microsoftovog generičkog EHCI drajvera.

U tom slučaju, rješenje uključuje ažuriranje upravljačkog programa USB adaptera, zamjenu uređaja ili, ako je potrebno, njegovo uklanjanje . Ova vrsta IRP analize je posebno korisna za BSOD-ove povezane s USB-om, pohranom, mrežnim karticama i, općenito, bilo kojom komponentom koja koristi intenzivan I/O.

Korisne WinDbg komande u kernel modu

Pored !analyze -v i .bugcheck , postoji nekoliko WinDbg ekstenzija i naredbi koje su vrlo korisne kada želimo malo dublje istražiti proces kernel dumpinga.

Neki od najčešćih su:

• !nit: Prikazuje detaljne informacije o niti, uključujući njen stek poziva, stanje, povezane IRP-ove itd. Omogućava vam da vidite "posljednje radnje" niti koja je bila pokrenuta kada se sistem srušio.
• !proces 0 0Ovo navodi sve aktivne procese u trenutku pada sistema. Korisno je za identifikaciju da li su na računaru bili pokrenuti sumnjivi procesi, servisi, EDR, antivirus itd.
• !irp: analizira određeni IRP i prikazuje trag vozača kroz koje je prošaoU/I komanda, zastavice itd. su ključne kod grešaka povezanih sa MULTIPLE_IRP_COMPLETE_REQUESTS i druge I/O greške.
• !cpuinfo: pruža informacije o procesoru (proizvođač, MHz, potpisi, karakteristike), korisno za provjeru hardverskih okruženja.
• !peb: prikazuje detalje PEB-a (Process Environment Block), kao što su naziv računara, putanja instalacije Windowsa, broj procesora itd.
• !token: pruža informacije o sigurnosnim tokenima, dozvolama i sigurnosnom kontekstu procesa ili niti.
• .cls: briše prozor komandne komande, kao u običnoj konzoli.

Osim toga, mnoge specifične ekstenzije datotečnih sistema (npr. za PnP, NTFS, itd.) omogućavaju vam da izvučete još više informacija iz datoteka. U nekim slučajevima, WinDbg će ukazati na prisustvo BLACKBOX* (BLACKBOXBSD, BLACKBOXNTFS, BLACKBOXPNP, BLACKBOXWINLOGON), koji su dodatni blokovi podataka snimljeni tokom provjere grešaka kako bi se olakšala dijagnoza specifičnih područja sistema.

Korištenje programa Driver Verifier za pronalaženje problematičnih upravljačkih programa

Vrlo visok udio grešaka plavog ekrana smrti (BSOD) u sistemu Windows uzrokovan je neispravnim ili loše programiranim upravljačkim programima . Za proaktivno otkrivanje ovih vrsta problema, sistem uključuje moćan alat: Verifikator upravljačkih programa.

Alat za provjeru upravljačkih programa (Driver Verifier) ​​radi u stvarnom vremenu i podvrgava odabrane upravljačke programe nizu testova i testova opterećenja: provjerava ispravnu upotrebu memorije, korištenje kernel poola, IRQL, IRP itd. Ako otkrije da se upravljački program ne ponaša ispravno, može izazvati kontrolirani BSOD kako bismo mogli analizirati mnogo jasniji ispis podataka, gdje se krivac obično lako identificira.

Da biste pokrenuli upravitelja verifikacije upravljačkih programa, jednostavno otvorite komandni redak s administratorskim privilegijama i upišite:

verifier

Odatle možemo odabrati koje drajvere želimo provjeriti. Pametno je biti oprezan: Verifikator dodaje opterećenje sistemu i može smanjiti performanse , pa se preporučuje omogućiti provjeru samo za najmanji mogući broj sumnjivih drajvera umjesto da se nasumično odabire sve.

Nakon što Verifier pokrene BSOD nakon otkrivanja neispravnog ponašanja, možemo analizirati kernel damp pomoću WinDbg-a i, nadamo se, jasno vidjeti koji je drajver uhvaćen i šta je uradio pogrešno. Microsoftovi referentni članci o Driver Verifier-u detaljno objašnjavaju različite opcije i strategije korištenja.

Praktični savjeti za inženjere i tehničare

Bez obzira da li ste programer drajvera, programer softvera koji komunicira s kernelom ili jednostavno tehničar kojem se uvijek javljaju plavi ekrani smrti, postoje neke smjernice koje vrijedi usvojiti kako biste izbjegli da se izgubite u džungli BSOD-ova.

Prvi korak, kada je greška povezana s vašim vlastitim kodom, jeste sistematsko korištenje debuggera kernela za reprodukciju i analizu problema . Povezivanjem debuggera na ciljni računar (putem mreže, serijskog porta itd.), provjera grešaka će uzrokovati zaustavljanje sistema unutar debuggera umjesto direktnog prikazivanja plavog ekrana. Odatle možete pregledati memoriju, stekove, strukture i ispraviti kod.

U drugim scenarijima, provjere grešaka mogu biti uzrokovane drajverima, hardverom ili softverom trećih strana koje ne kontrolišemo. U tim slučajevima, cilj se prebacuje sa "popravljanja koda" na izolovanje i ublažavanje problema.

• Identifikujte sumnjivi drajver ili hardversku komponentu pomoću WinDbg-a i analize dump-a.
• Ažuriranje ili vraćanje na prethodno stanje verzije upravljačkih programa, BIOS-a, firmvera ili srodnih aplikacija.
• Uklonite ili zamijenite USB uređaji, grafičke kartice, mrežni adapteri konfliktan.
• Oslanjati se na Preglednik događaja, Sysinternals, alati za praćenje i analizu mreže za dodatni kontekst.

Mnogi naizgled misteriozni problemi rješavaju se osnovnim postupcima rješavanja problema : pregledom dokumentacije, provjerom verzija i datuma datoteka, ponovnom instalacijom ključnih komponenti ili onemogućavanjem konfliktnih modula. Analiziranje datoteke ispisa nam daje jasan smjer gdje tražiti i često nam štedi sate pokušaja i grešaka.

Također je važno zapamtiti da se u okruženjima poput onog koje je uzrokovalo incident CrowdStrike Falcon i druge EDR-ove, najčešća pitanja vrte oko toga šta je izazvalo BSOD i kako ga brzo identificirati . Pravilno konfiguriranje WinDbg-a, sa simbolima i jasnom procedurom za otvaranje i analizu dumpova, omogućava vam da u nekoliko minuta suzite izbor onoga što bi inače moglo završiti "formatiranjem i ponovnom instalacijom" bez istinskog razumijevanja uzroka.

Ukratko, kombinovanje dobre konfiguracije memorijskog dumpa, disciplinovane upotrebe alata poput WinDbg-a, Driver Verifier-a i Sysinternals-a, te navike metodičnog pregleda logova i stekova, pretvara plave ekrane nepredvidivog neprijatelja u vrlo tačan izvor informacija o tome šta je zakazalo u kernelu , pomažući nam da donosimo mnogo informisanije tehničke odluke.