Udhëzues i plotë për analizimin e BSOD-ve dhe kernel dump-eve në Windows

Informatec Digital » Burime » Udhëzues i plotë për analizimin e BSOD-ve dhe kernel dump-eve në Windows

Kur një kompjuter me Windows ngrin me një ekran blu, kjo nuk është vetëm bezdisëse: shpesh ka informacione të vlefshme të fshehura në deponin e memories që na tregojnë saktësisht se çfarë ka ndodhur në kernel. Në vend që të fajësoni RAM-in, BIOS-in ose të riformatoni menjëherë, ia vlen të mësoni se si t'i lexoni ato të dhëna.

Me pak praktikë, mjete si WinDbg dhe funksione si !analyze -v, .bugcheck, ose përdorimi i saktë i simboleve na lejojnë të kalojmë nga "Kam një gabim në ekran blu" në "E di se cili drajver, burim ose pajisje shkaktoi BSOD-në". Në këtë artikull, do të analizojmë, hap pas hapi dhe me hollësi të konsiderueshme, se si të analizojmë një BSOD duke përdorur bërthamën e tij, çfarë llojesh bërthamash ekzistojnë, si të përgatisim gjithçka dhe cilat komanda të përdorim për të përfituar sa më shumë nga analiza.

Çfarë është një BSOD dhe çfarë informacioni përmban?

Kur Windows has një kusht që kompromenton integritetin e sistemit dhe nuk mund të rikuperohet në mënyrë të sigurt, ai bën një thirrje të brendshme të kernelit të quajtur KeBugCheckEx . Kjo thirrje është ajo që shkakton ekranin famëkeq Blu të Vdekjes (BSOD).

KeBugCheckEx merr gjithmonë pesë argumente: një kod STOP (kod kontrolli të gabimeve) dhe katër parametra shtesë që i japin kontekst teknik gabimit. Të njëjtat të dhëna janë ato që mund të konsultojmë më pas.

• Në ekranin blu klasik, nëse sistemi nuk është konfiguruar të rifillojë automatikisht.
• Në regjistrin e ngjarjeve të Windows, brenda Shikuesit të Ngjarjeve (regjistri i sistemit).
• Në skedarin e deponimit të memories (minidump, kernel dump ose full dump), duke përdorur WinDbg dhe komanda si !analyze -v o .bugcheck.

Çdo kod kontrolli defektesh ka një emër simbolik dhe një vlerë heksadecimale të shoqëruar . Për shembull, kontrolli i defekteve DRIVER_POWER_STATE_FAILURE ka kodin 0x9F , ndërsa RESOURCE_NOT_OWNED korrespondon me 0xE3 . Këto kode dhe parametrat e tyre janë të dokumentuar në referencën e kodit të kontrollit të defekteve të Microsoft, të cilën duhet ta mbani gjithmonë afër.

Përveç kodit, ekrani blu mund të shfaqë emrin e një drajveri .sys që mund të jetë i përfshirë . Nëse është një drajver i palës së tretë (antivirus, kartë rrjeti, kartë grafike, etj.), shpesh kemi një të dyshuar të qartë. Nëse shfaqet një komponent i përgjithshëm i sistemit (ntoskrnl.exe, win32k.sys, etj.), ose nëse nuk shfaqet asgjë, do të na duhet të kryejmë një pastrim të memorjes dhe të përdorim WinDbg për të hetuar më tej.

Llojet e deponive të memories në Windows

Për të analizuar një BSOD në thellësi, na duhet që Windows të gjenerojë një skedar memory dump (DMP) kur ndodh dështimi. Ky skedar kap gjendjen e sistemit në kohën e gabimit dhe mund të jetë i llojeve të ndryshme.

Në opsionet "Nisja dhe Rimëkëmbja" (klikoni me të djathtën mbi "Ky PC / Kompjuteri Im" → Vetitë → Cilësimet e avancuara të sistemit → skeda "Të avancuara" → butoni "Cilësimet" nën "Nisja dhe Rimëkëmbja"), mund të zgjidhni midis disa llojeve të skedarëve dump. Secili ka avantazhet dhe disavantazhet e veta.

Dump i Vogël i Memories (Minidump)

Formati minidump është më i vogli (rreth 64 KB) dhe gjithashtu më i kufizuari për debugging të avancuar. Megjithatë, ai mbetet i dobishëm për të marrë një diagnozë të shpejtë në shumë skenarë BSOD.

Një minidump ruan, ndër të dhëna të tjera:

• Mesazhi i ndalimit, kodi i kontrollit të gabimeve dhe parametrat e tij.
• Konteksti i procesorit (PRCB) të procesorit që shkaktoi dështimin.
• Informacion mbi procesin e bërthamës (EPROSS) të procesit aktiv në kohën e rrëzimit.
• Informacioni i fijes në kernel (ETHREAD) e fijes që shkaktoi rrëzimin.
• Stiva e thirrjeve në modalitetin kernel për atë fije (deri në 16 KB).
• Lista e drajverëve të ngarkuar në kohën e vendimit.
• Lista e moduleve të ngarkuara dhe të shkarkuara.
• Një bllok i të dhënave për debugging me informacionin bazë të sistemit.

Ky lloj i skedarit dump zakonisht ruhet në %SystemRoot%\Minidump (për shembull, C:\Windows\Minidump ). Për shumë raste mbështetjeje bazë ose diagnostikimi, një minidump i analizuar plotësisht me !analyze -v mund të jetë më se i mjaftueshëm.

Humbja e Memories Kernel

Depoja e memories kernel përmban përmbajtjen e memories kernel në kohën e rrëzimit, duke përjashtuar hapësirat e memories së procesit të përdoruesit. Ofron një ekuilibër të vlefshëm midis madhësisë dhe detajeve dhe shpesh është opsioni i rekomanduar për diagnostikimin e shumicës së BSOD-ve.

Kjo skedar dump ruhet si MEMORY.DMP në %SystemRoot% (si parazgjedhje, C:\Windows\MEMORY.DMP ). Madhësia e saj varet nga memoria e përdorur nga kerneli, por zakonisht është shumë më e madhe se një minidump dhe shumë më e menaxhueshme se një skedar dump i plotë.

Plotësoni shkarkimin e kujtesës

Një dep i plotë i memories ruan praktikisht të gjithë përmbajtjen e RAM-it në kohën e gabimit: bërthamën, proceset e përdoruesit, etj. Është më i detajuari, por edhe ai që zë më shumë hapësirë ​​dhe është më i kërkuari për sa i përket konfigurimit.

Që një deponi e plotë të jetë e vlefshme, duhet të përmbushen disa kërkesa:

• El skedar paging duhet të jetë në e njëjta ndarje ku është instaluar Windows.
• Duhet të ketë Hapësira e diskut të paktën e barabartë me madhësinë e memories fizike të makinës.
• Mos e zhvendosni skedarin e faqes në një disk tjetër fizik nëse doni të shmangni demp-et e korruptuara.

Në mjediset e prodhimit me shumë RAM, një deponi i plotë mund të jetë jopraktik, por për raste shumë komplekse ose me ndërprerje mund të bëjë gjithë ndryshimin në gjetjen e problemit.

Konfiguro Windows për të kapur dhe regjistruar BSOD-të

Para se të fillojmë punën me WinDbg, është thelbësore të sigurohemi që sistemi po gjeneron saktë skedarët dump dhe po regjistron ngjarjen e ekranit blu.

Në dritaren "Fillimi dhe Rimëkëmbja" gjejmë disa opsione përkatëse:

• Shkruaj një ngjarje në regjistrin e sistemit: duhet të jetë i aktivizuar që kontrolli i gabimeve të regjistrohet në Shikuesin e Ngjarjeve.
• Shkruaj informacionin e debugging-ut: këtu zgjedhim Minidump, Kernel memory dump ose Complete memory dump.
• shtegu i skedarit të shkarkimit: parazgjedhur %SystemRoot%\MEMORY.DMP për kernel/të plotë.
• Rinisni automatikisht: është e këshillueshme ta ç'shënojmë nëse duam shiko me qetësi ekranin blu dhe vini re atë që shfaqet.

Për disa prodhues ose departamente mbështetjeje, si në rastin e disa adaptorëve të rrjetit, përdoruesit i kërkohet të paraqesë skedarin dump . Zakonisht ndodhet në C:\Windows\memory.dmp dhe rekomandohet ta gjeni sipas datës/orës për të identifikuar atë që korrespondon me dështimin e fundit.

Nëse ajo që duam është të jemi në gjendje të detyrojmë një dump edhe kur sistemi është i ngrirë (pa përgjigjen e tastierës ose mausit), ekziston edhe një truk shumë i dobishëm për tastierat PS/2 (jo USB/Bluetooth), i cili konsiston në konfigurimin e regjistrit për të shkaktuar një dump me një kombinim tastesh.

Detyro një dump duke përdorur tastierën në rast të ngrirjes

Për të gjeneruar një "memory dump" edhe nëse ekrani është i ngrirë plotësisht, mund të përdorni opsionin CrashOnCtrlScroll në tastierat PS/2. Kjo metodë nuk është e vlefshme për tastierat USB ose Bluetooth.

Në regjistër, duhet të krijojmë ose modifikojmë çelësin e mëposhtëm:

HKEY_LOCAL_MACHINE
  System
    CurrentControlSet
      Services
        i8042prt
          Parameters

Nombre: CrashOnCtrlScroll
Tipo:   REG_DWORD
Valor:  1

Pas rinisjes, në çdo kohë (edhe me ekranin e ngrirë) mund të aktivizoni një bllokim të kontrolluar dhe ta bëni sistemin të gjenerojë një deponi memorieje duke shtypur tastin e djathtë CTRL dhe pastaj tastin Scroll Lock dy herë . Kjo është shumë e dobishme për të hetuar bllokimet e forta që nuk shfaqin një BSOD më vete.

Hyrje në WinDbg për analizimin e kernel dump-eve

WinDbg është mjeti kryesor i Microsoft-it për debugging-un e kernel-it dhe analizën e memory dump-it . Është i disponueshëm falas (momentalisht edhe në Microsoft Store si WinDbg Preview) dhe, megjithëse mund të duket e frikshme në shikim të parë, për një analizë fillestare BSOD duhet të kuptoni vetëm disa opsione bazë.

Mund ta instalojmë WinDbg në vetë makinën e prekur ose në çdo kompjuter tjetër ; skedari .dmp mund të kopjohet në rrjet, nëpërmjet USB-së, ose edhe të kompresohet në një skedar CAB. Procesori dhe versioni i Windows ku analizojmë të dhënat nuk duhet domosdoshmërisht të përputhen me ato të makinës që u rrëzua.

Nisni WinDbg me një skedar dump nga rreshti i komandës

Një mënyrë klasike për të hapur një skedar dump-i memorieje në WinDbg është përdorimi i rreshtit të komandës me parametrin `-z` , duke specifikuar shtegun drejt skedarit dump. Kjo mund të kombinohet me parametra të tjerë siç janë shtegu i simbolit ose binari.

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

Modifikuesi -v aktivizon modalitetin e detajuar , i cili është shumë i dobishëm për të parë më shumë kontekst. Përveç WinDbg, ekziston edhe kd.exe , një debugger i bazuar në konsolë që ju lejon të bëni praktikisht të njëjtën gjë, por pa një ndërfaqe grafike.

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

Hapni një skedar dump nga ndërfaqja grafike

Nëse WinDbg është hapur tashmë në modalitetin pasiv, mund të ngarkoni një skedar rrëzimi duke përdorur menynë Skedar → Hapni rrëzimin e skedarit ose shkurtoren Ctrl+D . Zgjidhni skedarin .dmp (ose edhe një skedar .cab që e përmban atë) dhe WinDbg do të ngarkojë informacionin e rrëzimit.

Një alternativë tjetër është të hapni WinDbg, dhe pasi të jeni brenda, të ekzekutoni komandën .opendump duke specifikuar shtegun drejt skedarit dump dhe më pas komandën g (Go) për të filluar seancën e debugging-ut të dump:

.opendump C:\Windows\Memory.dmp
g

WinDbg madje lejon pastroni disa deponi në të njëjtën kohëduke shtuar disa parametra -z në rreshtin e komandës ose duke përsëritur .opendump me rrugë të ndryshme dhe menaxhimin e seancës me shumë destinacione.

Konfiguro shtegun e simbolit në WinDbg

Pa simbole, WinDbg funksionon pothuajse verbërisht. Simbolet (.pdb) përmbajnë informacion për debugging në lidhje me funksionet, strukturat e brendshme, variablat, zhvendosjet, etj. , dhe janë thelbësore për analiza të besueshme, veçanërisht kur punohet me kernelin.

Për të përdorur simbolet publike të Microsoft-it pa pasur nevojë t'i shkarkoni manualisht, praktika më e mirë është të konfiguroni një server simbolesh që tregon serverin zyrtar të Microsoft-it dhe një direktori lokale të memorjes së përkohshme. Për shembull, së pari mund të krijojmë një dosje C:\symbols dhe pastaj, në WinDbg, të konfigurojmë shtegun e simboleve si më poshtë:

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

Kjo mund të bëhet nga menyja Skedari → Shtegu i Skedarit të Simboleve ose, në Parapamjen e WinDbg, nga Skedari → Cilësimet → Cilësimet e Debugging duke rregulluar "Shtegu i parazgjedhur i simboleve". Herën e parë që analizoni një dump nga një sistem specifik, debugger do të shkarkojë automatikisht simbolet e nevojshme nga interneti, gjë që mund të zgjasë disa minuta në varësi të lidhjes suaj.

Është e rëndësishme të theksohet se simbolet publike të Microsoft-it ndonjëherë nuk përfshijnë të gjithë informacionin e brendshëm të tipit dhe mund të shihni paralajmërime si "Debugger-i juaj nuk po përdor simbolet e sakta" ose referenca për tipe të pazgjidhshme. Për analizën bazë të BSOD-së, simbolet publike zakonisht janë të mjaftueshme, por nëse keni nevojë për më shumë detaje, do të ketë kufizime.

Analiza e parë: komandat bazë dhe kontrolli i gabimeve

Pasi të jetë ngarkuar skedari i dump-it dhe të jenë konfiguruar simbolet, WinDbg zakonisht shfaq një kokë me informacionin e sistemit dhe një paralajmërim si p.sh. "Përdorni !analyze -v për të marrë informacion të detajuar mbi debugging-un." Ky është ndalesa jonë e parë për një analizë fillestare.

Komanda !analyze -v kryen një analizë automatike të dump-it dhe zakonisht ofron:

• Kodi i kontrollit të gabimeve (për shembull, 0xE3, 0xD1, 0x9F, 0x44…).
• Parametrat Arg1, Arg2, Arg3 dhe Arg4 nga kontrolli i gabimeve.
• Moduli ose drajveri më i mundshëm shkaku i dështimit (Probably caused by).
• Procesi i lidhur në atë moment (për shembull, Teams.exe).
• Staku i thirrjeve (gjurmimi i stakut) e fijes që shkaktoi rrëzimin.
• Informacion mbi kovën dhe hash-et e dështimit, të dobishme për korrelimin e gabimeve të përsëritura.

Për shembull, në një rast kontrolli të gabimeve në botën reale RESOURCE_NOT_OWNED (0xE3) , analiza mund të tregojë se një fije u përpoq të lëshonte një burim që nuk e zotëron , duke e shfaqur Teams.exe si proces dhe duke treguar win32kbase.sys në një funksion si DrvEnumDisplaySettings . Kjo sugjeron që fija që dështoi po kërkonte ose manipulonte cilësimet e ekranit nga hapësira e përdoruesit përmes shtresës grafike të Windows.

Për të hyrë pak më thellë në detajet e kodit të ndalimit dhe parametrave të tij, kemi edhe komandën .kontroll gabimeshe cila shfaq përsëri kontrollin e gabimeve dhe katër argumentet, gjë që është e dobishme nëse duam ta përsërisim atë informacion pa i riekzekutuar të gjitha. !analyze -v.

Raste praktike: faktorë nxitës dhe konflikte tipike

Analiza e BSOD zakonisht sillet rreth identifikimit të drajverëve me defekt ose që nuk funksionojnë siç duhet , konflikteve të drajverëve, aksesit të papërshtatshëm në memorie, trajtimit të gabuar të IRP-ve (Paketave të Kërkesës I/O) e kështu me radhë. Le të shohim disa shembuj praktikë nga rastet e botës reale për ta kuptuar më mirë procesin.

RESOURCE_NOT_OWNED (0xE3) i lidhur me Teams dhe win32kbase.sys

Në një skenar të Windows 10 ku, pas disa ditësh funksionimi, shfaqet një BSOD me bugcheck 0xE3 (RESOURCE_NOT_OWNED) , skedari i minikernel tregon diçka të ngjashme me:

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

Këtu, debugger tregon se kontrolli i gabimeve shkaktohet nga një fije e lidhur me Teams.exe , por kodi që ndodhet në të vërtetë në stivë në momentin kritik i përket win32kbase.sys , konkretisht funksionit DrvEnumDisplaySettings . Kjo nuk do të thotë domosdoshmërisht që Teams është fajtori i drejtpërdrejtë, por përkundrazi që Teams po thërret një API përdoruesi që rezulton në një gabim sinkronizimi ose lirimi burimesh në nënsistemin grafik.

Në këto lloje diagnozash, përfundimi është shpesh se është një gabim në paketën grafike të Windows, një drajver specifik videoje ose bashkëveprimi midis aplikacionit dhe drajverëve. Zgjidhja aktuale mund të përfshijë përditësimin e drajverëve të GPU-së, përditësimin e Teams ose edhe aplikimin e patch-eve specifike të Windows , në vend që thjesht të pritet që të rregullohet vetë.

DRIVER_IRQL_NOT_LESS_OR_EQUAL (0xD1) me NotMyFault

Programi NotMyFault i Sysinternals është një mjet edukativ që ju lejon të gjeneroni gabime të kernelit në një mënyrë të kontrolluar për të mësuar se si të analizoni pamjet e ekranit. Për shembull, nëse hapni opsionin High IRQL fault (modaliteti i kernelit) nga NotMyFault dhe klikoni "Do Bug", do të detyroni një gabim DRIVER_IRQL_NOT_LESS_OR_EQUAL (0xD1).

Në ekranin blu, do të shohim diçka si DRIVER_IRQL_NOT_LESS_OR_EQUAL dhe ndoshta një drajver kandidat (për shembull, MyFault.sys , drajveri i përdorur nga mjeti). Pasi të gjenerohet dhe hapet dump me WinDbg, rezultati fillestar mund të duket diçka si ky:

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

Edhe pse debugger tregon për korruptim të memories , ne e dimë se shkaku i vërtetë lidhet me NotMyFault dhe drajverin e tij. Për ta konfirmuar këtë, mund të vazhdojmë gjurmimin me komanda si !thread për të parë se çfarë thirrjesh bën thread në kohën e dështimit, dhe !irp për të analizuar IRP-në e përfshirë nëse kontrolli i gabimeve lidhet me operacionet I/O.

Për shembull, me `!thread <dir_thread>` mund të shohim gjurmën e stack-ut të thread-it dhe të gjejmë udhëzimin ku shfaqet `myfault+0x403` , duke treguar se ku ka gabuar drajveri i testimit. Nga aty, mund të shqyrtojmë IRP-në, statusin e memories e kështu me radhë, ashtu siç do të bënim me një gabim të vërtetë.

Konflikte MULTIPLE_IRP_COMPLETE_REQUESTS (0x44) dhe USB

Një tjetër rast shumë ilustrues është kontrolli i gabimeve KËRKESA TË SHUMËFISHTA TË PËRFUNDUARA TË IRP-së ​​(0x44)Ky gabim ndodh kur Një IRP (Paketë Kërkese I/O) përfundohet më shumë se një herë., zakonisht sepse dy shoferë të ndryshëm besojnë se kanë të njëjtën IRP dhe të dy telefonojnë IoCompleteRequest().

Analiza me !analyze -v mund të japë një përshkrim të ngjashëm me këtë:

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

Fillimisht, i dyshuari duket të jetë usbehci.sys , një drajver i Microsoft për kontrolluesit USB EHCI. Megjithatë, është relativisht e rrallë që një gabim të shkaktohet nga një drajver i Windows-it pa ndërveprimin e ndonjë pale të tretë. Për të arritur në thelb, ne përdorim adresën IRP të ofruar nga bugcheck (Arg1) dhe ekzekutojmë !irp <IRP_ADDRESS> :

!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

Në rreshtin e fundit, e shohim qartë vargun \Driver\usbehci ax88172 , që zbulon se IRP ka kaluar si nëpër usbehci.sys ashtu edhe nëpër një drajver të quajtur ax88172.sys , i shoqëruar me një çipset specifik të rrjetit USB (AX88172). Prandaj, mund të konkludojmë se konflikti buron nga ky drajver i kartës USB të palës së tretë , jo nga drajveri gjenerik EHCI i Microsoft-it.

Në atë rast, zgjidhja përfshin përditësimin e drajverit të përshtatësit USB, zëvendësimin e pajisjes ose, nëse është e nevojshme, heqjen e saj . Ky lloj analize IRP është veçanërisht i dobishëm për BSOD-të që lidhen me USB-në, ruajtjen, kartat e rrjetit dhe, në përgjithësi, çdo komponent që përdor I/O intensive.

Komanda të dobishme WinDbg në modalitetin kernel

Përtej !analyze -v dhe .bugcheck , ekzistojnë disa zgjerime dhe komanda WinDbg që janë shumë të dobishme kur duam të futemi pak më thellë në procesin e shkarkimit të kernel-it.

Disa nga më të zakonshmet janë:

• !fijeShfaq informacion të detajuar rreth një fije pune (thread), duke përfshirë grumbullin e thirrjeve, gjendjen, IRP-të e lidhura, etj. Ju lejon të shihni "veprimet e fundit" të fijes që ishte duke u ekzekutuar kur sistemi u rrëzua.
• !proces 0 0Kjo rendit të gjitha proceset aktive në kohën e rrëzimit. Është e dobishme për të identifikuar nëse ka pasur ndonjë proces, shërbim, EDR, antivirus etj. të dyshimtë që funksiononte në makinë.
• !irp: analizon një IRP specifike dhe tregon gjurmën e shoferëve që ka kaluarKomanda I/O, flamujt, etj., janë çelësi në gabimet që lidhen me MULTIPLE_IRP_COMPLETE_KËRKESA dhe gabime të tjera I/O.
• !cpuinfo: ofron informacion në lidhje me procesorin (prodhuesi, MHz, nënshkrimet, karakteristikat), i dobishëm për verifikimin e mjediseve harduerike.
• !pebShfaq detajet e PEB (Bllokut të Mjedisit të Procesit), siç janë emri i kompjuterit, rruga e instalimit të Windows, numri i procesorëve, etj.
• !token: ofron informacion në lidhje me tokenët e sigurisë, lejet dhe kontekstin e sigurisë së procesit ose fijes.
• .cls: pastron dritaren e komandave, si në një konsolë të rregullt.

Përveç kësaj, shumë zgjerime specifike të sistemit të skedarëve (p.sh., për PnP, NTFS, etj.) ju lejojnë të nxirrni edhe më shumë informacion nga dump-et. Në disa raste, WinDbg do të tregojë praninë e BLACKBOX* (BLACKBOXBSD, BLACKBOXNTFS, BLACKBOXPNP, BLACKBOXWINLOGON), të cilat janë blloqe shtesë të dhënash të kapura gjatë kontrollit të gabimeve për të lehtësuar diagnostikimin e zonave specifike të sistemit.

Përdorimi i Verifikuesit të Drajverit për të gjetur drajverë problematikë

Një përqindje shumë e lartë e gabimeve të Ekranit Blu të Vdekjes (BSOD) të Windows shkaktohen nga drajverë të dëmtuar ose të programuar dobët . Për të zbuluar në mënyrë proaktive këto lloje problemesh, sistemi përfshin një mjet të fuqishëm: Verifikuesin e Drajverit.

Verifikuesi i Drajverit funksionon në kohë reale dhe i nënshtron drajverët e zgjedhur një sërë testesh dhe testesh stresi: kontrollon përdorimin e saktë të memories, përdorimin e pishinës së kernelit, IRQL, IRP, etj. Nëse zbulon se një drajver nuk sillet siç duhet, mund të detyrojë një BSOD të kontrolluar në mënyrë që të analizojmë një dump shumë më të qartë, ku fajtori zakonisht identifikohet lehtësisht.

Për të nisur menaxherin e Verifikuesit të Driver-it, thjesht hapni një komandë me të drejta administratori dhe shkruani:

verifier

Nga aty, mund të zgjedhim se cilët drajverë duam të verifikojmë. Është e mençur të jemi të kujdesshëm: Verifikuesi shton mbingarkesë në sistem dhe mund të degradojë performancën , kështu që rekomandohet të aktivizoni verifikimin vetëm për sa më pak drajverë të dyshimtë të jetë e mundur, në vend që të zgjidhni të gjithë pa dallim.

Pasi Verifikuesi shkakton një BSOD pas zbulimit të sjelljes së pasaktë, ne mund të analizojmë dump-in e kernel-it me WinDbg dhe, shpresojmë, të shohim qartë se cili drajver është kapur dhe çfarë ka bërë gabim. Artikujt referues të Microsoft-it mbi Driver Verifier shpjegojnë në detaje opsionet dhe strategjitë e ndryshme të përdorimit.

Këshilla praktike për inxhinierë dhe teknikë

Pavarësisht nëse jeni zhvillues drajverësh, zhvillues softuerësh që bashkëvepron me kernelin, apo thjesht tekniku i duhur që merr të gjitha ekranet blu të vdekjes, ka disa udhëzime që ia vlen t'i përvetësoni për të shmangur humbjen në xhunglën e BSOD-ve.

Hapi i parë, kur gabimi lidhet me kodin tuaj, është të përdorni sistematikisht debugger-in e bërthamës për të riprodhuar dhe analizuar problemin . Duke lidhur një debugger me makinën e synuar (nëpërmjet rrjetit, serialit, etj.), një kontroll i gabimeve do të bëjë që sistemi të ndalet brenda debugger-it në vend që të shfaqë ekranin blu direkt. Nga atje, mund të inspektoni memorien, stivat, strukturat dhe të korrigjoni kodin.

Në skenarë të tjerë, kontrollet e gabimeve mund të jenë për shkak të drajverëve, pajisjeve ose softuerëve të palëve të treta që ne nuk i kontrollojmë. Në këto raste, qëllimi ndryshon nga "rregullimi i kodit" në izolimin dhe zbutjen e problemit.

• Identifikoni drajverin ose komponentin e dyshuar të harduerit duke përdorur WinDbg dhe analizën e dump-it.
• Përditëso ose rikthe versionet e drajverëve, BIOS, firmware ose aplikacione të lidhura.
• Hiq ose zëvendëso Pajisjet USB, kartat grafike, adaptorët e rrjetit konfliktual.
• Të mbështetesh në Shikuesi i ngjarjeve, Sysinternals, mjetet e monitorimit dhe analizës së rrjetit për kontekst shtesë.

Shumë probleme në dukje misterioze zgjidhen me procedurat themelore të zgjidhjes së problemeve : shqyrtimi i dokumentacionit, kontrollimi i versioneve dhe datave të skedarëve, riinstalimi i komponentëve kryesorë ose çaktivizimi i moduleve që bien ndesh. Analizimi i skedarëve na jep një drejtim të qartë se ku të kërkojmë dhe shpesh na kursen orë të tëra provash dhe gabimesh.

Është gjithashtu e rëndësishme të mbani mend se, në mjedise si ai që shkaktoi incidentin CrowdStrike Falcon dhe EDR të tjera, pyetjet më të zakonshme sillen rreth asaj që shkaktoi BSOD-në dhe si ta identifikoni shpejt atë . Konfigurimi i duhur i WinDbg, me simbole dhe një procedurë të qartë për hapjen dhe analizimin e dump-eve, ju lejon të kufizoni brenda pak minutash atë që përndryshe mund të përfundonte në një "formato dhe riinstalim" pa e kuptuar vërtet shkakun.

Shkurt, kombinimi i një konfigurimi të mirë të memory dump-it, përdorimit të disiplinuar të mjeteve si WinDbg, Driver Verifier dhe Sysinternals, si dhe zakonit të shqyrtimit metodik të log-eve dhe stack-eve, i kthen ekranet blu të një armiku të paparashikueshëm në një burim shumë të saktë informacioni rreth asaj që ka dështuar në kernel , duke na ndihmuar të marrim vendime teknike shumë më të informuara.