swengjen Skrevet 4. desember 2010 Del Skrevet 4. desember 2010 Hei alle sammen, Trenger litt hjelp til å tolke minidump ved BSOD. BSOD oppstår ikke ved noen spesielle programmer, kan være alt fra gaming til OpenOffice. Hardware: - ASUS P7P55D-E - Intel Core i5 750 - OCZ DDR3 4 GB Value Memory Gold i5 1600MHz - HD 4870 GPU Tips noen? dump.txt Lenke til kommentar
fenderebest Skrevet 4. desember 2010 Del Skrevet 4. desember 2010 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
swengjen Skrevet 5. desember 2010 Forfatter Del Skrevet 5. desember 2010 Takk for hjelp så langt fenderebest! Prøver igjen. En liten tillegsopplysning: OS er 64-bit win7. dump2.txt Lenke til kommentar
fenderebest Skrevet 5. desember 2010 Del Skrevet 5. desember 2010 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. 1 Lenke til kommentar
fenderebest Skrevet 5. desember 2010 Del Skrevet 5. desember 2010 Om min forrige post var litt overvveldene: 1. Har du flere minidump filer, åpne de i WinDbg og post gjerne resultatet her. 2. Post gjerne minidump filene her slik at jeg kan kikke på dem. Lenke til kommentar
swengjen Skrevet 5. desember 2010 Forfatter Del Skrevet 5. desember 2010 Tror jeg var sånn halveis med på det du forklarte der! Veldig greit å vite litt om dette! 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
swengjen Skrevet 6. desember 2010 Forfatter Del Skrevet 6. desember 2010 Dobbeltsjekket her og hadde visst en dump til. Denne er visst fra 16. november. Fint om du kan ta en titt fenderebest (eller andre?)! dump3.txt Lenke til kommentar
fenderebest Skrevet 6. desember 2010 Del Skrevet 6. desember 2010 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
swengjen Skrevet 6. desember 2010 Forfatter Del Skrevet 6. desember 2010 Verifier-programmet du snakker om her er det det samme som "Application Verifier"? Får bare opp "Application Verifier" og "Application Verifier (x64)" av kjørbare programmer i win7. Lenke til kommentar
fenderebest Skrevet 6. desember 2010 Del Skrevet 6. desember 2010 Om du bruker kjør feltet (Windowstast + r) Og skriver inn verifier og trykker OK skal du få opp driver verifier. Lenke til kommentar
swengjen Skrevet 28. juli 2011 Forfatter Del Skrevet 28. juli 2011 I'm back - eller kanskje heller BSOD... ;-) Under spilling av BF3-trial fikk jeg BSOD som i vedlegg. Noen som klarer tyde noe fra dette? Ikke sikker på om det er samme feil som sist... dump4.txt Lenke til kommentar
Anbefalte innlegg
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 kontoLogg inn
Har du allerede en konto? Logg inn her.
Logg inn nå