Blåskjerm og "kernel data inpage", feilmelding! Trenger hjelp?

[Hrodebert]

Husk å være nøye med å plassere innlegg og tråder i korrekt kategori. Spør en moderator om du er i tvil. Denne tråden var feilpostet og er blitt flyttet til korrekt eller mer passende kategori.

 

Eventuelle reaksjoner på moderering skal gjøres via "Personlig Melding".

 

[hawa]

Nå er jeg tilbake, og det fungerete desverre ikke. Fikk den samme blåmeldingen. Har du noen andre ideer?

[fenderebest]

Vel 0xC000009D, or STATUS_DEVICE_NOT_CONNECTED, indicates defective or loose cabling, termination, or that the controller does not see the hard disk.

 

Så om man ser bort ifra dette, er alle drivere og slikt installert? Er ingen enheter med spørsmålstegn i enhetsbehandling?

 

Er dette en laptop eller en stasjonær forresten?

Endret 17. juni 2009 av fenderebest

[hawa]

Oi, oppe sent du Har stasjonær pc.

 

Gikk inn på enhetsbehandling og prøvde og oppdatere harddisken min men den var "up to date".

I dette siste forsøket ved å starte fra hvile/sovemodus så fikk jeg jo se skrivebodet før blåskjermen kom Er jo en liten progressjon.

 

Men jeg kan ikke skjønne at det bare skjer når jeg skal vekke pcen når jeg ikke har noen andre problemer ellers.

 

Kan det være SP2 eller noen annen hardware som får windows til å ikke finne harddisken min?

Eller bare at harddisken er for treg til å starte opp så windows gir opp med å finne den før den har startet?

 

Her er den siste dump filen fra i kveld.

Mini061809_01.zip

Endret 18. juni 2009 av hawa

[fenderebest]

Hei, er desverre litt opptatt nå, skal oppdatere den posten når jeg har tid.

[fenderebest]

Ok jeg gikk litt grundigere igjennom Minidump filen din idag, det var samme feilen men la oss se litt på stakken:

 

STACK_TEXT:

fffffa60`01bcd1f8 fffff800`020634c4 : 00000000`0000007a fffff6fd`30005f60 ffffffff`c000009d 00000000`bc134860 : nt!KeBugCheckEx

fffffa60`01bcd200 fffff800`020c2901 : fffffa80`043f7420 fffffa60`01bcd340 fffff800`02214240 00000000`00000000 : nt! ?? ::FNODOBFM::`string'+0x1cf99

fffffa60`01bcd2c0 fffff800`020bfea4 : fffffa80`023439c0 fffffa60`00b833a4 fffffa80`036af720 fffffa60`00b83924 : nt!MiDispatchFault+0xac1

fffffa60`01bcd420 fffff800`020a7fd9 : 00000000`00000008 00000000`00000000 00000000`00060000 fffffa80`046a9b80 : nt!MmAccessFault+0x7f4

fffffa60`01bcd500 fffffa60`00bec0ab : fffffa80`00000000 fffffa80`00000000 fffffa80`08965700 fffffa80`047a8900 : nt!KiPageFault+0x119

fffffa60`01bcd690 fffffa60`00be9616 : 00000000`00000000 fffffa80`046a5e00 00000000`00000000 fffffa80`046a5e00 : pci!PciScanBusCompletion+0x163

fffffa60`01bcd7e0 fffffa60`00bd3aaa : fffffa80`08965740 fffffa80`08965858 fffffa80`08965740 fffff800`02159a60 : pci!PciBus_QueryDeviceRelations+0x1ca

fffffa60`01bcd830 fffff800`023e2211 : fffffa80`08965740 fffffa80`054811d0 fffffa80`046a5cb0 fffff800`0239322c : pci!PciDispatchPnpPower+0xda

fffffa60`01bcd870 fffff800`023e4970 : 00000000`00000000 fffff800`02159a60 fffffa80`047a89e0 fffff800`0239d850 : nt!PnpAsynchronousCall+0xd1

fffffa60`01bcd8b0 fffff800`0242bd80 : fffffa80`047a8540 fffffa80`047a8540 00000000`00000002 fffffa80`0366b760 : nt!PnpQueryDeviceRelations+0xd0

fffffa60`01bcd960 fffff800`0248479c : fffffa80`047a8540 fffffa80`0366b760 fffffa80`0366b760 00000000`00000002 : nt!PipEnumerateDevice+0x120

fffffa60`01bcd9c0 fffff800`02484d3a : 00000000`00700198 fffffa80`065fc1a0 00000000`00000000 fffff800`022a3ee1 : nt!PipProcessDevNodeTree+0x21c

fffffa60`01bcdc30 fffff800`0217ce3d : fffff801`00000003 fffffa80`043d4aa0 00000000`00000000 00000000`00000000 : nt!PiProcessReenumeration+0x8a

fffffa60`01bcdc80 fffff800`020b08c3 : fffff800`0217cc10 fffff800`021e0801 fffff800`021e08f8 00000000`00000000 : nt!PnpDeviceActionWorker+0x22d

fffffa60`01bcdcf0 fffff800`022b3f37 : fffff800`022475c0 00000000`00000020 fffffa80`036af720 00000000`00000080 : nt!ExpWorkerThread+0xfb

fffffa60`01bcdd50 fffff800`020e6616 : fffffa60`01963180 fffffa80`036af720 fffffa60`0196cd40 fffffa80`036b0ca8 : nt!PspSystemThreadStartup+0x57

fffffa60`01bcdd80 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiStartSystemThread+0x16

 

Den virker logisk og om man følger funksjonene på stakken kan man se at denne tråden er opprettet for å gi beskjed til enheter på PCI-bussen om å slå på strømmen, men midt oppi det hele treffer en av funksjonene på en sidevekslingsfeil:

 

pci!PciScanBusCompletion+0x163:

fffffa60`00bec0ab 0000 add byte ptr [rax],al ds:ea00:00000000`00000000=??

 

Dette er instruksjonen som feilet og her referer den faktisk en nullpeker. Dog gir Windbg oss beskjed om at noen registre kan være inkorrekte så verdien i rax kan være inkorrekt.

 

Dog har prosessorerne et spesielt kontroll register, CR2 som lagrer den addressen som programmet forsøkte å aksessere ved en sidevekslingsfeil, la oss derfor se hva som ligger i CR2:

 

3: kd> r cr2

cr2=0000000002aadfe8

 

Som er en helt annen addresse enn den i fant i rax, det er rimelig å tro at den korrekte verdien til rax ligger i CR2. Men selv denne addressen virker ikke logsik da denne referer til et område i User mode og det ville vært rimelig uvanlig, vi kan nok derfor konkludere med at denne addressen er feil og at det var derfor sidevekslingsfeilen inntraff.

 

Den vanlige måten å håndtere en sidevekslingsfeil på er først å lete i sidevekslingsfilen for så å lese inn dataen fra disk om den finner addressen. Dog om den inntreffer en sidevekslingsfeil i det systemet som skal "vekke" disken opp fra sovemodus ville ikke systemet kunne håndtere en sidevekslingsfeil selv om addressen var gyldig da disken fremdeles "sov"

 

Dermed er det rimelig at en sidevekslingsfeil på dette stadiet burde ikke forekomme og både det at addressen den vil lese fra er ulogisk og at den ikke er å finne i minne får meg til å mistenke at minnet har blitt korrupt.

 

Minnekorrupsjon kan både skyldes drivere og maskinvare men siden dette bare inntreffer når man skal vekke datamaskinen fra sovemodus vil jeg først og fremst mistenke en driver. Man kan feks tenke seg at en driver har en dårlig strømhåndteringsrutine som først blir aktivert når maskinen går i sovemodus og deretter vil den gjøre minnet korrupt som til sist gjør at når man vekker maskinen igjen vil maskinen krasje.

 

Jeg vil derfor først og fremst mistenke en Plug and Play driver, så en mulig metode er å bruke Driver Verifer med spesialutvalg på mistenkelige drivere. Men bare for å støtte opp litt om teorien min før man begynner med Driver Verifier kunne jeg tenke meg til at det første man kan prøve er å skje om problemet gjentar seg i sikkermodus.

[hawa]

Skal sjekke opp dette når jeg kommer hjem i dag.

 

En venn fortalte meg nå at det ikke er mulig og sove i sikkermodus.

Endret 18. juni 2009 av hawa

[fenderebest]

Nei det stemmer forøvrig det, beklager. Nei da er det vel bare å gå rett på Driver Verifier med en gang. Jeg har skrevet om Driver Verifier her

 

Er ikke nødvendig å lese alt som står der, under valgene skal du bare velge "Spesialutvalg" og deretter velge ut 10 mistenkelige drivere i Driver Verifer og teste ut om du får en ny type blåskjerm. Deretter fortsetter du med de 10 neste drivere, husk først og fremst Plug and Play drivere som kommer fra en tredjepart.

 

Bare kort ned tiden til å sette i Ventemoudus til 1 minutt da kan du teste dette raskere.

Du er ute etter en blåskjerm som ikke er av typen 7A.

 

Du må forøvrig restarte maskinen etter du har aktivert Driver Verifier før valgene du har gjort tar effekt.

Endret 18. juni 2009 av fenderebest

[hawa]

JA, er litt opptatt i dag så skal gjøre dette i kveld. Oppdaterer posten før midnatt.

 

Hmm, dette blir litt utsatt - vil gjøre det i morgen eller noe. Oppdateres når jeg har fått tid til å bli ferdig

 

Fikk også høre noe fra noen venner om at Lydkort kan ha problemer med sovemodus? Kan det ha noe med saken og gjøre eller?

 

Kom til denne delen hvor jeg ble litt redd for å trykke noe feil. Hva skal jeg egentlig gjøre her?

Endret 18. juni 2009 av hawa