Kaip analizuoti Windows dump failus

Kas tie dump failai ir kodėl jie atsiranda jūsų kompiuteryje

Turbūt kiekvienas Windows vartotojas bent kartą yra matęs tą nemalonų mėlyną ekraną su klaidos pranešimu. Kai sistema užstringa ir nebegali normaliai funkcionuoti, Windows automatiškai sukuria specialų failą – dump’ą. Tai tarsi kompiuterio atminties nuotrauka tą kritinę akimirką, kai viskas nuėjo ne taip.

Dump failai yra neįkainojami, kai reikia suprasti, kas gi iš tikrųjų nutiko jūsų kompiuteriui. Juose saugoma informacija apie tai, kokios programos veikė, kokie tvarkyklių procesai buvo aktyvūs, kokia buvo sistemos būsena. Tai lyg juodoji dėžė lėktuve – po katastrofos ji padeda atskleisti įvykių eigą.

Paprastai šie failai atsiranda C:\Windows\Minidump arba C:\Windows\MEMORY.DMP kataloge. Minidump failai yra mažesni (paprastai 256-512 KB), o pilni atminties dump’ai gali užimti kelis gigabaitus – priklausomai nuo jūsų kompiuterio RAM kiekio.

Pasiruošimas analizei – reikalingi įrankiai

Norėdami analizuoti dump failus, jums reikės specialių įrankių. Pats populiariausias ir galingiausias yra WinDbg (Windows Debugger) – nemokama Microsoft programa, skirta būtent tokiai analizei. Taip, iš pradžių ji gali atrodyti bauginanti su savo tekstiniu interfeisu ir komandomis, bet nebijokite – pamažu viskas paaiškės.

Alternatyva pradedantiesiems yra BlueScreenView – daug paprastesnė programa su grafiniu interfeisu. Ji automatiškai nuskaito visus dump failus jūsų sistemoje ir pateikia informaciją suprantamesniu pavidalu. Tačiau jos galimybės ribotos – sudėtingesniais atvejais vis tiek reikės WinDbg.

Dar vienas naudingas įrankis – WhoCrashed. Ši programa automatiškai analizuoja dump failus ir pateikia išvadas žmogiškai suprantama kalba. Puikiai tinka tiems, kas nenori gilintis į technines detales, bet nori greitai suprasti problemos priežastį.

Prieš pradedant, įsitikinkite, kad turite administratoriaus teises. Dump failų analizė reikalauja prieigos prie sisteminių failų ir registrų, todėl be šių teisių toli nenueisit.

Pirmieji žingsniai su WinDbg

Kai įdiegsite WinDbg (dabar jis vadinamas WinDbg Preview ir prieinamas Microsoft Store), pirmiausia reikia sukonfigūruoti simbolių kelią. Simboliai – tai papildoma informacija, padedanti suprasti, kas vyksta dump faile. Be jų matysite tik sausas atminties adresus, o su jais – tikrus funkcijų pavadinimus ir tvarkyklių informaciją.

Simbolių kelią nustatykite taip: eikite į File → Symbol File Path ir įveskite:

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

Tai nurodys programai atsisiųsti reikalingus simbolius iš Microsoft serverio į jūsų kompiuterį. Pirmą kartą tai gali užtrukti, bet vėliau viskas veiks greičiau.

Dabar atidarykite dump failą per File → Open Crash Dump. Programa pradės automatinę analizę. Pamatysite daug teksto, bet nesijaudinkite – dauguma informacijos jums tikriausiai nereikalinga. Svarbiausias dalykas – paskutinės eilutės, kuriose bus nurodyta tikėtina klaidos priežastis.

Kaip skaityti analizės rezultatus

Kai WinDbg baigia pradinę analizę, jis automatiškai paleidžia komandą !analyze -v. Rezultate pamatysite daug informacijos, bet svarbiausi punktai yra šie:

BugCheck kодas – tai heksadecimalinis skaičius, identifikuojantis klaidos tipą. Pavyzdžiui, 0x0000007E reiškia SYSTEM_THREAD_EXCEPTION_NOT_HANDLED. Šį kodą galite ieškoti internete ir sužinoti, kokio tipo problema tai yra.

Probably caused by – čia programa nurodo, kas greičiausiai sukėlė problemą. Dažniausiai tai būna tvarkyklė (driver failas su .sys plėtiniu). Jei matote konkrečios tvarkyklės pavadinimą, tai puikus atspirties taškas.

Stack trace – tai funkcijų iškvietimų sąrašas, vedantis iki klaidos momento. Čia galite pamatyti, kokia funkcijų seka vedė prie problemos. Kartais tai atskleidžia, kad problema ne pačioje tvarkyklėje, o kaip ji sąveikauja su kitais sistemos komponentais.

Praktinis pavyzdys: jei matote, kad problema susijusi su nvlddmkm.sys, tai NVIDIA vaizdo plokštės tvarkyklė. Sprendimas paprastas – atnaujinkite arba perkraukite tvarkyklę.

Dažniausios problemos ir jų atpažinimas

Per daugelį metų dirbant su Windows sistemomis, tam tikri klaidos šablonai kartojasi vėl ir vėl. Štai keletas dažniausiai pasitaikančių situacijų:

Tvarkyklių konfliktai – tai absoliučiai dažniausia BSOD priežastis. Senos, nesuderinamos arba blogai parašytos tvarkyklės gali destabilizuoti visą sistemą. Ypač dažnai kaltos vaizdo plokščių, tinklo adapterių ir USB įrenginių tvarkyklės. Jei dump analizė nurodo konkrečią .sys failą, pirmiausia bandykite atnaujinti arba pašalinti tą tvarkyklę.

Aparatūros problemos – gedimas RAM atmintyje, perkaitęs procesorius arba miršta standžiojo disko dalis gali sukelti atsitiktinius užstrigimus. Tokiais atvejais dump failai dažnai rodo skirtingas klaidas, nes problema ne programinėje įrangoje, o fiziniame komponente. Jei matote įvairius BugCheck kodus skirtinguose dump’uose, verta patikrinti aparatūrą.

Atminties problemos – klaidos kodai kaip 0x0000001A (MEMORY_MANAGEMENT) arba 0x0000007F (UNEXPECTED_KERNEL_MODE_TRAP) dažnai rodo RAM problemas. Paleiskite Windows Memory Diagnostic įrankį arba Memtest86, kad patikrintumėte atmintį.

Віруси та шкідливі програми – nors rečiau, bet kenkėjiška programinė įranga gali modifikuoti sisteminius failus ir sukelti nestabilumą. Jei dump’e matote keistų pavadinimų tvarkykles arba procesus, verta patikrinti sistemą antivirusiniu skeneriu.

Praktiniai patarimai gilesnei analizei

Kai jau supratote pagrindus, galite naudoti papildomas WinDbg komandas, kurios atskleis daugiau informacijos:

!process 0 0 – parodo visus procesus, kurie veikė klaidos metu. Naudinga, kai įtariate, kad problema susijusi su konkrečia programa.

!vm – rodo virtualios atminties statistiką. Gali padėti nustatyti, ar sistema neturėjo pakankamai atminties.

!irql – parodo IRQL (Interrupt Request Level) informaciją. Tai svarbu analizuojant tvarkyklių problemas, nes daugelis BSOD įvyksta dėl neteisingų IRQL operacijų.

lm – išvardija visus įkeltus modulius (tvarkykles ir bibliotekas). Galite patikrinti, ar visos tvarkyklės yra tinkamų versijų.

Dar vienas naudingas triukas – palyginti kelis dump failus. Jei turite keletą užstrigimų, atidarykite kelis dump’us ir ieškokite bendrų vardiklių. Galbūt ta pati tvarkyklė minima visuose? Ar klaidos įvyksta panašiu laiku? Tokie šablonai padeda susiaurinti galimų priežasčių ratą.

Automatizuota analizė paprastesniems atvejams

Ne visi turi laiko ar noro mokytis WinDbg subtilybes. Todėl automatizuoti įrankiai gali būti tikras išgelbėjimas. BlueScreenView programa automatiškai nuskaito visus minidump failus ir pateikia lentelę su svarbiausiais duomenimis: klaidos kodu, tvarkyklėmis, kurios buvo atmintyje, ir tikėtina problemos priežastimi.

Programa spalvomis pažymi tvarkykles, kurios greičiausiai sukėlė problemą – raudonai pažymėtos yra įtariausios. Galite dukart spustelėti ant bet kurios tvarkyklės ir pamatyti išsamią informaciją apie ją: kelią, versiją, gamintoją.

WhoCrashed eina dar toliau – ji ne tik analizuoja dump failus, bet ir pateikia rekomendacijas. Pavyzdžiui, jei problema susijusi su konkrečia tvarkykle, programa pasiūlys ją atnaujinti ir net gali pateikti nuorodą į gamintojo svetainę.

Šie įrankiai puikiai tinka namų vartotojams, kurie nori greitai išspręsti problemą be gilaus techninio supratimo. Tačiau profesionalams ir sudėtingesniais atvejais WinDbg lieka nepakeičiamas.

Kada kreiptis į specialistus ir kaip pasiruošti

Kartais problema būna per sudėtinga išspręsti savarankiškai. Jei po kelių bandymų vis dar negalite nustatyti priežasties, arba problema kartojasi nepaisant visų jūsų pastangų, galbūt laikas kreiptis pagalbos.

Prieš kreipdamiesi į techninės pagalbos specialistus ar forumus, pasiruoškite:

– Surinkite kelis dump failus (jei turite)
– Užrašykite, kada problemos prasidėjo ir ar pastebėjote kokį nors šabloną
– Pažymėkite, kokius pakeitimus darėte sistemoje prieš prasidedant problemoms (naujų programų diegimas, Windows atnaujinimai, aparatūros keitimas)
– Padarykite pradinės analizės ekrano nuotrauką iš WinDbg arba BlueScreenView

Forumuose kaip TenForums, Reddit r/techsupport ar net Microsoft Community dažnai galite rasti pagalbos nemokamai. Tačiau būkite pasiruošę pateikti išsamią informaciją – niekas negali padėti, jei vienintelis jūsų aprašymas yra „kompiuteris užstrigo”.

Jei problema susijusi su aparatūra, gali prireikti profesionalios diagnostikos. Gedimas RAM, maitinimo bloke ar pagrindinėje plokštėje dažnai reikalauja fizinio komponentų testavimo, ko negalima padaryti tik programine analize.

Kai dump failai tampa jūsų sąjungininkais kovoje už stabilumą

Dump failų analizė iš pradžių gali atrodyti kaip raketų mokslas, bet iš tikrųjų tai tiesiog metodiškas požiūris į problemų sprendimą. Kiekvienas dump failas pasakoja istoriją apie tai, kas nutiko jūsų sistemai, ir su tinkamais įrankiais bei šiek tiek kantrybės galite tą istoriją perskaityti.

Pradėkite nuo paprastų įrankių kaip BlueScreenView – jie dažnai pakanka identifikuoti akivaizdžias problemas. Jei norite giliau suprasti sistemą arba susiduriate su sudėtingesnėmis problemomis, investuokite laiko į WinDbg mokymąsi. Tai įgūdis, kuris atsipirks ne kartą, ypač jei dirbate IT srityje.

Nepamirškite, kad dump failai – tai tik diagnostikos įrankis. Jie parodo, kas nutiko, bet ne visada kodėl. Kartais reikia derinti dump analizę su kitais metodais: aparatūros testavimu, sistemos žurnalų peržiūra, programinės įrangos konfliktų tikrinimu.

Ir paskutinis patarimas – reguliariai darykite sistemos atsargines kopijas. Net jei puikiai mokate analizuoti dump failus ir spręsti problemas, kartais paprasčiau ir greičiau atkurti sistemą iš atsarginės kopijos nei valandų valandas ieškoti retai pasitaikančios klaidos priežasties. Dump failų analizė – tai galingas įrankis, bet ne visada būtinas, jei turite gerą atsarginę kopiją.