Der er intet, der er mere frustrerende. Det ene øjeblik arbejder du på din pc, og det næste bliver skærmen blå, og systemet genstarter og ødelægger alt det arbejde, der ikke er blevet gemt. Og en time efter sker det igen. Hvad foregår der?

Hvis man skal diagnosticere nedbrud, må man vide, hvad der udløser dem. Men forvent ikke, at Windows kommer til hjælp. Hvis man for eksempel går til »Problemrapporter og løsninger« i Vista, får man typisk ubrugelige beskrivelser som: »Windows lukkede pludselig ned.« Ja, ok. Tusind tak.

Heldigvis findes der et gratis alternativ: Microsofts debugger WinDbg. Peg ned i retning af det seneste nedbrud, så nævner det den fil, dll eller driver, der sandsynligvis stod bag.

Det opregner alt andet, der kørte; advarer dig mod potentielle hukommelseslæk og leverer nyttig information til fejlfinding og diagnosticering. Hvis din pc er ustabil, findes der ikke noget bedre værktøj til at finde årsagen.

Diagnosticering af nedbrud begynder med selve skærmmeddelelsen. Den kan somme tider afsløre den fil, sandsynligvis står bag nedbruddet.

Konfigurer WinDbg

Microsoft gør sit bedste for at gemme Win-Dbg. Du skal downloade et Windows Driver Kit ISO-image (www.bit.ly/98g9Uo), der fylder hele 619MB, og brænde det på en cd. Start KitSetup. Nu får du en liste over de forskellige muligheder for driverudvikling. Vælg boksen »Debugging Tools for Windows« og klik »OK».

Hvis WinDbg skal virke ordentligt, skal det kunne downloade »symboler«: Filer, der hjælper debuggeren med at konvertere rå, binær information til de funktions- og variabelnavne, som bliver brugt af Windowskomponenter.

Dem kan man gemme lokalt, og det er en god ide, for så skal man kun downloade dem en gang. Opret en folder til dem – noget i retning af »C:\Windows\Symbols« vil være ideelt.

Nu skal du fortælle programmet, hvor dets symboler kan findes og gemmes. Klik »Start«, skriv WinDbg og klik på linket »WinDbg.exe« for at starte debuggeren. Klik »File | Symbol File Path« for at se den aktuelle sti.

Så skriver du en sti som »SRV*c:windows\symbols*http://msdl.microsoft.com/download/symbols« i boksen, hvor »c:\windows\symbols« bliver erstattet af stien til din egen lokale symbolmappe.

Klik »OK«, luk programmet og klik »Yes«, når du bliver spurgt, om du vil gemme information til arbejdsområdet – det gemmer den sti, du netop har skrevet.

Det er vigtigt at tjekke, om Windows er konfigureret til at oprette hukommelses-dumpfiler, når din pc gør ned, fordi WinDbg skal bruge dem til at finde ud af, hvad der skete på det tidspunkt. ¨

Det ordner du ved at klikke »Start«, højreklikke »Computer« og vælge »Properties | Advanced system settings | Startup and Recovery Settings«. Sørg for, at der er krydset af i boksen »Write an event to the system log«, så Windows indsamler oplysninger om dine nedbrud.

Dernæst rydder du boksen »Automatically restart«, så du får mulighed for at læse eventuelle fejlmeddelelser, og vælger »Kernel memory dump« i listen »Write debugging information« for at sikre, at Windows gemmer alle disse hukommelsesblokke, hvis det går ned.

Noter dumpfilens navn – den er sandsynligvis »Memory.dmp«. Det er den dumpfil, du senere skal finde. Til sidst slutter du af ved at klikke »OK«.

Opret en rapport

Når WinDbg er sat op, er det overraskende nemt at bruge på et grundlæggende niveau, og alle og enhver kan bruge det til at få oplysninger om sit systemes seneste udforklarlige nedbrud. Prøv det selv ved at klikke »Start«, skrive WinDbg og klikke på »WinDbg«-linket. Klik »File | Open Crash Dump« og gå til din seneste dumpfil. Den ligger sikkert i »\Windows\Memory.dmp, selv om du måske har flere filer liggende i »\Windows\Minidump».

Klik »Open« og vent, mens filen bliver analyseret. Det kan tage et stykke tid – fem minutter eller mere – afhængig af dumpfilens kompleksitet og din pc’s hastighed. Vær tålmodig.

Åbn din dumpfil, så identificerer Windows Debugging Tools den fil, der måske udløste nedbruddet.

På bunden af skærmbilledet kommer der en prompt: »0 : kd>«, når det er gjort, og nu kan du scanne resten af rapporten for at se, hvad den byder på.

Typisk vil du ved rapportens slutning se en linje i retning af »Probably caused by : driver.sys«, idet »driver.sys« bliver erstattet af navnet på den fil, som WinDbg mistænker for at stå bag nedbruddet. Perfekt.

Hvis du ikke genkender navnet, kan du google det, eventuelt med ekstra nøgleord som blue screen. Du finder straks applikationen bag ustabiliteten foruden løsninger på problemet.

Nedbrud med blå skærm kan imidlertid være komplicerede, fordi den fil, der udløste nedbruddet ikke nødvendigvis er den, der er skyld i dine problemer. Det lyder sært, men se sådan på det:

Hvis en fejlbehæftet driver giver Windows en ukorrekt hukommelseslokation, kan den blive ført videre til flere andre Windowskomponenter. En af dem kan prøve at få adgang til hukommelsen og dermed udløse et nedbrud i den fil – men det egentlige problem ligger hos driveren.

Hvis WinDbg udpeger nogle centrale Windowskomponenter eller en anden applikation, som virker udmærket, kan det være sådan et problem. Du skal igennem lidt mere granskning for at finde ud af, hvad der egentlig sker.

Grav lidt dybere

Scan din WinDbg-rapport igen og led efter linjer, der er fremhævet med »** ERROR«, og som klager over, at »symbols could not be loaded« for en bestemt fil.

Hvis du har konfigureret WinDbg korrekt, vil det kunne indlæse symboler uden problemer. Så ved du, at det må være tredjeparts-drivere, der var aktive på tidspunktet for nedbruddet.

Alt, hvad der bliver fremhævet således, er en mulig synder. Igen skal du lede på nettet efter filnavnet, og du finder måske andre nedbrudsrapporter. Hvis det ikke giver noget resultat, skal du klikke i kommandolinjen i bunden af WinDbg-vinduet og skrive !analyze –v (v står for »verbose«, der betyder ordrig) og trykke »Enter« for at få en mere detaljeret analyse af din nedbrudsfil.

Den ordrige rapport er fuld af udviklersnak med masser af tal, pointers og udviklingsrelateret jargon, men du behøver ikke at forstå det hele. Vælg blot de dele, der giver flere oplysninger.

Du får sikkert en fejlmeddelelse, der nævner grunden til nedbruddet. I en af vores test sagde den første rapport simpelthen, at nedbruddet sikkert var udløst af nvlddmkm.sys.

Den ordrige rapport forklarede, at nedbruddet skete, da et forsøg på at resette skærmdriveren og vende tilbage efter timeout slog fejl. Det er langt mere specifikt og anvende- ligt. Hvis du kommer ud for noget lignende, kan du installere de seneste driveropdateringer til din skærmdriver. Det løser måske problemet.

Den ordrige rapport kan også indeholde oplysninger om stakken, altså en liste over de funktioner, der blev kaldt af Windows og din software umiddelbart før nedbruddet.

Det ser kompliceret ud, og det er det også. Men man behøver ikke at forstå hvert ord. Alt, hvad du skal gøre, er at finde ud af, hvad pc’en lavede, da nedbruddet skete, og stakken kan give meget nyttige oplysninger (se boksen »Læs stakken«).

Undersøg dit system

Hvis standardrapporten og den ordrige rapport ikke kan forklare dine nedbrud, bør du se nærmere på din pc’s konfiguration på tidspunktet for nedbruddet.

Skriv !vm og tryk »Enter«. Så får du omfattende oplysninger om for eksempel systemets hukommelsesbrug. Led efter særheder i rapporten. Er der for eksempel en advarsel om »excessive usage« ved »paged pool« eller »non-paged pool«? Det kan betyde, at du har en ressourcelæk et sted, måske en driver, der tildeler Windowsressourcer uden at frigive dem igen.

Er din sidefil tæt på den maksimale størrelse? Hvis det sker, kan det også skyldes en ressourcelæk, eller du har måske manuelt givet den størrelse, der er mindre end nødvendigt.

Til sidst er der under den generelle rapport en liste over Windowskomponenter og den ram, de brugte ved tidspunktet for nedbruddet. Er der noget, der virker usædvanligt?

Process-kommandoen kan også være nyttig, for den viser de systemprocesser, der kørte ved tidspunktet for nedbruddet. Skriv !process 0 0 (det er nuller) og tryk »Enter« for at se den komplette liste. Led efter HandleCount-tallet her.

Det viser, hvor mange Windowsobjekter en proces har åbnet. Det er normalt nogle få hundrede, måske et par tusinde i nogle tilfælde, men hvis det er mange tusinde, uden at der er en indlysende årsag – det er for eksempel ikke et antivirusprogram, der scanner hele systemet – kan det betyde, at der er et problem.

Windows’ logbog omfatter somme tider fejlmeddelelser, der forklarer problemer. Start den ved at køre »eventvwr« fra en kommandolinje.

Hvis du vil se den dybdeborende rapport om, hvilke processer der var i hukommelsen, da din pc gik ned, skriver du lmv og trykker »Enter«. Denne kommando er en forkortelse for »Loaded Modules Verbose«, og rapporten giver dig en lang liste over programmer, drivere og Windowskomponenter, der var aktive ved tidspunktet for nedbruddet.

Bladr gennem listen, og du vil finde mange drivere, som du ikke anede, at du havde. På vores test-pc fandt vi for eksempel drivere, der var installeret af HWiNFO32, VMware, VirtualBox, Paragon Partition Manager, forskellige sikkerhedsværktøjer og andet.

Hvis du have tilsvarende tredjepartsdrivere på din pc, er det fint. Men hvis du finder noget, der relaterer til applikationer, som du ikke længere bruger, er det en god ide at afinstallere dem. Der er ingen garanti for, at det stopper dine nedbrud, men du frigør nogle systemressourcer og forenkler systemet, og det er altid et godt skridt fremad.

Den måske vigtigste pointe er ikke at give op. Nedbrudsanalyse er kompliceret, og WinDbg kan ikke altid hjælpe, men du bør alligevel grave videre. Sandsynligvis får du inden længe oplysninger, der kan få din pc til at køre glat igen.

Sådan skal du gøre... læs stakken

Åbn en dumpfil i WinDbg, skriv kommandoen k og tryk »Enter«. Så kan du se stakken, der er en liste over de programfunktioner, der blev kaldt lige før nedbruddet. Disse aktiviteter kan give dig oplysninger om den generelle grund til dine nedbrud.

Den ældste funktion på stakken er ved bunden. Begynd der og læs opad. Hver linje har to hukommelsesrelaterede værdier, efterfulgt af et funktionsnavn såsom: »0000000000000000 nt!KiThreadStartup+0x16«.

Glem tallene – det er funktionsnavnet, der tæller. I dette tilfælde betyder »nt« før udråbstegnet, at det er en Windows-kernefunktion, og »KiThreadStartup« betyder, at den starter en tråd. Du har ganske givet andre funktionsnavne i din stak, men medmindre de er meget uklare, skal du ikke bruge for lang tid på at google dem.

Der er mange NTFS-kald i stakken, og det fortæller os, at systemet brugte harddisken kort før nedbruddet.

Du behøver kun finde ud af, hvad din pc lavede, da den gik ned.Hvis de fleste af navnene begynder med »dxgkrnl!-et eller andet-«, er de DirectX Graphics Kernel-funktioner. Det betyder, at din pc var i gang med noget videorelateret, da den gik ned, og videodriveren kan være årsagen.

Hvis en funktion begynder med »tcpip!«, er den netværksrelateret, »ntfs!« henfører til filsystemet og så videre.Den aktivitet, du finder, er måske ikke årsagen til nedbruddet, men den kan give stof til eftertanke.

Sådan skal du gøre... diagnosticer låste og hængende applikationer

WinDbg er ikke kun til fejlfinding ved nedbrud. Det kan også give nyttige oplysninger om regulære applikationsnedbrud og hængende programmer.

Hvis et program er låst, skal du trykke [Ctrl]+[Shift]+[Esc] for at starte »Joblisten«. Klik på knappen »Programmer«, højreklik på den applikation, der hænger, og vælg »Opret dump-fil«. Det virker kun i Windows Vista og 7, ikke i XP.

Du kan manuelt oprette en dumpfil for enhver kørende applikation med et par klik. Det kan hjælpe med at diagnosticere problemet.

Efter et øjeblik eller to fortæller Joblisten dig, hvor på systemet den har oprettet filen (det er som regel et sted under »\Brugere\[Brugernavn]\AppData\Local«). Start WinDbg, klik »File | Open Crash Dump« og åbn den fil med kommandoen !analyze –hang –v for at få flere oplysninger om problemet.

Du kan bruge de andre WinDbg-kommandoer, vi har beskrevet her, men applikationsdumps indeholder andre oplysninger end regulære nedbruds-dumpfiler, og resultaterne er ikke altid lige så klare. Du får for eksempel højst sandsynligt ikke nøjagtige hukommelsesoplysninger fra kommandoen »VM«.

Forskellene betyder, at du bør være omhyggelig med, hvordan du tolker dumprapporterne.

Sådan skal du gøre... tjek dine drivere

Driver Verifier er et meget nyttigt værktøj til at stressteste dine drivere. Hvis nogen af dem har fejl, går de sandsynligvis ned under testen, og den fejlbehæftede driver burde kunne ses tydeligt i WinDbg.Start »Verifier.exe«, accepter funktionen »Create Standard Settings« og vælg »Automatically select unsigned drivers«. Gennemgå resten af wizarden, klik »Finish« og genstart.

Nu tester Verifier din pc, men du kan hjælpe med ved at køre nogle krævende applikationer, for eksempel et spil (men ikke noget for seriøst. Vi prøver at få pc’en til at gå ned. Lad være med at indlæse arbejdsfiler).

Driver Verifier kan hurtigt identificere fejlbehæftede drivere, men pas på – den får sandsynligvis din pc til at gå ned undervejs.

Lad det køre en times tid. Hvis der kommer et nedbrud med blå skærm, genstarter du pc’en, åbner du den nye dumpfil i WinDbg, finder ud af, hvilken driver der gik ned, og prøver at opdatere eller fjerne den.

Uanset om det virker eller ej, skal du huske at lukke Driver Verifier, når du er færdig. Start »Verifier.exe«, vælg »Delete Existing Settings« og klik »Finish« for at stoppe testene. Eller, hvis Driver Verifier får din pc til at gå ned under boot, trykker du »F8« for at boote i fejlsikret tilstand. Start programmet som før og slet dets indstillinger for at boote normalt igen.

Hent nye drivere

En enkel strategi til at håndtere blå skærme og fejlmeddelelser fungerer sådan: Åbn en dumpfil og skriv kommandoen lmv for at opregne alle de indlæste moduler. Det omfatter et tidsstempel. Lav en liste over de ældste tre drivere, der ikke er del af operativsystemet, opdater dem og se, om det hjælper.

Brug arbejds-områder

WinDbg spørger som standard, om det skal gemme information til et arbejdsområde. Det betyder, at det gemmer dine aktuelle indstillinger, og når du første gang skriver symbolstien, er det afgørende.

Ellers vil vi anbefale dig at klikke at klikke »No«. Det sikrer, at programmet bruger sine standardindstillinger, hvilket sikkert er det bedste til mindre øvede WinDbg-brugere.

Hvis du begynder at bruge WinDbg meget, kan det være klogt at lære, hvordan arbejdsområder kan hjælpe. Blogging NT Debugging har en detaljeret postering, der forklarer alt det, man kan finde på www.bit.ly/99yPCU.

Hent nye drivere

Opret dumpfiler

Hvis Windows ikke opretter dumpfiler, skal du højreklikke på »Computer«, klikke på »Properties | Avancerede systemindstillinger | Ydelsesindstillinger | Avanceret | Skift« og sikre dig, at sidefilen er slået til og indstillet til »Systemadministreret størrelse«. Det er nødvendigt, fordi Windows kan få brug for en sidefil til at skrive en dumpfil.

Find dårlige drivere

Fejlbehæftede drivere er de hyppigste årsager til blå skærme. Men hvilke? Start Signature Verifier (»sigverif.exe« og klik »Start« for at se en liste over ikkesignerede systemfiler. Led efter drivere – det er dem med efternavnet ».sys« – og google filnavnene. Find ud af, hvad de er og fjern eller opdater de associerede applikationer for at se, om det hjælper.