Komplet guide til analyse af BSOD'er og kerneldumps i Windows

Informatec Digital » Ressourcer » Komplet guide til analyse af BSOD'er og kerneldumps i Windows

Når en Windows-computer fryser med en blå skærm, er det ikke bare irriterende: der er ofte værdifuld information gemt i hukommelsesdumpen , der fortæller os præcis, hvad der skete i kernen. I stedet for at give RAM'en, BIOS'en eller den øjeblikkelige omformatering skylden, er det værd at lære at læse disse data.

Med lidt øvelse giver værktøjer som WinDbg og funktioner som !analyze -v, .bugcheck eller korrekt brug af symboler os mulighed for at gå fra "Jeg får en blå skærmfejl" til "Jeg ved, hvilken driver, ressource eller enhed der forårsagede BSOD'en." I denne artikel vil vi trin for trin og i detaljer gennemgå, hvordan man analyserer en BSOD ved hjælp af dens kerneldump, hvilke typer dumps der findes, hvordan man forbereder alt, og hvilke kommandoer der skal bruges for at få mest muligt ud af analysen.

Hvad er en BSOD, og ​​hvilke oplysninger indeholder den?

Når Windows støder på en tilstand, der kompromitterer systemintegriteten og ikke kan gendannes sikkert, foretager den et internt kernekald kaldet KeBugCheckEx . Dette kald er det, der udløser den berygtede Blue Screen of Death (BSOD).

KeBugCheckEx modtager altid fem argumenter: en STOP-kode (bugcheck-kode) og fire yderligere parametre , der giver teknisk kontekst til fejlen. Det er disse samme data, vi derefter kan konsultere.

• På den blå skærm klassisk, hvis systemet ikke er konfigureret til at genstarte automatisk.
• I Windows-hændelsesloggen, i Logbogen (systemlog).
• I hukommelsesdumpfilen (minidump, kerneldump eller fuld dump), ved hjælp af WinDbg og kommandoer som !analyze -v o .bugcheck.

Hver fejltjekkode har et symbolsk navn og en tilhørende hexadecimal værdi . For eksempel har fejltjekket DRIVER_POWER_STATE_FAILURE koden 0x9F , mens RESOURCE_NOT_OWNED svarer til 0xE3 . Disse koder og deres parametre er dokumenteret i Microsofts fejltjekkodereference, som du altid bør have ved hånden.

Ud over koden kan den blå skærm vise navnet på en potentielt involveret .sys-driver . Hvis det er en tredjepartsdriver (antivirus, netværkskort, grafikkort osv.), har vi ofte en klar mistænkt. Hvis en generisk systemkomponent (ntoskrnl.exe, win32k.sys osv.) vises, eller hvis der slet ikke vises noget, skal vi udføre en hukommelsesdump og bruge WinDbg til at undersøge det nærmere.

Typer af hukommelsesdumps i Windows

For at kunne analysere en BSOD i dybden, skal Windows generere en hukommelsesdumpfil (DMP), når fejlen opstår. Denne fil registrerer systemets tilstand på fejltidspunktet og kan være af forskellige typer.

I indstillingerne "Start og gendannelse" (højreklik på "Denne pc / Denne computer" → Egenskaber → Avancerede systemindstillinger → fanen "Avanceret" → knappen "Indstillinger" under "Start og gendannelse") kan du vælge mellem flere typer dumps. Hver af dem har sine fordele og ulemper.

Lille hukommelsesdump (minidump)

Minidump - formatet er det mindste (omkring 64 KB) og også det mest begrænsede til avanceret fejlfinding. Det er dog stadig nyttigt til at opnå en hurtig diagnose i mange BSOD-scenarier.

En minidump lagrer blandt andet data:

• Stopmeddelelsen, bugcheck-koden og dens parametre.
• Processorkonteksten (PRCB) for den processor, der forårsagede fejlen.
• Oplysninger om kerneprocessen (EPROSS) af den aktive proces på tidspunktet for nedbruddet.
• Trådinformation i kernen (ETHREAD) af den tråd, der forårsagede nedbruddet.
• Kernel-mode kaldstakken for den tråd (op til 16 KB).
• Liste over indlæste drivere på tidspunktet for kendelsen.
• Liste over indlæste og downloadede moduler.
• En fejlfindingsdatablok med grundlæggende systemoplysninger.

Denne type dump gemmes typisk i %SystemRoot%\Minidump (f.eks. C:\Windows\Minidump ). I mange tilfælde af grundlæggende support eller diagnosticering kan en minidump, der er grundigt analyseret med !analyze -v, være mere end tilstrækkelig.

Kernel Memory Dump

Kernelhukommelsesdumpen indeholder kernelhukommelsens indhold på tidspunktet for nedbruddet, eksklusive brugerproceshukommelsespladser. Den tilbyder en værdifuld balance mellem størrelse og detaljer og er ofte den anbefalede mulighed til diagnosticering af de fleste BSOD'er.

Denne dump gemmes som MEMORY.DMP i %SystemRoot% (som standard C:\Windows\MEMORY.DMP ). Dens størrelse afhænger af den hukommelse, der bruges af kernen, men den er normalt meget større end en minidump og meget mere håndterbar end en fuld dump.

Komplet hukommelsesdump

En fuld hukommelsesdump gemmer stort set alt indhold af RAM på fejltidspunktet: kerne, brugerprocesser osv. Det er den mest detaljerede, men også den, der optager mest plads og er den mest krævende med hensyn til konfiguration.

For at en komplet dump kan være gyldig, skal flere krav være opfyldt:

• El personsøgerfil skal være i samme partition hvor Windows er installeret.
• Der må være diskplads mindst svarende til størrelsen af ​​den fysiske hukommelse af maskinen.
• Flyt ikke sidefilen til en anden fysisk disk, hvis du vil undgå beskadigede dumps.

I produktionsmiljøer med meget RAM kan en fuld dump være upraktisk, men i meget komplekse eller intermitterende tilfælde kan det gøre hele forskellen i at finde problemet.

Konfigurer Windows til at registrere og logge BSOD'er

Før vi går i gang med WinDbg, er det vigtigt at sikre, at systemet genererer dumps korrekt og logger blå skærm-hændelsen.

I vinduet "Start og gendannelse" finder vi flere relevante muligheder:

• Skriv en hændelse til systemloggenskal være aktiveret for at fejlkontrollen kan registreres i Logbogen.
• Skriv fejlfindingsoplysningerHer vælger vi Minidump, Kernel memory dump eller Complete memory dump.
• sti til dumpfilen: standard %SystemRoot%\MEMORY.DMP for kerne/fuld.
• Genstart automatiskDet er tilrådeligt at fjerne markeringen, hvis vi ønsker det. se roligt på den blå skærm og læg mærke til, hvad der dukker op.

For nogle producenter eller supportafdelinger, f.eks. i tilfælde af visse netværkskort, bliver brugeren bedt om at indsende dumpfilen . Den er normalt placeret i C:\Windows\memory.dmp , og det anbefales at finde den efter dato/klokkeslæt for at identificere den, der svarer til den seneste fejl.

Hvis det, vi ønsker, er at kunne fremtvinge en dump, selv når systemet er frosset (uden at tastatur eller mus reagerer), er der også et meget nyttigt trick til PS/2-tastaturer (ikke USB/Bluetooth), som består i at konfigurere registreringsdatabasen til at udløse en dump med en tastekombination.

Tving en dump ved hjælp af tastaturet i tilfælde af frysning

For at generere en hukommelsesdump, selvom skærmen er helt frosset, kan du bruge indstillingen CrashOnCtrlScroll på PS/2-tastaturer. Denne metode er ikke gyldig for USB- eller Bluetooth-tastaturer.

I registreringsdatabasen skal vi oprette eller ændre følgende nøgle:

HKEY_LOCAL_MACHINE
  System
    CurrentControlSet
      Services
        i8042prt
          Parameters

Nombre: CrashOnCtrlScroll
Tipo:   REG_DWORD
Valor:  1

Efter genstart kan du når som helst (selv med frossen skærm) udløse et kontrolleret nedbrud og få systemet til at generere en hukommelsesdump ved at trykke på den højre CTRL- tast og derefter Scroll Lock-tasten to gange . Dette er meget nyttigt til at undersøge hårde nedbrud, der ikke viser en BSOD alene.

Introduktion til WinDbg til analyse af kerneldumps

WinDbg er Microsofts førende værktøj til kernel-fejlfinding og hukommelsesdumpanalyse . Det er tilgængeligt gratis (i øjeblikket også i Microsoft Store som WinDbg Preview), og selvom det kan virke skræmmende ved første øjekast, behøver du kun at forstå et par grundlæggende muligheder for at foretage en indledende BSOD-analyse.

Vi kan installere WinDbg på selve den berørte maskine eller på en hvilken som helst anden computer ; .dmp-filen kan kopieres over netværket, via USB eller endda komprimeres til en CAB-fil. Processoren og Windows-versionen, hvor vi analyserer dump'en, behøver ikke nødvendigvis at stemme overens med dem på den maskine, der gik ned.

Start WinDbg med en dump fra kommandolinjen

En klassisk måde at åbne en hukommelsesdump i WinDbg er at bruge kommandolinjen med `-z`- parameteren , der angiver stien til dumpfilen. Dette kan kombineres med andre parametre, såsom symbol- eller binærstien.

windbg -y <RutaSimbolos> -i <RutaBinarios> -z <RutaDump>

Modifikatoren -v aktiverer verbose-tilstanden , hvilket er meget nyttigt til at se mere kontekst. Udover WinDbg findes der også kd.exe , en konsolbaseret debugger, der giver dig mulighed for at gøre stort set det samme, men uden en grafisk brugerflade.

kd.exe -z "Ruta\al\volcado.dmp" -y "Ruta\simbolos" -i "Ruta\busqueda\binarios"

Åbn en dump fra den grafiske brugerflade

Hvis WinDbg allerede er åben i passiv tilstand, kan du indlæse en crashdump-fil ved hjælp af menuen Filer → Åbn Crash Dump eller genvejen Ctrl+D . Vælg .dmp-filen (eller endda en .cab-fil, der indeholder den), og WinDbg vil indlæse crashoplysningerne.

Et andet alternativ er at starte WinDbg, og når du er inde i den, skal du køre kommandoen .opendump , hvor du angiver stien til dumpfilen, og derefter køre kommandoen g (Go) for at starte dump-fejlfindingssessionen:

.opendump C:\Windows\Memory.dmp
g

WinDbg tillader endda rydde op i flere lossepladser på én gangtilføjelse af flere parametre -z på kommandolinjen eller ved at gentage .opendump med forskellige ruter og styring af sessionen med flere destinationer.

Konfigurer symbolstien i WinDbg

Uden symboler fungerer WinDbg næsten blindt. Symboler (.pdb) indeholder fejlfindingsinformation om funktioner, interne strukturer, variabler, offsets osv . og er afgørende for pålidelig analyse, især når man arbejder med kernen.

For at bruge Microsofts offentlige symboler uden at skulle downloade dem manuelt, er den bedste fremgangsmåde at konfigurere en symbolserver, der peger på den officielle Microsoft-server og en lokal cachemappe. For eksempel kan vi først oprette en mappe C:\symbols og derefter i WinDbg konfigurere symbolstien som følger:

SRV*c:\symbols*https://msdl.microsoft.com/download/symbols

Dette kan gøres fra menuen Fil → Symbolfilsti eller, i WinDbg Preview, fra Fil → Indstillinger → Fejlfindingsindstillinger ved at justere "Standard symbolsti". Første gang du analyserer en dump fra et bestemt system, vil fejlfindingsprogrammet automatisk downloade de nødvendige symboler fra internettet, hvilket kan tage et par minutter afhængigt af din forbindelse.

Det er vigtigt at bemærke, at Microsofts offentlige symboler nogle gange ikke inkluderer alle interne typeoplysninger , og du kan muligvis se advarsler som "Din fejlfinder bruger ikke de korrekte symboler" eller referencer til uopløselige typer. Til grundlæggende BSOD-analyse er offentlige symboler normalt tilstrækkelige, men hvis du har brug for flere detaljer, vil der være begrænsninger.

Første analyse: grundlæggende kommandoer og fejltjek

Når dumpfilen er indlæst, og symbolerne er konfigureret, viser WinDbg normalt en header med systemoplysninger og en advarsel som f.eks. "Brug !analyze -v for at få detaljerede fejlfindingsoplysninger." Det er vores første stop for en indledende analyse.

Kommandoen !analyze -v udfører en automatisk analyse af dumpen og leverer normalt:

• Bugcheck-koden (for eksempel 0xE3, 0xD1, 0x9F, 0x44…).
• Parametrene Arg1, Arg2, Arg3 og Arg4 fra fejlkontrollen.
• Det mest sandsynlige modul eller driver årsagen til fejlen (Probably caused by).
• Den tilhørende proces i det øjeblik (for eksempel Teams.exe).
• Opkaldsstakken (staksporing) af den tråd, der udløste nedbruddet.
• Spandoplysninger og fejlhashes, nyttige til at korrelere gentagne fejl.

For eksempel, i en virkelig bugcheck-sag RESOURCE_NOT_OWNED (0xE3) , kan analysen indikere, at en tråd forsøgte at frigive en ressource, den ikke ejer , hvilket viser Teams.exe som processen og peger på win32kbase.sys i en funktion som DrvEnumDisplaySettings . Dette tyder på, at den fejlende tråd forespurgte eller manipulerede skærmindstillinger fra brugerområdet via Windows-grafiklaget.

For at dykke lidt dybere ned i detaljerne om stopkoden og dens parametre, har vi også kommandoen .fejltjeksom igen viser fejlkontrollen og de fire argumenter, hvilket er nyttigt, hvis vi vil gentage disse oplysninger uden at køre alt igen. !analyze -v.

Praktiske tilfælde: drivkræfter og typiske konflikter

BSOD-analyse drejer sig typisk om at identificere defekte eller funktionsfejlende drivere , driverkonflikter, forkert hukommelsesadgang, forkert håndtering af IRP'er (I/O-anmodningspakker) og så videre. Lad os se på nogle praktiske eksempler fra den virkelige verden for bedre at forstå processen.

RESOURCE_NOT_OWNED (0xE3) tilknyttet Teams og win32kbase.sys

I et Windows 10-scenarie, hvor der efter flere dages oppetid vises en BSOD med bugcheck 0xE3 (RESOURCE_NOT_OWNED) , viser minikernel-dumpen noget i stil med:

RESOURCE_NOT_OWNED (e3)
A thread tried to release a resource it did not own.
Arguments:
Arg1: <dirección recurso>
Arg2: <dirección thread>
Arg3: 0
Arg4: 0

PROCESS_NAME: Teams.exe

STACK_TEXT:
...
win32kbase!DrvEnumDisplaySettings+0x356
win32kbase!NtUserEnumDisplaySettings+0x59
win32k!NtUserEnumDisplaySettings+0x15
nt!KiSystemServiceCopyEnd+0x28
...

Her indikerer debuggeren, at fejltjekket udløses af en tråd tilknyttet Teams.exe , men at den kode, der faktisk er på stakken på det kritiske tidspunkt, tilhører win32kbase.sys , nærmere bestemt DrvEnumDisplaySettings- funktionen . Dette betyder ikke nødvendigvis, at Teams er den direkte synder, men snarere at Teams kalder en bruger-API , der resulterer i en synkroniserings- eller ressourcefrigivelsesfejl i grafikundersystemet.

I denne type diagnoser er konklusionen ofte, at det er en fejl i Windows-grafikstakken, en specifik videodriver eller interaktionen mellem applikationen og driverne. Den egentlige løsning kan involvere opdatering af GPU-drivere, opdatering af Teams eller endda anvendelse af specifikke Windows-patches i stedet for blot at vente på, at det løser sig selv.

DRIVER_IRQL_NOT_LESS_OR_EQUAL (0xD1) med NotMyFault

Sysinternals' NotMyFault -værktøj er et uddannelsesværktøj, der giver dig mulighed for at generere kernefejl på en kontrolleret måde for at lære at analysere skærmbilleder. Hvis du for eksempel starter indstillingen Høj IRQL-fejl (kernetilstand) fra NotMyFault og klikker på "Udfør fejl", vil du fremtvinge en DRIVER_IRQL_NOT_LESS_OR_EQUAL (0xD1)-fejl.

På den blå skærm ser vi noget i retning af DRIVER_IRQL_NOT_LESS_OR_EQUAL og muligvis en kandidatdriver (f.eks. MyFault.sys , den driver, der bruges af værktøjet). Når dumpfilen er genereret og åbnet med WinDbg, kan det oprindelige output se sådan ud:

Use !analyze -v to get detailed debugging information.
BugCheck D1, {e1071800, 1c, 0, f7cda403}
*** ERROR: Module load completed but symbols could not be loaded for myfault.sys
Probably caused by : memory_corruption
Followup: memory_corruption

Selvom debuggeren peger på hukommelseskorruption , ved vi, at den virkelige årsag er relateret til NotMyFault og dens driver. For at bekræfte dette kan vi fortsætte med at spore med kommandoer som !thread for at se, hvilke kald tråden foretager på fejltidspunktet, og !irp for at analysere den involverede IRP, hvis fejlkontrollen er relateret til I/O-operationer.

For eksempel kan vi med `!thread <dir_thread>` se trådens stakspor og finde instruktionen, hvor `myfault+0x403` vises , hvilket angiver, hvor testdriveren har taget fejl. Derfra kan vi undersøge IRP, hukommelsesstatus og så videre, ligesom vi ville gøre med en rigtig fejl.

MULTIPLE_IRP_COMPLETE_REQUESTS (0x44) og USB-konflikter

Et andet meget illustrativt tilfælde er bugchecken MULTIPLE_IRP_COMPLETE_REQUESTS (0x44)Denne fejl opstår, når En IRP (I/O-anmodningspakke) udføres mere end én gang, normalt fordi to forskellige chauffører mener, at de ejer den samme IRP, og begge ringer IoCompleteRequest().

Analysen med !analyze -v kan give en beskrivelse, der ligner denne:

MULTIPLE_IRP_COMPLETE_REQUESTS (44)
A driver has requested that an IRP be completed (IoCompleteRequest()), but
the packet has already been completed.
...
Arguments:
Arg1: <IRP_ADDRESS>
Arg2: 00000d75
Arg3: 00000000
Arg4: 00000000

Probably caused by : usbehci.sys

I starten ser den mistænkte ud til at være usbehci.sys , en Microsoft-driver til USB EHCI-controllere. Det er dog relativt sjældent, at en fejl rent faktisk skyldes en indbygget Windows-driver uden nogen interaktion fra tredjepart. For at komme til sagen bruger vi IRP-adressen leveret af bugchecken (Arg1) og kører !irp <IRP_ADDRESS> :

!irp 87e5a490
Irp is active with 3 stacks 3 is current (= 0x87e5a548)
...
> [ f, 0] 0 c0 8a055618 00000000 b69de300-00000000 Success Error
  \Driver\usbehci ax88172
Args: b70989c0 00000000 00220003 00000000

I den sidste linje ser vi tydeligt strengen \Driver\usbehci ax88172 , hvilket afslører, at IRP'en er gået gennem både usbehci.sys og en driver kaldet ax88172.sys , der er tilknyttet et specifikt USB-netværkschipsæt (AX88172). Derfor kan vi konkludere, at konflikten stammer fra denne tredjeparts USB NIC-driver , ikke fra Microsofts generiske EHCI-driver.

I så fald involverer løsningen at opdatere USB-adapterdriveren, udskifte enheden eller om nødvendigt fjerne den . Denne type IRP-analyse er især nyttig til BSOD'er relateret til USB, lagring, netværkskort og generelt enhver komponent, der bruger intensiv I/O.

Nyttige WinDbg-kommandoer i kerneltilstand

Ud over !analyze -v og .bugcheck er der adskillige WinDbg-udvidelser og -kommandoer, der er meget nyttige, når vi vil dykke lidt dybere ned i kerneldumping.

Nogle af de mest almindelige er:

• !trådViser detaljerede oplysninger om en tråd, herunder dens kaldstak, tilstand, tilhørende IRP'er osv. Det giver dig mulighed for at se de "sidste handlinger" for den tråd, der kørte, da systemet gik ned.
• !proces 0 0Dette viser alle aktive processer på tidspunktet for nedbruddet. Det er nyttigt til at identificere, om der var mistænkelige processer, tjenester, EDR, antivirus osv., der kørte på maskinen.
• !irp: analyserer en specifik IRP og viser sporet af de chauffører, den har gennemgåetI/O-kommandoen, flag osv. er nøglen til fejl relateret til FLERE_IRP_FULDSTÆNDIGE_ANMODNINGER og andre I/O-fejl.
• !cpuinfo: giver oplysninger om processoren (producent, MHz, signaturer, egenskaber), nyttige til at verificere hardwaremiljøer.
• !pebviser detaljer om PEB (Process Environment Block), såsom computernavn, Windows-installationssti, antal processorer osv.
• !token: giver oplysninger om sikkerhedstokens, tilladelser og sikkerhedskontekst for processen eller tråden.
• .cls: rydder kommandovinduet, som i en almindelig konsol.

Derudover giver mange specifikke filsystemudvidelser (f.eks. til PnP, NTFS osv.) dig mulighed for at udtrække endnu mere information fra dumps. I nogle tilfælde vil WinDbg indikere tilstedeværelsen af ​​BLACKBOX* (BLACKBOXBSD, BLACKBOXNTFS, BLACKBOXPNP, BLACKBOXWINLOGON), som er yderligere datablokke, der indsamles under fejlkontrollen for at lette diagnosen af ​​specifikke systemområder.

Brug af Driver Verifier til at finde problematiske drivere

En meget høj andel af Windows Blue Screen of Death (BSOD)-fejl skyldes defekte eller dårligt programmerede drivere . For proaktivt at opdage disse typer problemer indeholder systemet et effektivt værktøj: Driver Verifier.

Driver Verifier kører i realtid og udsætter udvalgte drivere for en række tests og stresstests: den kontrollerer for korrekt hukommelsesforbrug, kernepoolbrug, IRQL, IRP osv. Hvis den registrerer, at en driver opfører sig forkert, kan den fremtvinge en kontrolleret BSOD, så vi kan analysere en meget tydeligere dump, hvor synderen normalt let kan identificeres.

For at starte Driver Verifier-administratoren skal du blot åbne en kommandoprompt med administratorrettigheder og skrive:

verifier

Derfra kan vi vælge, hvilke drivere vi vil verificere. Det er klogt at være forsigtig: Verifikatoren øger systemets belastning og kan forringe ydeevnen , så det anbefales kun at aktivere verifikation for de færreste mulige mistænkelige drivere i stedet for at vælge alt vilkårligt.

Når Verifier udløser en BSOD, når den registrerer forkert adfærd, kan vi analysere kerneldumpen med WinDbg og forhåbentlig tydeligt se, hvilken driver der blev fanget , og hvad den gjorde forkert. Microsofts referenceartikler om Driver Verifier forklarer de forskellige muligheder og brugsstrategier i detaljer.

Praktiske råd til ingeniører og teknikere

Uanset om du er driverudvikler, softwareudvikler, der interagerer med kernen, eller blot den tekniker, der får alle de blå skærme, der viser døden, er der nogle retningslinjer, der er værd at internalisere for at undgå at fare vild i junglen af ​​BSOD'er.

Det første trin, når fejlen er relateret til din egen kode, er systematisk at bruge kernel-debuggeren til at reproducere og analysere problemet . Ved at forbinde en debugger til målmaskinen (via netværk, serielt osv.) vil en bugcheck få systemet til at stoppe inde i debuggeren i stedet for at vise den blå skærm direkte. Derfra kan du inspicere hukommelse, stakke, strukturer og rette koden.

I andre scenarier kan fejltjek skyldes tredjepartsdrivere, hardware eller software , som vi ikke kontrollerer. I disse tilfælde skifter målet fra at "rette koden" til at isolere og afbøde problemet.

• Identificér den mistænkelige driver eller hardwarekomponent ved hjælp af WinDbg og dumpanalyse.
• Opdater eller fortryd driverversioner, BIOS, firmware eller relaterede applikationer.
• Fjern eller udskift USB-enheder, grafikkort, netværkskort konfliktfyldt.
• At læne sig op ad Hændelsesvisning, Sysinternals, netværksovervågnings- og analyseværktøjer for yderligere kontekst.

Mange tilsyneladende mystiske problemer løses med grundlæggende fejlfindingsprocedurer : gennemgang af dokumentation, kontrol af filversioner og datoer, geninstallation af nøglekomponenter eller deaktivering af modstridende moduler. Analyse af dumpen giver os en klar retning i, hvor vi skal lede, og sparer os ofte for timers forsøg og fejl.

Det er også vigtigt at huske, at i miljøer som det, der forårsagede CrowdStrike Falcon- hændelsen og andre EDR'er, drejer de mest almindelige spørgsmål sig om, hvad der udløste BSOD'en, og hvordan man hurtigt identificerer den . Når WinDbg er korrekt konfigureret, med symboler og en klar procedure til åbning og analyse af dumps, kan du på få minutter indsnævre, hvad der ellers ville ende med en "formatering og geninstallation" uden egentlig at forstå årsagen.

Kort sagt, en kombination af en god memory dump-konfiguration, disciplineret brug af værktøjer som WinDbg, Driver Verifier og Sysinternals, og vanen med metodisk at gennemgå logfiler og stakke, forvandler de blå skærme fra en uforudsigelig fjende til en meget præcis kilde til information om, hvad der er fejlet i kernen , hvilket hjælper os med at træffe langt mere informerede tekniske beslutninger.