Täydellinen opas BSOD-virheiden ja ytimen vedosten analysointiin Windowsissa

Informatec Digital » Resurssit » Täydellinen opas BSOD-virheiden ja kernel-vedosten analysointiin Windowsissa

Kun Windows-tietokone jumiutuu siniseen näyttöön, se ei ole vain ärsyttävää: muistivedoksessa on usein arvokasta tietoa , joka kertoo tarkalleen, mitä kernelissä tapahtui. Sen sijaan, että syyttäisit RAM-muistia, BIOSia tai alustaisit tietokoneen välittömästi uudelleen, kannattaa opetella lukemaan kyseisiä tietoja.

Harjoittelemalla hieman työkalut, kuten WinDbg, ja funktiot, kuten !analyze -v, .bugcheck, tai symbolien oikea käyttö , auttavat meitä siirtymään tilanteesta "Saan sinisen ruudun virheen" tilanteeseen "Tiedän, mikä ajuri, resurssi tai laite aiheutti BSOD:n". Tässä artikkelissa käymme läpi askel askeleelta ja yksityiskohtaisesti, miten BSOD analysoidaan sen ytimen vedoksen avulla, minkä tyyppisiä vedoksia on olemassa, miten kaikki valmistetaan ja mitä komentoja käytetään analyysin tehostamiseksi.

Mikä on BSOD ja mitä tietoja se sisältää?

Kun Windows kohtaa tilanteen, joka vaarantaa järjestelmän eheyden eikä sitä voida palauttaa turvallisesti, se tekee sisäisen kernel-kutsun nimeltä KeBugCheckEx . Tämä kutsu laukaisee pahamaineisen sinisen ruudun (BSOD).

KeBugCheckEx vastaanottaa aina viisi argumenttia: STOP-koodin (virheentarkistuskoodi) ja neljä lisäparametria , jotka antavat virheelle teknisen kontekstin. Näitä samoja tietoja voimme sitten tarkastella.

• Sinisellä ruudulla klassinen, jos järjestelmää ei ole määritetty käynnistymään uudelleen automaattisesti.
• Windowsin tapahtumalokissa, Tapahtumienvalvonnassa (järjestelmälokissa).
• Muistivedostiedostossa (minivedos, kernel-vedos tai täysi vedos) käyttämällä WinDbg:tä ja komentoja, kuten !analyze -v o .bugcheck.

Jokaisella virheenkorjauskoodilla on symbolinen nimi ja siihen liittyvä heksadesimaaliarvo . Esimerkiksi virheenkorjauskoodilla DRIVER_POWER_STATE_FAILURE on koodi 0x9F , kun taas RESOURCE_NOT_OWNED vastaa koodia 0xE3 . Nämä koodit ja niiden parametrit on dokumentoitu Microsoftin virheenkorjauskoodien referenssissä, joka kannattaa pitää aina käsillä.

Koodin lisäksi sinisessä ruudussa saattaa näkyä mahdollisesti ongelmaan liittyvän .sys-ajurin nimi . Jos kyseessä on kolmannen osapuolen ajuri (virustorjuntaohjelma, verkkokortti, näytönohjain jne.), meillä on usein selkeä epäilys. Jos näkyviin tulee yleinen järjestelmäkomponentti (ntoskrnl.exe, win32k.sys jne.) tai jos mitään ei näy ollenkaan, meidän on suoritettava muistivedos ja käytettävä WinDbg:tä tutkiaksemme asiaa tarkemmin.

Muistivedosten tyypit Windowsissa

Jotta voimme analysoida BSOD:ia yksityiskohtaisesti, Windowsin on luotava muistivedostiedosto (DMP), kun virhe ilmenee. Tämä tiedosto tallentaa järjestelmän tilan virhehetkellä ja voi olla erityyppisiä.

"Käynnistys ja palautus" -asetuksissa (napsauta hiiren kakkospainikkeella "Tämä tietokone / Oma tietokone" → Ominaisuudet → Järjestelmän lisäasetukset → "Lisäasetukset"-välilehti → "Asetukset"-painike kohdassa "Käynnistys ja palautus") voit valita useista erityyppisistä vedoksista. Jokaisella on omat etunsa ja haittansa.

Pieni muistivedos (Minidump)

Minidump - muoto on pienin (noin 64 kt) ja myös rajoitetuin edistyneeseen virheenkorjaukseen. Se on kuitenkin edelleen hyödyllinen nopean diagnoosin saamiseksi monissa BSOD-tilanteissa.

Minidump tallentaa muun muassa seuraavat tiedot:

• Pysäytysviesti, virheenkorjauskoodi ja sen parametrit.
• Suorittimen konteksti (PRCB) sen prosessorin, joka aiheutti virheen.
• Ytimen prosessitiedot Aktiivisen prosessin (EPROSS) kaatumisen aikaan.
• Säikeiden tiedot ytimessä (ETHREAD) kaatumisen aiheuttaneesta säikeestä.
• Ydintilan kutsupino kyseiselle ketjulle (enintään 16 kt).
• Ladattujen ajureiden luettelo tuomion aikaan.
• Ladattujen ja ladattujen moduulien luettelo.
• Virheenjäljitysdatalohko perusjärjestelmän tiedoilla.

Tämän tyyppinen vedos tallennetaan tyypillisesti kansioon %SystemRoot%\Minidump (esimerkiksi C:\Windows\Minidump ). Monissa perustason tuki- tai diagnostiikkatapauksissa perusteellinen minidump, joka on analysoitu komennolla !analyze -v, voi olla enemmän kuin riittävä.

Ytimen muistivedos

Ytimen muistivedos sisältää ytimen muistin sisällön kaatumisen hetkellä, lukuun ottamatta käyttäjän prosessien muistialueita. Se tarjoaa arvokkaan tasapainon koon ja tarkkuuden välillä ja on usein suositeltu vaihtoehto useimpien kaatumisten diagnosointiin.

Tämä vedos tallennetaan nimellä MEMORY.DMP kansioon %SystemRoot% (oletusarvoisesti C:\Windows\MEMORY.DMP ). Sen koko riippuu ytimen käyttämästä muistista, mutta se on yleensä paljon suurempi kuin minivedos ja paljon helpommin hallittavissa kuin täysi vedos.

Täydellinen muistivedos

Täysi muistivedos tallentaa käytännössä kaiken RAM-muistin sisällön virhehetkellä: ytimen, käyttäjäprosessit jne. Se on yksityiskohtaisin, mutta myös eniten tilaa vievä ja konfiguroinnin kannalta vaativin.

Jotta täydellinen tyhjennys olisi pätevä, useiden vaatimusten on täytyttävä:

• El sivutiedosto täytyy olla kohdassa sama osio, johon Windows on asennettu.
• On oltava levytilaa vähintään yhtä paljon kuin fyysisen muistin koko koneen.
• Älä siirrä sivutustiedostoa toiselle fyysiselle levylle, jos haluat välttää vioittuneet vedokset.

Tuotantoympäristöissä, joissa on paljon RAM-muistia, täysi vedos voi olla epäkäytännöllinen, mutta erittäin monimutkaisissa tai satunnaisissa tapauksissa sillä voi olla ratkaiseva merkitys ongelman paikantamisessa.

Määritä Windows kaappaamaan ja kirjaamaan BSOD-virheet

Ennen kuin aloitamme WinDbg:n käytön, on tärkeää varmistaa, että järjestelmä luo vedokset ja kirjaa sinisen ruudun tapahtuman oikein.

"Käynnistä ja palautus" -ikkunassa on useita asiaankuuluvia vaihtoehtoja:

• Kirjoita tapahtuma järjestelmälokiin: on oltava käytössä, jotta virheenkorjaustarkistus tallennetaan Tapahtumienvalvonnassa.
• Kirjoita virheenkorjaustiedot: tässä valitsemme Minidump, Kernel memory dump tai Complete memory dump.
• vedostiedoston polkuoletusarvo %SystemRoot%\MEMORY.DMP kernel/full-versiolle.
• Käynnistä automaattisesti uudelleenon suositeltavaa poistaa valinta, jos haluamme katso rauhallisesti sinistä ruutua ja kiinnitä huomiota siihen, mitä näkyy.

Joidenkin valmistajien tai tukiosastojen, kuten tiettyjen verkkosovittimien tapauksessa, käyttäjältä pyydetään lähettämään vedostiedosto . Se sijaitsee yleensä kansiossa C:\Windows\memory.dmp , ja on suositeltavaa etsiä se päivämäärän/kellonajan mukaan, jotta voidaan tunnistaa viimeisimmän virheen aiheuttanut tiedosto.

Jos haluamme voida pakottaa vedoksen luomisen myös järjestelmän ollessa jumiutunut (ilman näppäimistön tai hiiren reagointia), on olemassa myös erittäin hyödyllinen kikka PS/2-näppäimistöille (ei USB/Bluetooth-näppäimistöille): rekisterin määrittäminen käynnistämään vedos näppäinyhdistelmällä.

Pakota vedos näppäimistöllä jumiutumisen sattuessa

Voit luoda muistivedoksen, vaikka näyttö olisi täysin jumiutunut, käyttämällä CrashOnCtrlScroll -vaihtoehtoa PS/2-näppäimistöissä. Tämä menetelmä ei toimi USB- tai Bluetooth-näppäimistöissä.

Rekisterissä meidän on luotava tai muokattava seuraavaa avainta:

HKEY_LOCAL_MACHINE
  System
    CurrentControlSet
      Services
        i8042prt
          Parameters

Nombre: CrashOnCtrlScroll
Tipo:   REG_DWORD
Valor:  1

Uudelleenkäynnistyksen jälkeen voit milloin tahansa (myös näytön ollessa jähmettynyt) laukaista hallitun kaatumisen ja saada järjestelmän luomaan muistivedoksen painamalla oikeaa CTRL -näppäintä ja sitten Scroll Lock -näppäintä kahdesti . Tämä on erittäin hyödyllistä tutkittaessa kovia kaatumisia, jotka eivät itsessään näytä BSOD:ia.

Johdatus WinDbg:hen ytimen vedosten analysointia varten

WinDbg on Microsoftin ensisijainen työkalu ytimen virheenkorjaukseen ja muistivedosten analysointiin . Se on saatavilla ilmaiseksi (tällä hetkellä myös Microsoft Storessa nimellä WinDbg Preview), ja vaikka se saattaa ensi silmäyksellä vaikuttaa pelottavalta, alustavaa BSOD-analyysiä varten sinun tarvitsee ymmärtää vain muutamia perusasetuksia.

Voimme asentaa WinDbg:n itse ongelmalliseen koneeseen tai mihin tahansa muuhun tietokoneeseen ; .dmp-tiedosto voidaan kopioida verkon kautta, USB:n kautta tai jopa pakata CAB-tiedostoksi. Vedosta analysoitavan prosessorin ja Windows-version ei välttämättä tarvitse vastata kaatuneen koneen vastaavia.

Käynnistä WinDbg komentoriviltä tehtävällä vedoksella

Klassinen tapa avata muistivedos WinDbg:ssä on käyttää komentoriviä ja `-z` -parametria , joka määrittää vedostiedoston polun. Tätä voidaan yhdistää muihin parametreihin, kuten symboliin tai binääripolkuun.

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

-v - modifikaattori aktivoi yksityiskohtaisen tilan , joka on erittäin hyödyllinen kontekstin näkemisen kannalta. WinDbg:n lisäksi on olemassa myös kd.exe , konsolipohjainen virheenkorjausohjelma, jonka avulla voit tehdä käytännössä saman asian ilman graafista käyttöliittymää.

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

Avaa vedos graafisesta käyttöliittymästä

Jos WinDbg on jo auki passiivisessa tilassa, voit ladata kaatumisvedostiedoston valitsemalla Tiedosto → Avaa kaatumisvedos tai painamalla Ctrl+D -näppäinyhdistelmää . Valitse .dmp-tiedosto (tai jopa sitä sisältävä .cab-tiedosto), niin WinDbg lataa kaatumistiedot.

Toinen vaihtoehto on käynnistää WinDbg ja sen sisällä suorittaa komento .opendumpp , joka määrittää vedostiedoston polun, ja sitten komento g (Go) aloittaakseen vedosten virheenkorjausistunnon:

.opendump C:\Windows\Memory.dmp
g

WinDbg jopa sallii siivoa useita kaatopaikkoja kerrallalisäämällä useita parametreja -z komentorivillä tai toistamalla .opendump eri reiteillä ja monikohdeistunnon hallinnassa.

Symbolipolun määrittäminen WinDbg:ssä

Ilman symboleja WinDbg toimii lähes sokeasti. Symbolit (.pdb) sisältävät virheenkorjaustietoja funktioista, sisäisistä rakenteista, muuttujista, offseteista jne . ja ovat välttämättömiä luotettavalle analyysille, erityisesti ytimen kanssa työskenneltäessä.

Jotta Microsoftin julkisia symboleja voitaisiin käyttää ilman manuaalista latausta, paras käytäntö on määrittää symbolipalvelin, joka osoittaa viralliseen Microsoftin palvelimeen, ja paikallinen välimuistihakemisto. Voimme esimerkiksi ensin luoda kansion C:\symbols ja sitten WinDbg:ssä määrittää symbolipolun seuraavasti:

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

Tämä voidaan tehdä Tiedosto → Symbolitiedoston polku -valikosta tai WinDbg-esikatselussa kohdasta Tiedosto → Asetukset → Virheenkorjausasetukset muuttamalla ”Oletussymbolipolkua”. Kun analysoit tietyn järjestelmän vedosta ensimmäisen kerran, virheenkorjausohjelma lataa tarvittavat symbolit automaattisesti internetistä, mikä voi kestää muutaman minuutin yhteytesi tehosta riippuen.

On tärkeää huomata, että Microsoftin julkiset symbolit eivät aina sisällä kaikkia sisäisiä tyyppitietoja , ja saatat nähdä varoituksia, kuten "Virheenkorjaajasi ei käytä oikeita symboleja" tai viittauksia ratkaisemattomiin tyyppeihin. Perus BSOD-analyysiin julkiset symbolit yleensä riittävät, mutta jos tarvitset lisätietoja, on olemassa rajoituksia.

Ensimmäinen analyysi: peruskomennot ja virheentarkistus

Kun vedos on ladattu ja symbolit konfiguroitu, WinDbg näyttää yleensä otsikon, jossa on järjestelmätiedot ja varoitus, kuten "Käytä !analyze -v saadaksesi yksityiskohtaisia ​​virheenkorjaustietoja." Tämä on ensimmäinen vaihe alustavaa analyysia varten.

Komento !analyze -v suorittaa vedoksen automaattisen analyysin ja antaa yleensä seuraavat tulokset:

• Virheenkorjauskoodi (esimerkiksi 0xE3, 0xD1, 0x9F, 0x44…).
• Parametrit Arg1, Arg2, Arg3 ja Arg4 bugitarkistuksesta.
• Todennäköisin moduuli tai ajuri epäonnistumisen syy (Probably caused by).
• Liittyvä prosessi sillä hetkellä (esimerkiksi Teams.exe).
• Kutsupino (pinon jäljitys) ketjusta, joka laukaisi kaatumisen.
• Kauhan tiedot ja virhehajautukset, jotka ovat hyödyllisiä toistuvien virheiden korreloinnissa.

Esimerkiksi reaalimaailman virheentarkistustapauksessa RESOURCE_NOT_OWNED (0xE3) analyysi saattaa viitata siihen, että säie yritti vapauttaa resurssia, jota se ei omista , näyttäen Teams.exe -prosessin prosessina ja osoittaen win32kbase.sys- tiedostoon funktiossa, kuten DrvEnumDisplaySettings . Tämä viittaa siihen, että virheellinen säie kyseli tai manipuloi näyttöasetuksia käyttäjätilasta Windowsin grafiikkakerroksen kautta.

Syventääksemme pysäytyskoodin ja sen parametrien yksityiskohtia, meillä on myös komento .bugcheck-tiedostojoka näyttää jälleen virheenkorjaustarkistuksen ja neljä argumenttia, mikä on hyödyllistä, jos haluamme toistaa tiedot suorittamatta kaikkea uudelleen. !analyze -v.

Käytännön tapauksia: ajurit ja tyypilliset konfliktit

BSOD-analyysi keskittyy tyypillisesti viallisten tai toimintahäiriöisten ajureiden , ajuriristiriitojen, virheellisen muistin käytön, IRP:iden (I/O-pyyntöpakettien) virheellisen käsittelyn ja niin edelleen tunnistamiseen. Tarkastellaan joitakin käytännön esimerkkejä tosielämän tapauksista prosessin ymmärtämiseksi paremmin.

RESOURCE_NOT_OWNED (0xE3) liittyy Teamsiin ja win32kbase.sys-tiedostoon

Windows 10 -skenaariossa, jossa useiden käyttöpäivien jälkeen ilmestyy BSOD, jossa on virhekoodi 0xE3 (RESOURCE_NOT_OWNED) , minikernel-vedos näyttää jotain vastaavaa:

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

Tässä debuggeri osoittaa, että virheenkorjaustarkistuksen laukaisee Teams.exe- tiedostoon liittyvä säie , mutta kriittisellä hetkellä pinossa oleva koodi kuuluu win32kbase.sys- tiedostolle , tarkemmin sanottuna DrvEnumDisplaySettings -funktiolle . Tämä ei välttämättä tarkoita, että Teams olisi suora syyllinen, vaan että Teams kutsuu käyttäjän API:a , joka aiheuttaa synkronointi- tai resurssien vapautusvirheen grafiikkajärjestelmässä.

Tällaisissa diagnooseissa päädytään usein siihen, että kyseessä on Windowsin grafiikkapinon virhe, tietty näytönohjain tai sovelluksen ja ohjainten välinen vuorovaikutus. Varsinainen ratkaisu voi sisältää näytönohjaimen ohjainten päivittämisen, Teamsin päivittämisen tai jopa tiettyjen Windows-korjausten asentamisen sen sijaan, että vain odotettaisiin, että vika korjaantuu itse.

DRIVER_IRQL_NOT_LESS_OR_EQUAL (0xD1) ja NotMyFault

Sysinternalsin NotMyFault- apuohjelma on koulutustyökalu, jonka avulla voit luoda ydinvirheitä hallitusti ja oppia analysoimaan kuvakaappauksia. Jos esimerkiksi käynnistät NotMyFaultista High IRQL -virheen (ydintila) ja napsautat "Tee virhe", pakotat DRIVER_IRQL_NOT_LESS_OR_EQUAL (0xD1) -virheen.

Sinisellä ruudulla näemme esimerkiksi DRIVER_IRQL_NOT_LESS_OR_EQUAL ja mahdollisesti sopivan ajurin (esimerkiksi MyFault.sys , työkalun käyttämä ajuri). Kun vedos on luotu ja avattu WinDbg:llä, alkuperäinen tuloste saattaa näyttää suunnilleen tältä:

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

Vaikka debuggeri viittaa muistin vioittumiseen , tiedämme, että todellinen syy liittyy NotMyFaultiin ja sen ajuriin. Tämän varmistamiseksi voimme jatkaa jäljitystä komennoilla, kuten !thread , nähdäksemme, mitä kutsuja säie tekee virheen sattuessa, ja !irp, analysoidaksemme kyseessä olevan IRP:n, jos virheentarkistus liittyy I/O-toimintoihin.

Esimerkiksi komennolla `!thread <dir_thread>` voimme nähdä säikeen pinonjäljen ja paikantaa käskyn, jossa `myfault+0x403` esiintyy , mikä osoittaa, missä testiajuri on mennyt pieleen. Sieltä voimme tutkia IRP:tä, muistin tilaa ja niin edelleen, aivan kuten tekisimme oikean virheen tapauksessa.

MULTIPLE_IRP_COMPLETE_REQUESTS (0x44) ja USB-ristiriidat

Toinen erittäin havainnollistava tapaus on bugcheck MULTIPLE_IRP_COMPLETE_REQUESTS (0x44)Tämä virhe ilmenee, kun IRP (I/O-pyyntöpaketti) suoritetaan useammin kuin kerran, yleensä siksi, että kaksi eri kuljettajaa uskoo omistavansa saman IRP:n ja molemmat soittavat IoCompleteRequest().

Analyysi komennolla !analyze -v saattaa tuottaa seuraavanlaisen kuvauksen:

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

Aluksi epäiltynä näyttää olevan usbehci.sys , Microsoftin USB EHCI -ohjainten ajuri. On kuitenkin suhteellisen harvinaista, että virheen aiheuttaisi Windowsin natiivi ajuri ilman kolmannen osapuolen toimia. Päästäksemme asiaan, käytämme virheenkorjaustarkistuksen tarjoamaa IRP-osoitetta (Arg1) ja suoritamme komennon !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

Viimeisellä rivillä näkyy selvästi merkkijono \Driver\usbehci ax88172 , joka paljastaa, että IRP on läpäissyt sekä usbehci.sys-tiedoston että ax88172.sys -nimisen ajurin , joka liittyy tiettyyn USB-verkkopiirisarjaan (AX88172). Tästä voidaan päätellä, että konflikti johtuu tästä kolmannen osapuolen USB-verkkokortin ajurista , ei Microsoftin yleisestä EHCI-ajurista.

Tässä tapauksessa ratkaisuun kuuluu USB-sovittimen ajurin päivittäminen, laitteen vaihtaminen tai tarvittaessa sen poistaminen . Tämän tyyppinen IRP-analyysi on erityisen hyödyllinen USB:hen, tallennustilaan, verkkokortteihin ja yleisesti ottaen kaikkiin intensiivistä I/O-tehoa käyttäviin komponentteihin liittyville BSOD-virheille.

Hyödyllisiä WinDbg-komentoja ydintilassa

!analyze -v- ja .bugcheck- komentojen lisäksi on olemassa useita WinDbg-laajennuksia ja -komentoja, jotka ovat erittäin hyödyllisiä, kun haluamme perehtyä tarkemmin kernel-tiedostojen kopiointiin.

Joitakin yleisimpiä ovat:

• !kierreNäyttää yksityiskohtaisia ​​tietoja säikeestä, mukaan lukien sen kutsupinon, tilan, liittyvät IRP:t jne. Sen avulla voit nähdä järjestelmän kaatuessa käynnissä olleen säikeen "viimeisimmät toiminnot".
• !prosessi 0 0Tämä listaa kaikki aktiiviset prosessit kaatumisen aikaan. Se on hyödyllinen sen tunnistamisessa, oliko koneella käynnissä epäilyttäviä prosesseja, palveluita, EDR:ää, virustorjuntaohjelmia jne.
• !irp: analysoi tietyn IRP:n ja näyttää kuljettajien jäljet, joiden läpi se on kulkenutI/O-komento, liput jne. ovat avainasemassa virheissä, jotka liittyvät MULTIPLE_IRP_COMPLETE_REQUESTS ja muita I/O-virheitä.
• !cpuinfo: tarjoaa tietoja prosessorista (valmistaja, MHz, allekirjoitukset, ominaisuudet), mikä on hyödyllistä laitteistoympäristöjen tarkistamisessa.
• !peb: näyttää PEB:n (Process Environment Block) tiedot, kuten tietokoneen nimen, Windowsin asennuspolun, prosessorien lukumäärän jne.
• !token: tarjoaa tietoja prosessin tai säikeen suojaustunnisteista, käyttöoikeuksista ja suojauskontekstista.
• .cls-tiedosto: tyhjentää komentoikkunan, kuten tavallisessa konsolissa.

Lisäksi monet tietyt tiedostojärjestelmälaajennukset (esim. PnP, NTFS jne.) mahdollistavat entistä enemmän tiedon poimimisen vedoksista. Joissakin tapauksissa WinDbg ilmoittaa BLACKBOX* -lohkojen (BLACKBOXBSD, BLACKBOXNTFS, BLACKBOXPNP, BLACKBOXWINLOGON) läsnäolosta. Nämä ovat virheenkorjauksen aikana tallennettuja lisätietolohkoja tiettyjen järjestelmäalueiden diagnosoinnin helpottamiseksi.

Ohjainverifikaattorin käyttäminen ongelmallisten ohjainten löytämiseen

Hyvin suuri osa Windowsin sinisen ruudun (BSOD) virheistä johtuu viallisista tai huonosti ohjelmoiduista ajureista . Järjestelmä sisältää tehokkaan työkalun näiden ongelmien ennakoivaan havaitsemiseen: Driver Verifier.

Ohjaintarkistin toimii reaaliajassa ja suorittaa valituille ajureille sarjan testejä ja rasitustestejä: se tarkistaa muistin oikean käytön, ytimen varannon käytön, IRQL:n, IRP:n jne. Jos se havaitsee ajurin toimivan virheellisesti, se voi pakottaa kontrolloidun BSOD:n, jotta voimme analysoida paljon selkeämmän vedoksen, jossa syyllinen on yleensä helppo tunnistaa.

Voit käynnistää Driver Verifier -hallinnan avaamalla komentokehotteen järjestelmänvalvojan oikeuksilla ja kirjoittamalla:

verifier

Sieltä voimme valita, mitkä ajurit haluamme tarkistaa. On viisasta olla varovainen: Verifier lisää järjestelmän kuormitusta ja voi heikentää suorituskykyä , joten on suositeltavaa ottaa käyttöön tarkistus vain mahdollisimman vähälle epäilyttäville ajureille sen sijaan, että valitaan kaikki summittaisesti.

Kun Verifier laukaisee BSOD:n havaitessaan virheellisen toiminnan, voimme analysoida ytimen vedoksen WinDbg:llä ja toivottavasti nähdä selvästi, mikä ajuri jäi kiinni ja mitä se teki väärin. Microsoftin Driver Verifieriä käsittelevät viiteartikkelit selittävät yksityiskohtaisesti eri vaihtoehdot ja käyttöstrategiat.

Käytännön neuvoja insinööreille ja teknikoille

Olitpa sitten ajurikehittäjä, ytimen kanssa työskentelevä ohjelmistokehittäjä tai yksinkertaisesti teknikko, joka vastaanottaa kaikki kuoleman siniset ruudut, on olemassa joitakin ohjeita, jotka kannattaa sisäistää, jotta et eksy BSOD-viidakkoon.

Ensimmäinen askel, kun virhe liittyy omaan koodiisi, on käyttää systemaattisesti kernel-virheenkorjaajaa ongelman toistamiseen ja analysointiin . Yhdistämällä virheenkorjaajan kohdekoneeseen (verkon, sarjaportin jne. kautta) virheenkorjaustarkistus pysäyttää järjestelmän virheenkorjaajan sisällä sen sijaan, että sininen ruutu näytettäisiin suoraan. Sieltä käsin voit tarkastella muistia, pinoja ja rakenteita sekä korjata koodia.

Toisissa tilanteissa virheenkorjaustarkistukset voivat johtua kolmannen osapuolen ajureista, laitteistosta tai ohjelmistoista , joita emme hallitse. Näissä tapauksissa tavoite siirtyy "koodin korjaamisesta" ongelman eristämiseen ja lieventämiseen.

• Tunnista epäilyttävä ohjain tai laitteistokomponentti WinDbg:n ja vedosanalyysin avulla.
• Päivitä tai palauta ohjainversiot, BIOS, laiteohjelmisto tai niihin liittyvät sovellukset.
• Poista tai vaihda USB-laitteet, näytönohjaimet, verkkosovittimet ristiriitainen.
• Nojata Tapahtumienvalvonta, Sysinternals, verkonvalvonta- ja analyysityökalut lisäkontekstia varten.

Monet näennäisesti mystiset ongelmat ratkaistaan ​​​​perusvianmääritysmenetelmillä : dokumentaation tarkastelulla, tiedostoversioiden ja päivämäärien tarkistamisella, keskeisten komponenttien uudelleenasentamisella tai ristiriitaisten moduulien poistamisella käytöstä. Vedoksen analysointi antaa meille selkeän suunnan siihen, mistä etsiä, ja usein säästää meiltä tuntikausia kokeilua ja erehdystä.

On myös tärkeää muistaa, että CrowdStrike Falcon -tapauksen ja muiden EDR-ongelmien kaltaisissa ympäristöissä yleisimmät kysymykset liittyvät siihen, mikä laukaisi kaatuneen virheilmoituksen (BSOD) ja miten se voidaan tunnistaa nopeasti . Kun WinDbg on määritetty oikein, symboleilla ja selkeällä menetelmällä vedosten avaamiseen ja analysointiin, voit rajata muutamassa minuutissa tilanteita, jotka muuten saattaisivat johtaa "alustukseen ja uudelleenasennukseen" ilman, että todellista syytä ymmärretään.

Lyhyesti sanottuna hyvän muistivedoskonfiguraation, työkalujen, kuten WinDbg:n, Driver Verifier:in ja Sysinternalsin, kurinalaisen käytön sekä lokien ja pinojen järjestelmällisen tarkastelun yhdistelmä muuttaa arvaamattoman vihollisen siniset ruudut erittäin tarkaksi tiedonlähteeksi siitä, mikä ytimessä on epäonnistunut , mikä auttaa meitä tekemään paljon tietoisempia teknisiä päätöksiä.