Gå til innhold
Trenger du hjelp med PCen? Still spørsmål her! ×

Hjelp til tolkning av minidump ved BSOD


Anbefalte innlegg

Videoannonse
Annonse

Det er ikke satt riktige symboler i WinDbg.

 

Symboler er viktige for å kunne tolke minidumpfiler.

 

Du setter symboler ved å:

 

1.Starte WinDbg.

 

2.Trypp på File menyen og velg Symbol file path...

 

3.Sett denne til srv*"Symbolbane"*http://msdl.microsoft.com/downloads/symbols hvor "Symbolbane" er plassen hvor symbolene blir lagret lokalt til disk. Trykk deretter OK.

 

4.Trykk på File menyen igjen og velg Image file path...

 

5.Sett denne til srv*"Symbolbane"*http://msdl.microsoft.com/downloads/symbols hvor "Symbolbane" er plassen hvor symbolene blir lagret lokalt til disk. Trykk deretter OK.

 

6.Du kan nå åpne minidump filen og skriv deretter !analyze -v for å få opp en analyse av dump filen. Post så denne analysen inn her.

Lenke til kommentar

Hmm la meg forklare litt om hvordan man "tolker" minidump filer.

 

Som du sikkert vet har alle datamaskiner en prosessor, prosessorens oppgave er å utføre operasjoner på vegne av programmer. Disse operasjonene "kjøres" i et objekt kalt tråder. Alle prosesser som kjører på datamaskinen din har minst en tråd, og har man har flere prosessorer kan flere tråder kjøres samtidig. (En for hver prosessor eller prosessorkjerne.)

 

Det blir da slik at operasjonene har flere ledd, skal du feks lese fra en fil fra harddisken må du gå gjennom flere "ledd" før operasjonen er utført. Disse "leddene" blir organisert i en datastruktur kalt en stakk(STACK). Det er slik at hver tråd som kjører på datamaskinen vil ha sin egen stakk. (Litt forenkelet sagt egentlig, hver tråd har 2 stakker, en for kernel mode og en annen for user mode...men det er rimelig irrelevant)

 

Det mest interessante i minidump filene er derfor stakken, da disse inneholder informasjon om hva datamaskinen drev på med da maskinen krasjet. Om du tar en titt på stakken i din minidump-fil har du:

 

STACK_TEXT:

fffff880`08372588 fffff800`02b0ea39 : 00000000`0000001e ffffffff`c0000005 00000000`0000033e 00000000`00000008 : nt!KeBugCheckEx

fffff880`08372590 fffff800`02ad3d82 : fffff880`08372d58 00000000`0000033e fffff880`08372e00 fffff960`001603c5 : nt!KiDispatchException+0x1b9

fffff880`08372c20 fffff800`02ad28fa : 00000000`00000008 00000000`0000033e fffff880`08372f00 fffff960`00203861 : nt!KiExceptionDispatch+0xc2

fffff880`08372e00 00000000`0000033e : 00000000`0000033e 00000000`24448944 00000215`00000001 fffff880`08372ff0 : nt!KiPageFault+0x23a

fffff880`08372f90 00000000`0000033e : 00000000`24448944 00000215`00000001 fffff880`08372ff0 00000000`00000001 : 0x33e

fffff880`08372f98 00000000`24448944 : 00000215`00000001 fffff880`08372ff0 00000000`00000001 00000000`00000000 : 0x33e

fffff880`08372fa0 00000215`00000001 : fffff880`08372ff0 00000000`00000001 00000000`00000000 00000000`00000001 : 0x24448944

fffff880`08372fa8 fffff880`08372ff0 : 00000000`00000001 00000000`00000000 00000000`00000001 00000000`00000000 : 0x215`00000001

fffff880`08372fb0 00000000`00000001 : 00000000`00000000 00000000`00000001 00000000`00000000 00000000`00000200 : 0xfffff880`08372ff0

fffff880`08372fb8 00000000`00000000 : 00000000`00000001 00000000`00000000 00000000`00000200 fffff900`c08248b0 : 0x1

 

Alle tallene er egentlig irrelevant (Forenklet sagt igjen, tallene kan være nyttige) , det er den lesbare teksten som beskriver operasjonen som er mest relevant.

 

Den første operasjonen ligger nederst i stakken (altså operasjon 0x1). Den siste operasjonen som ble utført ligger øverst i stakken (altså operasjon nt!KeBugCheckEx). Om man bare tar med den lesbare teksten får man:

 

nt!KeBugCheckEx

nt!KiDispatchException+0x1b9

nt!KiExceptionDispatch+0xc2

nt!KiPageFault+0x23a

 

Man leser en stakk fra bunn til topp så dermed får man at datamaskinen møtte på en sidevekslingsfeil (nt!KiPageFault+0x23a), som betyr at data ikke finnes i RAM, noe som vanligvis ikke er en kritisk feil da den normalt sett bare leser inn dataen fra disk. De neste operasjonene prøver å behandle feilen, men feiler selv:

nt!KiDispatchException+0x1b9

nt!KiExceptionDispatch+0xc2

 

Det som skjer da er at Windows "Bug Checker" noe som betyr at Windows vil vise en Blåskjerm eller BSOD om du vil:

nt!KeBugCheckEx

 

Dette er egentlig ikke relevant for problemet, for problemet eksisterte lenge før operasjonen nt!KiPageFault+0x23a ble utført. Desverre er stakken korrupt som man kan se av at operasjonene før nt!KiPageFault+0x23a ikke er lesbare, feks er den første operasjonen 0x1 noe som ikke gir mening. Skal man finne ut av problemet må man finne ut hva datamaskinen drev på med FØR KiPageFault ble kjørt.

 

Så hvordan gjør man dette? Vel, om datamaskinen har krasjet flere ganger kan du prøve å sammenligne de andre minidump filene og se om de gir mer informasjon, eller man kan prøve å se om man kan rekonstruere stakken manuelt, (av og til er ikke stakken virkelig korrupt, det er bare WinDbg som har problemer med å konstruere den) Dette kan derimot være vanskelig å gjøre uten erfaring, så du kan jo begynne med å gå over de andre minidump filene først.

  • Liker 1
Lenke til kommentar

Tror jeg var sånn halveis med på det du forklarte der! Veldig greit å vite litt om dette! :thumbup:

 

Av en eller annen grunn har jeg ikke flere minidumper. Er vel kanskje en uke eller to siden jeg hadde BSOD sist, men de slettes vel kanskje etter en stund...

 

Jeg poster en ny når det oppstår.

Lenke til kommentar

Stakken er igjen ulesbar:

 

 

STACK_TEXT:

fffff880`077f1758 fffff800`02b123b3 : 00000000`0000001a 00000000`00041284 fffff900`c5cc3001 00000000`00000d92 : nt!KeBugCheckEx

fffff880`077f1760 fffff800`02a62fbe : 00000000`00000d92 fffffa80`02736060 00000000`00000000 fffffa80`03b9eb60 : nt! ?? ::FNODOBFM::`string'+0x4a83

fffff880`077f17a0 fffff800`02e6d260 : fffff900`c5cc3000 fffff880`000003fd fffffa80`03c906d0 00000000`00000000 : nt! ?? ::FNODOBFM::`string'+0x2df20

fffff880`077f18f0 fffff800`02e6d333 : fffff900`c2320020 00000000`00000002 00000000`00000006 00000000`00000002 : nt!MiRemoveFromSystemSpace+0x1d0

fffff880`077f1950 fffff960`0074264f : 00000000`00000001 00000000`00000000 00000000`64646344 00000000`64646344 : nt!MmUnmapViewInSystemSpace+0x73

fffff880`077f1980 00000000`00000001 : 00000000`00000000 00000000`64646344 00000000`64646344 ffffffff`fffd73b1 : cdd+0x264f

fffff880`077f1988 00000000`00000000 : 00000000`64646344 00000000`64646344 ffffffff`fffd73b1 fffff960`00745e31 : 0x1

 

At den er ulesbar på akkurat samme viset får meg til å mistenke at det er en driver som forårsaker problemer. Det ville være svært uvanlig om hardware greide å gjøre minnet korrupt på akkurat samme vis. Det beste jeg kommer på er å kjøre Driver Verifier mot suspekte drivere. Problemet med korrupsjon er at minnet kan ha vært korrupt i lang tid før maskinen krasjet, så det kan være vanskelig å spore tilbake til hvem som gjorde minnet korrupt.

 

Man aktiverer driver verifier ved å kjøre verifier fra kjør-feltet.

 

Velg Opprett egendefinerte innstillinger. Trykk Neste

Velg indiviudelle innstillinger fra en liste. Trykk Neste

Huk av for Spesialutvalg og Utvalgssporing. Trykk Neste

Velg drivernavn fra en liste. Trykk Neste.

 

Velg ut mistenkelige drivere fra en tredjepart (Altså ikke Microsoft) Trykk Fullfør og restart maskinen.

 

Nå vil Windows utføre ekstra kontroll på hvordan drivere bruker minnet. Om Driver Verifier oppdager noe galt vil maskinen krasje med blåskjerm. Merk at dette kan gjøre at Windows krasjer med en gang og ikke starter opp skikkelig, da velger du bare bruk siste fungerende innstillinger fra oppstartsmenyen.

Lenke til kommentar
  • 7 måneder senere...

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
×
×
  • Opprett ny...