Hvordan DU kan feilsøke Windows! (Guider)

fenderebest · 2. mars 2008

Hvordan feilsøke Windows:

Fra tid til annen vil man støte på problemer i Windows, dette kan være alt fra at operativsystemet oppleves tregt, til at det krasjer eller ikke gjør slik man vil. Den beste måten å løse disse problemene på er å gå systematisk til verks. Ved å se på symptomene og samle beviser vil man bestandig kunne finne en årsak og dermed løsningen til alle problemer. Jeg har valgt å skrive noen guider som viser hvordan man kan feilsøke noen av de vanligste problemer man støter på:

Feilsøking av oppstarten i Windows XP.

Feilsøking av drivere med driver verifier.

Feilsøking av blåskjermer

Hvordan feilsøke blåskjermer:

Den beste måten å feilsøke blåskjermer på er gjennom et program som heter WinDbg. Dette programmet kan åpne en type filer kalt krasjdumper og analysere disse for å fortelle hva som gikk galt. Under følger noen vanlige spørsmål som kan oppstå ved feilsøking med WinDbg.

Hva er en blåskjerm?

En blåskjerm henviser til skjermbildet som kommer opp når Windows krasjer:

Navnet får den fra den karakteristiske blåe bakgrunnen. Blåskjermer går også under navnet Blue Screen Of Death. (BSOD).

Hvorfor oppstår blåskjermer?

Blåskjermer i moderne Windows-versjoner oppstår når operativsystemet har oppdaget en alvorlig feil i kjernen av operativsystemet. Når feilen oppdages vil systemet stoppe helt opp og det blir tegnet en blåskjerm som gir en grunnleggende beskrivelse om hva som gikk galt. Grunnen til at systemet stopper opp er for å sikre at korrupte data ikke skrives til disk.

Hva forårsaker blåskjermer?

Statistikk tatt fra Microsofts Online Crash Analysis viser at 70% av alle blåskjermer oppstår pga tredjeparts-drivere, videre står maskinvare for 15% og Windows sin egen kode for 5% av alle feil. De resterende 15% er det ikke mulig å vise til noen sikker årsak. Man kan vertfall hente av dette at de fleste blåskjermer forårsakes som oftest av drivere.

Hva er en krasjdump?

Ved standard oppsett er Windows satt til å generere en krasjdump når en blåskjerm inntreffer. Denne inneholder en del (eller hele) porsjonen av minnet når feilen inntraff. Ved å se på minnet kan man finne ut hvilken tilstand datamaskinen var i og dermed avgjøre hvordan man løser problemet.

Hva er forskjellen på de forskjellige typene krasjdumper?

Windows deler minnet i to hoveddeler. Kjerneminne og brukerminne. I kjerneminnet kjører drivere til maskinvare og operativsystemet mens i brukerminnet kjører de vanlige programmene. Du har valget mellom å la Windows generere en kjerneminnedump, en minidump eller en fullstendig minnedump. Det er best å generere kjerneminnedumper da disse inneholder mest mulig nyttig informasjon. Minidump filer er veldig små og kan brukes til å sende til andre for videre feilsøking. De inneholder dessverre en god del mindre informasjon enn en kjerneminnedump. En fullstendig minnedump inneholder både kjerneminnet og brukerminnet og en fil vil være like stor som mengden RAM du har på datamaskinen. Har du 4gb ram vil du med andre ord få en 4gb fil. Som regel er det ikke nødvendig med fullstendige minnedumper og de er også upraktiske pga sin størrelse.

Hvordan setter jeg Windows opp for å generere krasjdumper?

Normalt sett skal Windows automatisk generere krasjdumper uten behov for noen videre konfigurasjon. Innstillingene gjøres ved å velge Systemegenskaper i Kontrollpanel og deretter velge fanen Avansert for så å trykke på knappen for Innstillinger innunder kategorien Oppstart og gjenoppretting:

Her er systemet konfigurert for å generere en kjerneminnedump.

Hvor finner jeg krasjdumpene?

Kjerneminnedumper finnes typisk i c:\windows\ mappen, mens minidumper finnes i c:\windows\minidump. Det kan være en fordel å kopiere ut filene til en annen mappe da Vista og Windows 7 gir brukere begrenset tilgang til disse mappene. Merk at c: er stasjonsbokstaven der hvor Windows er installert, har du installert Windows på d: blir mappene d:\windows\ osv.

Hvor finner jeg WinDbg?

Den nyste versjonen av WinDbg finnes bare ved å laste ned Windows SDK. Du kan derimot laste ned eldre versjoner av Debugging Tools for Windows. WinDbg er da en del av disse verktøyene.

32-bit versjonen finnes her.

64-bit versjonen finnes her.

Hvordan skal WinDbg settes opp?

WinDbg trenger symbolfiler for å fungere optimalt. Disse kan lastes ned fra Microsoft sin egen symbolserver. For å konfigurere symbolserveren må du først starte Windbg og deretter velge Symbol file path fra File menyen. Du skal deretter legge til følgende tekst:

srv*c:\symboler*http://msdl.microsoft.com/download/symbols; Hvor c:\symboler er mappen der symbolfilene blir lagret. (Dette kan du endre hvis du vil.) Deretter må du velge Image File Path fra File menyen og kopiere samme teksten inn der og velge ok. Windbg skal nå være ferdig konfigurert.

Feilsøking med WinDbg:

Den beste måten å feilsøke blåskjermer på er ved å feilsøke krasjdumper. Dette er fordi at disse inneholder mest mulig informasjon som beskriver problemer og det blir dermed enklere å finne en løsning. Sørg for at systemet er korrekt satt opp til å generere krasjdumper når blåskjermen inntreffer. Start deretter Windbg og velg ”Open crash dump” og henvis til plasseringen til der hvor krasjdumpen ligger. Det beste er å feilsøke på kjerneminnedumper om tilgjengelig.

Når filen er lastet vil Windbg laste ned nødvendige symboler, sørg derfor for at Windbg er korrekt konfigurert før du begynner feilsøkingen. Symbolfilene brukes for å gjøre informasjonen mer tolkbar og er derfor nødvendig om du skal få noe ut av krasjdumpene.

Når symbolfilene er ferdig nedlastet (noe som kan ta sin tid) er en grei begynnelse å skrive kommandoen ”!analyze –v” i kommandofeltet og trykke enter. Dette vil gi deg en beskrivelse om hva problemet er og hva som gikk galt. Blir teksten forvirrende kan du prøve å klippe og lime dette inn på forumet slik at andre kan se hva feilen var. Du kan også sende minidump filene til andre slik at de kan se på de. Om du har flere krasjdumpfiler kan det være en god ide å se på alle.

Slik skal det se ut etter du har kjørt !analyze -v

Endret 14. juli 2011 av fenderebest

snippsat · 2. mars 2008

Fin guide.

Historie.

http://en.wikipedia.org/wiki/Blue_Screen_of_Death

Ja har feilsøkt siden 3.1 på dette mener og huske at den var i 1.0 og hmm husker ikke

lenge side.

Kjenne jeg dette rett blir guiden litt lang for de fleste.

Hender jeg ber om minidump filer,så jeg kan se på dem.

De fleste gidder ikke sette seg inn i dette.

Sliter jo bare med og få stop coden.

En liten huskeliste jeg bruker og poste.

Kontrollpanel->system->avansert->oppstart og gjenoppretting->systemfeil

Fjern hake V "starte på nytt automatisk"

Liten minnedump (64kb)

%SystemRoot%\Minidump

Skriv ned stop code(post den)

Post SystemRoot minidumpfiler.(ikke alltid jeg ber om dette)

Litt om feilsøking stop coder.

http://aumha.org/a/stop.htm

Alltid få synder nr.1 en ut av bilde minne

Testes med memtest86+ 1.70

Råd jeg alltid gir.

Sett korrekt spenning og timings i bios.

Boot memtest86+ 1.70 kjøre en god stund kun 0 feil er ok.

http://www.ultimatebootcd.com/

Memtest86+ 1.70

Endret 2. mars 2008 av SNIPPSAT

fenderebest · 2. mars 2008

Ja, det er en lang guide men burde også besvare de fleste spørsmål angående grunnleggende analyse med Windbg. (La til en rask gjennomgang da) Jeg bare tok med mitt eksempel for å demonstrere at å google Stopcode i mange tilfeller ikke kan løse problemet. (De løsningene jeg har sett på nettet i diverse tilfeller har til tider vært absurde og misvisende.)

Og igjen er dette en ny-bygget pc som gir blåskjerm før du har installert drivere tilogmed er det selvsagt en fordel å gå over hardware og BIOS-konfig. Om man ser på statistikk fra Microsoft OCA (Online Crash Analysis) viser det seg faktisk at årsaken til blåskjermer er faktisk drivere i 70% av tilfellene, Hardware i 10%, i 15% av tilfellene var kræsjdumpen for korrupt for analysering og i kun 5% var det pga feil i Microsoft sin kode!

Så synder nr1. er faktisk Drivere! Ihvertfall på et system som har fungert.

Endret 2. mars 2008 av fenderebest

substeve · 2. mars 2008

Med noen screenshots blir denne en sticky.

fenderebest · 3. mars 2008

Hvordan feilsøke med Driver Verifier

Noen ganger henger Windows seg helt og svarer ikke engang på Ctrl+Alt+Delete, mens andre ganger får du blåskjermer som peker ut Windows-Komponenter som synderen eller rett og slett tilfeldige blåskjermer som ser ut til å ha lite til felles og er forholdvis uforutsigbare. Dette kan ofte være veldig vanskelig å feilsøke siden når feks systemet henger seg helt kan du ikke gjøre noe feilsøking heller og du får heller ikke noen kræsjdump å analysere.

En måte å feilsøke dette på er ved å bruke enten en Firewire eller Serie-kabel (Også USB2.0 i Vista) for å gjøre en såkalt Local Kernell Debugging. Men en enklere måte er å bruke verktøyet Driver Verifier som følger med Windows. Du starter Driver Verifer ved å trykke Windows-tast+R (Kjør) og skrive inn verifier og trykke enter, da vil du få opp et skjermbilde som dette:

Velg Opprett Egendefinerte Innstillinger (Som over) og trykk neste.

Velg som over og trykk neste.

I denne listen kan du da velge hvilke drivere du vil Driver Verifier skal kontrollere, du bør ikke velge mange drivere om gangen men ta det etappevis og velg drivere som ikke kommer fra Microsoft først og fremst. (Du har sikkert noen mistanker over hvilke drivere som kan være uheldige.)

Når du er fornøyd med valget av drivere trykker du fullfør. (Om du vil velge drivere som ikke er lastet inn trykker du på knappen for å legge dem til i listen.)

For at endringene skal bli aktivert må du restarte maskinen. Det driver verifier gjør nå med de driverne du har valgt er at den innfører ekstra feilkontroll på dem slik at med en gang de gjør noe galt vil Windows kræsje. Så prøv nå med driver verifier aktivert å gjør de tingene du vanligvis gjør og se om Windows låser seg.

En av de vanligste årsakene til at Windows henger seg helt er at det er to drivere som går i Vranglås(Det vil si at to drivere vil ha tilgang til samme ressurs og det ene venter på at den andre skal frigjøre ressursen og vice versa.) Og siden man nå har aktivert Oppdaging av vranglås vil Windows istedet for å henge seg nå kræsje og gi en blåskjerm du kan analysere med Windbg.

Da kan du enkelt åpne kræsjdumpen og analysere den med !analyze -hang for å få opp hvilke drivere som forårsaket vranglåsen og oppdatere eller eventuellt deaktivere dem.

Andre kræsj som ikke er relatert til såkalte Deadlocks (Vranglåser) Analyserer du bare som vanlig med !analyze -v

Når du er ferdig med å feilsøke driverne med Driver Verifier starter du bare Verifier fra kjør menyen igjen og velger Slett eksisterende innstillinger og deretter restart maskinen. Husk at å aktivere Driver Verifier på mange drivere om gangen vil ta opp fryktelig med ressureser og føre til unødig stabilitet så aktiver Driver Verifier for få drivere om gangen og slå av driver verifer når du skal bruke Windows Normalt.

En god sjekkliste er å gå gjennom grafikkdrivere,nettverkdrivere og lyddrivere hver for seg. Deretter å aktivere Driver Verifier for andre suspekte drivere og tilslutt for større grupper.

Som sagt...om det skulle være noe du lurer på er det bare å spørre! :-)

UPDATE

OS bygd på Server 2008 kjernen har forresten 3 nye tester for Driver Verfier disse er:

Security Checks-Sjekker at drivere setter sikker tilgang på objekter som interakterer med Programmer.

Force pending I/O requests-Tester om Drivere håndterer Asynkrone I/O operasjoner som blir ferdig med en gang på rett måte.

Miscellaneous checks-Sjekker om Drivere prøver å frigjøre ressurser allerede i bruk, ukorrekt bruk av WMI (Windows Management Instrumentation) og sjekker for ressurslekasjer.

Endret 4. april 2008 av fenderebest

fenderebest · 4. mars 2008

Hvordan feilsøke oppstarten i Windows XP

En siste guide over hvordan du kan feilsøke det mest vanlige problemene under oppstarten av Windows XP. Først og fremst bør du bestandig se til at harddisken din er ved fin form (Ved å kjøre feks chkdsk) og at du er sikker på at all BIOS-konfigurasjon er korrekt.

Feilmelding

Ugyldig Partisjonstabell.

Feil under lasting av operativsystem.

Manglende operativsystem.

Mulig årsak

Korrupt MBR (Master-Boot-Record)-Inneholder en boot kode og oversikt over aktive partisjoner.

Løsning

Kjør FIXMBR fra gjenopprettingskonsollet. (Dette skriver bare over boot koden og sjekker ikke at de aktive partisjonene er korrekte, du kan trenge et kraftigere MBR verktøy.)

Feilmelding

Lesefeil på disken.

NTLDR mangler.

NTLDR er komprimert.

Mulig årsak

Korrupt Boot-sektor.

Løsning

Kjør FIXBOOT fra gjenopprettingskonsollet.

Feilmelding

Could not read from selected boot disk

Check boot path and disk hardware

Windows could not start because of a computer disk hardware configuration problem

Melder ifra om at hal.dll eller ntorskrnl er manglende.

Mulig årsak

Enten korrupt,manglende eller feil oppsatt boot.ini

Løsning

Kjør bootcfg /rebuild fra gjenopprettingskonsollet.

Feilmelding

Melder fra at en systemfil er manglende.

Blåskjerm med stopkode 0xC0000135

Mulig årsak

En eller flere kritiske systemfiler er korrupte eller manglende.

Løsning

Om du da først har kjørt chkdsk og er sikker på at harddisken er i god form kan du kopiere over systemfiler fra enten Xp-CD-en eller en annen datamaskin. (Helst fra en annen datamaskin slik at du får en oppdatert versjon.)

Feilmelding

Windows kunne ikke stoppe fordi manglende fil er manglende eller korrupt \WINDOWS\SYSTEM32\CONFIG\SYSTEM

Mulig årsak

Registeret er skadet.

Løsning

Erstatt registerfilen med en gammel fra siste gjenopprettingspunkt. Disse finner du med å gå inn i Gjenopprettingskonsollen og gå til \System Volume Information og se etter en mappe som begynner med _restore. Deretter blar du frem til den mappen med det høyeste tallet etter RP. (Dette er da det nyeste Gjenopprettingspunktet) Se under Snapshot mappen her og kopier filen REGISTRY_MACHINE_SYSTEM over til der registret ligger (Altså: \WINDOWS\SYSTEM32\CONFIG. Deretter kan du lagre en backup av dem gamle registerfilen (Feks SYSTEM.BAK) og rename REGISTYRE_MACHINE_SYSTEM til SYSTEM.

Feilmelding

Blåskjerm under Windows xp "loade" skjermebildet.

Mulig årsak

Skyldes som oftest en driver.

Løsning

Prøv først LAST KNOWN GOOD fra F8 menyen i ntldr. Deretter kan du gå inn i gjenopprettingskonsollet for å deaktivere driveren manuelt og prøve å oppdatere den.

Gjenopprettingskonsollet

Du kan legge det inn på harddisken din manuelt men vanligvis vil det kun ligge på Windows XP installasjons CD-en. Om du starter fra denne CD-en kan du komme inn på Gjenopprettingskonsollet ved å velge å Starte fra cd, vente til driverne har blitt lastet inn og deretter trykke E for å komme inn i Gjenopprettingskonsollet.

Endret 16. april 2008 av fenderebest

odderling · 7. mars 2008

jeg har og blitt plaget av crasher nå i det siste men jeg har ikke innstalert noen nye drivere men jeg har vert plaget av crasher siden min pc ble satt sammen.

Så jeg tar bare å copy/paster det jeg fikk i command - dump jeg.

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - Instruksjonen i "0x%08lx" refererte til adresse "0x%08lx". Minnet kunne ikke v re "%s".

FAULTING_IP: 
win32k!PopAndFreeW32ThreadLock+15
bf802997 8b11			mov	 edx,dword ptr [ecx]

TRAP_FRAME:  b521bba4 -- (.trap 0xffffffffb521bba4)
ErrCode = 00000000
eax=e1047c28 ebx=00000000 ecx=00002000 edx=80000000 esi=e1047c28 edi=00000000
eip=bf802997 esp=b521bc18 ebp=b521bc18 iopl=0		 nv up ei pl nz na pe nc
cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000			 efl=00010206
win32k!PopAndFreeW32ThreadLock+0x15:
bf802997 8b11			mov	 edx,dword ptr [ecx]  ds:0023:00002000=????????
Resetting default scope

CUSTOMER_CRASH_COUNT:  3

DEFAULT_BUCKET_ID:  DRIVER_FAULT

BUGCHECK_STR:  0x8E

PROCESS_NAME:  explorer.exe

LAST_CONTROL_TRANSFER:  from bf820429 to bf802997

STACK_TEXT:  
b521bc18 bf820429 00002000 e1047c28 b521bc60 win32k!PopAndFreeW32ThreadLock+0x15
b521bc28 bf820207 e1047c28 893e6dc0 e1047c28 win32k!CleanupW32ThreadLocks+0x11
b521bc3c bf8209b0 8914fda8 00000000 00000000 win32k!DestroyThreadsObjects+0x25
b521bc60 bf819e30 00000001 b521bc88 bf819ef4 win32k!xxxDestroyThreadInfo+0x1cf
b521bc6c bf819ef4 8914fda8 00000001 00000000 win32k!UserThreadCallout+0x4b
b521bc88 805d0d38 8914fda8 00000001 8914fda8 win32k!W32pThreadCallout+0x3d
b521bd14 805d1150 00000000 00000000 8914fda8 nt!PspExitThread+0x3cc
b521bd34 805d1490 8914fda8 00000000 b521bd64 nt!PspTerminateThreadByPointer+0x52
b521bd54 8054086c 00000000 00000000 0164ffb4 nt!NtTerminateThread+0x70
b521bd54 7c90eb94 00000000 00000000 0164ffb4 nt!KiFastCallEntry+0xfc
WARNING: Frame IP not in any known module. Following frames may be wrong.
0164ffb4 00000000 00000000 00000000 00000000 0x7c90eb94


STACK_COMMAND:  kb

FOLLOWUP_IP: 
win32k!PopAndFreeW32ThreadLock+15
bf802997 8b11			mov	 edx,dword ptr [ecx]

SYMBOL_STACK_INDEX:  0

SYMBOL_NAME:  win32k!PopAndFreeW32ThreadLock+15

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: win32k

IMAGE_NAME:  win32k.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  45f013f6

FAILURE_BUCKET_ID:  0x8E_win32k!PopAndFreeW32ThreadLock+15

BUCKET_ID:  0x8E_win32k!PopAndFreeW32ThreadLock+15

Followup: MachineOwner
---------

fenderebest · 7. mars 2008

Hei! Har du noen tredje-parts programvare for å logge på eksternt med?

odderling · 7. mars 2008

ja, jeg har www.logmein.com frogramvare innstalert og der er det mulighet for innloging!

Har to andre dump filer i C:\WINDOWS\Minidump mappen også.

fenderebest · 7. mars 2008

Gir disse forskjellige feilmeldinger fra hver gang?

En rask gjennomgang av den minidumpen du sendte inn gir meg grunn til å mistenke nettopp et slikt program! Kan du prøve å enten deaktivere eller avinstallere det og se om problemet forsvinner?

odderling · 7. mars 2008

Om det kan være til hjelp så klikker fire fox stadig nå (slik ca 2-3 ganger i minuttet) skal prøve å avinstallere nå, så får se. skal jeg poste de to andre crash dumpene?

fenderebest · 7. mars 2008

Vel er de forskjellig fra den første? Du kan se om det virker som det fungerer bedre nå også kan du poste de to andre etterpå!

snippsat · 7. mars 2008

Nå som denne guiden er blitt sticky.

Vil jeg annbefale og be dem med problemer og lage en ny post.

Viss du skal legge til mere kommer dette mitt inni posten.

En moderator kan vel rydde opp litt viss du ber om det.

Endret 7. mars 2008 av SNIPPSAT

odderling · 7. mars 2008

ok, kommer og plager deg sikkert mere i morgen. men fire fox klikker fremdeles, kllikket faktisk tre ganger på å bare skrive denne kommentaren.

Endret 8. mars 2008 av odderling

fenderebest · 7. mars 2008

Yep, er enig burde egentlig ha fått en moderator til å flytte disse beskjedene som ikke har direkte med feilsøking og gjøre og så låse den!

odderling · 8. mars 2008

Jeg har rotet littt rundt i debuging programet og jeg ser at det står tre forskjellige "probably caused" programer.

Dump 1

Klikk for å se/fjerne innholdet nedenfor

<Microsoft ® Windows Debugger Version 6.8.0004.0 X86

Loading Dump File [C:\WINDOWS\Minidump\Mini030508-02.dmp]

Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: srv*c:\symbols*http://msdl.microsoft.com/downloads/symbols

Executable search path is: srv*c:\symbols*http://msdl.microsoft.com/downloads/symbols

Windows XP Kernel Version 2600 (Service Pack 2) MP (4 procs) Free x86 compatible

Product: WinNt, suite: TerminalServer SingleUserTS

Built by: 2600.xpsp_sp2_gdr.070227-2254

Kernel base = 0x804d7000 PsLoadedModuleList = 0x8055c700

Debug session time: Wed Mar 5 18:55:05.531 2008 (GMT+1)

System Uptime: 0 days 0:05:15.172

Loading Kernel Symbols

..........................................................................................

...................................................

Loading User Symbols

Loading unloaded module list

.........

*******************************************************************************

* *

* Bugcheck Analysis *

* *

*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 1000008E, {c0000005, 80545d11, b4a5b858, 0}

Probably caused by : win32k.sys ( win32k!RBRUSH::vRemoveRef+e )

Followup: MachineOwner

---------

3: kd> !analyze -v

*******************************************************************************

* *

* Bugcheck Analysis *

* *

*******************************************************************************

KERNEL_MODE_EXCEPTION_NOT_HANDLED_M (1000008e)

This is a very common bugcheck. Usually the exception address pinpoints

the driver/function that caused the problem. Always note this address

as well as the link date of the driver/image that contains this address.

Some common problems are exception code 0x80000003. This means a hard

coded breakpoint or assertion was hit, but this system was booted

/NODEBUG. This is not supposed to happen as developers should never have

hardcoded breakpoints in retail code, but ...

If this happens, make sure a debugger gets connected, and the

system is booted /DEBUG. This will let us see why this breakpoint is

happening.

Arguments:

Arg1: c0000005, The exception code that was not handled

Arg2: 80545d11, The address that the exception occurred at

Arg3: b4a5b858, Trap Frame

Arg4: 00000000

Debugging Details:

------------------

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - Instruksjonen i "0x%08lx" refererte til adresse "0x%08lx". Minnet kunne ikke v re "%s".

FAULTING_IP:

nt!__InterlockedDecrement+5

80545d11 f00fc101 lock xadd dword ptr [ecx],eax

TRAP_FRAME: b4a5b858 -- (.trap 0xffffffffb4a5b858)

ErrCode = 00000002

eax=ffffffff ebx=00000001 ecx=00002000 edx=dd280005 esi=00002000 edi=88011431

eip=80545d11 esp=b4a5b8cc ebp=b4a5b8d4 iopl=0 nv up ei pl nz na pe nc

cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010206

nt!__InterlockedDecrement+0x5:

80545d11 f00fc101 lock xadd dword ptr [ecx],eax ds:0023:00002000=????????

Resetting default scope

CUSTOMER_CRASH_COUNT: 2

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0x8E

PROCESS_NAME: firefox.exe

LAST_CONTROL_TRANSFER: from bf8079c2 to 80545d11

STACK_TEXT:

b4a5b8c8 bf8079c2 e6dc2538 b4a5b8f4 bf8093d2 nt!__InterlockedDecrement+0x5

b4a5b8d4 bf8093d2 00000001 b4a5b908 bf809427 win32k!RBRUSH::vRemoveRef+0xe

b4a5b8e0 bf809427 88011431 0000ffff 00000000 win32k!EBRUSHOBJ::vNuke+0x13

b4a5b8f4 bf80d2b3 00000000 00000000 bf80fafb win32k!XDCOBJ::bDeleteDC+0x4e

b4a5b90c bf80fb4c e25e0008 00000000 00000000 win32k!bDeleteDCInternal+0x134

b4a5b928 8054086c 88011431 0012f618 7c90eb94 win32k!NtGdiDeleteObjectApp+0x88

b4a5b928 7c90eb94 88011431 0012f618 7c90eb94 nt!KiFastCallEntry+0xfc

WARNING: Frame IP not in any known module. Following frames may be wrong.

0012f618 00000000 00000000 00000000 00000000 0x7c90eb94

STACK_COMMAND: kb

FOLLOWUP_IP:

win32k!RBRUSH::vRemoveRef+e

bf8079c2 85c0 test eax,eax

SYMBOL_STACK_INDEX: 1

SYMBOL_NAME: win32k!RBRUSH::vRemoveRef+e

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: win32k

IMAGE_NAME: win32k.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 45f013f6

FAILURE_BUCKET_ID: 0x8E_win32k!RBRUSH::vRemoveRef+e

BUCKET_ID: 0x8E_win32k!RBRUSH::vRemoveRef+e

Followup: MachineOwner

--------->

Dump 2

Klikk for å se/fjerne innholdet nedenfor

<

Microsoft ® Windows Debugger Version 6.8.0004.0 X86

Loading Dump File [C:\WINDOWS\Minidump\Mini030508-03.dmp]

Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: srv*c:\symbols*http://msdl.microsoft.com/downloads/symbols

Executable search path is: srv*c:\symbols*http://msdl.microsoft.com/downloads/symbols

Windows XP Kernel Version 2600 (Service Pack 2) MP (4 procs) Free x86 compatible

Product: WinNt, suite: TerminalServer SingleUserTS

Built by: 2600.xpsp_sp2_gdr.070227-2254

Kernel base = 0x804d7000 PsLoadedModuleList = 0x8055c700

Debug session time: Wed Mar 5 18:57:50.140 2008 (GMT+1)

System Uptime: 0 days 0:01:53.796

Loading Kernel Symbols

..........................................................................................

.................................................

Loading User Symbols

Loading unloaded module list

...........

*******************************************************************************

* *

* Bugcheck Analysis *

* *

*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 1000008E, {c0000005, bf802997, b521bba4, 0}

Probably caused by : win32k.sys ( win32k!PopAndFreeW32ThreadLock+15 )

Followup: MachineOwner

---------

0: kd> !analyze -v

*******************************************************************************

* *

* Bugcheck Analysis *

* *

*******************************************************************************

KERNEL_MODE_EXCEPTION_NOT_HANDLED_M (1000008e)

This is a very common bugcheck. Usually the exception address pinpoints

the driver/function that caused the problem. Always note this address

as well as the link date of the driver/image that contains this address.

Some common problems are exception code 0x80000003. This means a hard

coded breakpoint or assertion was hit, but this system was booted

/NODEBUG. This is not supposed to happen as developers should never have

hardcoded breakpoints in retail code, but ...

If this happens, make sure a debugger gets connected, and the

system is booted /DEBUG. This will let us see why this breakpoint is

happening.

Arguments:

Arg1: c0000005, The exception code that was not handled

Arg2: bf802997, The address that the exception occurred at

Arg3: b521bba4, Trap Frame

Arg4: 00000000

Debugging Details:

------------------

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - Instruksjonen i "0x%08lx" refererte til adresse "0x%08lx". Minnet kunne ikke v re "%s".

FAULTING_IP:

win32k!PopAndFreeW32ThreadLock+15

bf802997 8b11 mov edx,dword ptr [ecx]

TRAP_FRAME: b521bba4 -- (.trap 0xffffffffb521bba4)

ErrCode = 00000000

eax=e1047c28 ebx=00000000 ecx=00002000 edx=80000000 esi=e1047c28 edi=00000000

eip=bf802997 esp=b521bc18 ebp=b521bc18 iopl=0 nv up ei pl nz na pe nc

cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010206

win32k!PopAndFreeW32ThreadLock+0x15:

bf802997 8b11 mov edx,dword ptr [ecx] ds:0023:00002000=????????

Resetting default scope

CUSTOMER_CRASH_COUNT: 3

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0x8E

PROCESS_NAME: explorer.exe

LAST_CONTROL_TRANSFER: from bf820429 to bf802997

STACK_TEXT:

b521bc18 bf820429 00002000 e1047c28 b521bc60 win32k!PopAndFreeW32ThreadLock+0x15

b521bc28 bf820207 e1047c28 893e6dc0 e1047c28 win32k!CleanupW32ThreadLocks+0x11

b521bc3c bf8209b0 8914fda8 00000000 00000000 win32k!DestroyThreadsObjects+0x25

b521bc60 bf819e30 00000001 b521bc88 bf819ef4 win32k!xxxDestroyThreadInfo+0x1cf

b521bc6c bf819ef4 8914fda8 00000001 00000000 win32k!UserThreadCallout+0x4b

b521bc88 805d0d38 8914fda8 00000001 8914fda8 win32k!W32pThreadCallout+0x3d

b521bd14 805d1150 00000000 00000000 8914fda8 nt!PspExitThread+0x3cc

b521bd34 805d1490 8914fda8 00000000 b521bd64 nt!PspTerminateThreadByPointer+0x52

b521bd54 8054086c 00000000 00000000 0164ffb4 nt!NtTerminateThread+0x70

b521bd54 7c90eb94 00000000 00000000 0164ffb4 nt!KiFastCallEntry+0xfc

WARNING: Frame IP not in any known module. Following frames may be wrong.

0164ffb4 00000000 00000000 00000000 00000000 0x7c90eb94

STACK_COMMAND: kb

FOLLOWUP_IP:

win32k!PopAndFreeW32ThreadLock+15

bf802997 8b11 mov edx,dword ptr [ecx]

SYMBOL_STACK_INDEX: 0

SYMBOL_NAME: win32k!PopAndFreeW32ThreadLock+15

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: win32k

IMAGE_NAME: win32k.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 45f013f6

FAILURE_BUCKET_ID: 0x8E_win32k!PopAndFreeW32ThreadLock+15

BUCKET_ID: 0x8E_win32k!PopAndFreeW32ThreadLock+15

Followup: MachineOwner

--------->

Dump 3

Klikk for å se/fjerne innholdet nedenfor

Microsoft ® Windows Debugger Version 6.8.0004.0 X86

Loading Dump File [C:\WINDOWS\Minidump\Mini030708-01.dmp]

Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: srv*c:\symbols*http://msdl.microsoft.com/downloads/symbols

Executable search path is: srv*c:\symbols*http://msdl.microsoft.com/downloads/symbols

Windows XP Kernel Version 2600 (Service Pack 2) MP (4 procs) Free x86 compatible

Product: WinNt

Built by: 2600.xpsp_sp2_gdr.070227-2254

Kernel base = 0x804d7000 PsLoadedModuleList = 0x8055c700

Debug session time: Fri Mar 7 22:14:10.875 2008 (GMT+1)

System Uptime: 0 days 0:43:45.875

Loading Kernel Symbols

..........................................................................................

....................................................

Loading User Symbols

Loading unloaded module list

............

*******************************************************************************

* *

* Bugcheck Analysis *

* *

*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck A, {2000, 2, 1, 806e4a2a}

Unable to load image JGOGO.sys, Win32 error 0n2

*** WARNING: Unable to verify timestamp for JGOGO.sys

*** ERROR: Module load completed but symbols could not be loaded for JGOGO.sys

Probably caused by : afd.sys ( afd!AfdFastIoDeviceControl+5bd )

Followup: MachineOwner

---------

0: kd> !analyze -v

*******************************************************************************

* *

* Bugcheck Analysis *

* *

*******************************************************************************

IRQL_NOT_LESS_OR_EQUAL (a)

An attempt was made to access a pageable (or completely invalid) address at an

interrupt request level (IRQL) that is too high. This is usually

caused by drivers using improper addresses.

If a kernel debugger is available get the stack backtrace.

Arguments:

Arg1: 00002000, memory referenced

Arg2: 00000002, IRQL

Arg3: 00000001, bitfield :

bit 0 : value 0 = read operation, 1 = write operation

bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)

Arg4: 806e4a2a, address which referenced memory

Debugging Details:

------------------

WRITE_ADDRESS: 00002000

CURRENT_IRQL: 2

FAULTING_IP:

hal!KeAcquireInStackQueuedSpinLock+3a

806e4a2a 8902 mov dword ptr [edx],eax

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0xA

TRAP_FRAME: b5853a40 -- (.trap 0xffffffffb5853a40)

ErrCode = 00000002

eax=b5853ac4 ebx=b5853b1c ecx=8912c6cd edx=00002000 esi=8912c6b0 edi=00000000

eip=806e4a2a esp=b5853ab4 ebp=b5853b10 iopl=0 nv up ei ng nz na po nc

cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010282

hal!KeAcquireInStackQueuedSpinLock+0x3a:

806e4a2a 8902 mov dword ptr [edx],eax ds:0023:00002000=????????

Resetting default scope

LAST_CONTROL_TRANSFER: from 806e4a2a to 80543930

STACK_TEXT:

b5853a40 806e4a2a badb0d00 00002000 00000000 nt!KiTrap0E+0x238

b5853b40 80534a4d 0019cc10 80560ec0 00000110 hal!KeAcquireInStackQueuedSpinLock+0x3a

b5853b10 b73cebc4 00001000 00a5f0dc b73cebc4 nt!ExReleaseResourceLite+0x8d

b5853c5c 8057f1fd 891cf418 00000001 00a5f010 afd!AfdFastIoDeviceControl+0x5bd

b5853d00 805780c2 000000f4 000000ec 00000000 nt!IopXxxControlFile+0x255

b5853d34 8054086c 000000f4 000000ec 00000000 nt!NtDeviceIoControlFile+0x2a

b5853d34 7c90eb94 000000f4 000000ec 00000000 nt!KiFastCallEntry+0xfc

WARNING: Frame IP not in any known module. Following frames may be wrong.

00a5f06c 00000000 00000000 00000000 00000000 0x7c90eb94

STACK_COMMAND: kb

FOLLOWUP_IP:

afd!AfdFastIoDeviceControl+5bd

b73cebc4 e955fdffff jmp afd!AfdFastIoDeviceControl+0xaf (b73ce91e)

SYMBOL_STACK_INDEX: 3

SYMBOL_NAME: afd!AfdFastIoDeviceControl+5bd

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: afd

IMAGE_NAME: afd.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 41107eb5

FAILURE_BUCKET_ID: 0xA_W_afd!AfdFastIoDeviceControl+5bd

BUCKET_ID: 0xA_W_afd!AfdFastIoDeviceControl+5bd