Komplett guide til å analysere BSOD-er og kerneldumps i Windows

Informatec Digital » Ressurser » Komplett guide til å analysere BSOD-er og kerneldumps i Windows

Når en Windows-datamaskin fryser med en blåskjerm, er det ikke bare irriterende: det er ofte verdifull informasjon skjult i minnedumpen som forteller oss nøyaktig hva som skjedde i kjernen. I stedet for å skylde på RAM, BIOS eller umiddelbart omformatering, er det verdt å lære seg å lese disse dataene.

Med litt øvelse lar verktøy som WinDbg og funksjoner som !analyze -v, .bugcheck, eller riktig bruk av symboler oss gå fra «Jeg får en blåskjermfeil» til «Jeg vet hvilken driver, ressurs eller enhet som forårsaket BSOD-en.» I denne artikkelen vil vi trinn for trinn og i detalj gå gjennom hvordan man analyserer en BSOD ved hjelp av kjernedumpen, hvilke typer dump-er som finnes, hvordan man forbereder alt, og hvilke kommandoer som skal brukes for å få mest mulig ut av analysen.

Hva er en BSOD, og ​​hvilken informasjon inneholder den?

Når Windows støter på en tilstand som kompromitterer systemintegriteten og ikke kan gjenopprettes på en sikker måte, foretar den et internt kjernekall kalt KeBugCheckEx . Dette kallet er det som utløser den beryktede blåskjermen (BSOD).

KeBugCheckEx mottar alltid fem argumenter: en STOP-kode (feilsjekkkode) og fire tilleggsparametere som gir teknisk kontekst til feilen. Det er disse samme dataene vi deretter kan konsultere.

• På den blå skjermen klassisk, hvis systemet ikke er konfigurert til å starte på nytt automatisk.
• I Windows-hendelsesloggen, i hendelseslisten (systemloggen).
• I minnedumpfilen (minidump, kernel dump eller full dump), ved bruk av WinDbg og kommandoer som !analyze -v o .bugcheck.

Hver feilsjekkkode har et symbolsk navn og en tilhørende heksadesimal verdi . For eksempel har feilsjekken DRIVER_POWER_STATE_FAILURE koden 0x9F , mens RESOURCE_NOT_OWNED tilsvarer 0xE3 . Disse kodene og parameterne deres er dokumentert i Microsofts feilsjekkkodereferanse, som du alltid bør ha for hånden.

I tillegg til koden kan den blå skjermen vise navnet på en potensielt involvert .sys-driver . Hvis det er en tredjepartsdriver (antivirus, nettverkskort, grafikkort osv.), har vi ofte en klar mistenkt. Hvis en generisk systemkomponent (ntoskrnl.exe, win32k.sys osv.) vises, eller hvis ingenting vises i det hele tatt, må vi utføre en minnedump og bruke WinDbg til å undersøke saken nærmere.

Typer minnedumper i Windows

For å analysere en BSOD i dybden, trenger vi at Windows genererer en minnedumpfil (DMP) når feilen oppstår. Denne filen registrerer systemtilstanden på tidspunktet for feilen og kan være av forskjellige typer.

I alternativene for «Oppstart og gjenoppretting» (høyreklikk på «Denne PC-en / Min datamaskin» → Egenskaper → Avanserte systeminnstillinger → fanen «Avansert» → knappen «Innstillinger» under «Oppstart og gjenoppretting») kan du velge mellom flere typer dumpfiler. Hver av dem har sine fordeler og ulemper.

Liten minnedump (minidump)

Minidump - formatet er det minste (rundt 64 KB) og også det mest begrensede for avansert feilsøking. Det er imidlertid fortsatt nyttig for å få en rask diagnose i mange BSOD-scenarier.

En minidump lagrer blant annet data:

• Stoppmeldingen, feilsjekkkoden og dens parametere.
• Prosessorkonteksten (PRCB) til prosessoren som forårsaket feilen.
• Informasjon om kjerneprosessen (EPROSS) av den aktive prosessen på tidspunktet for krasj.
• Trådinformasjon i kjernen (ETHREAD) av tråden som forårsaket krasjet.
• Kjernemodus-kallstakken for den tråden (opptil 16 KB).
• Liste over lastede drivere på tidspunktet for kjennelsen.
• Liste over lastede og nedlastede moduler.
• En feilsøkingsdatablokk med grunnleggende systeminformasjon.

Denne typen dump lagres vanligvis i %SystemRoot%\Minidump (for eksempel C:\Windows\Minidump ). For mange grunnleggende støtte- eller diagnostikktilfeller kan en minidump som er grundig analysert med !analyze -v være mer enn tilstrekkelig.

Kjerneminnedump

Kjerneminnedumpen inneholder innholdet i kjerneminnet på tidspunktet for krasj, unntatt brukerprosessens minneplasser. Den gir en verdifull balanse mellom størrelse og detaljer, og er ofte det anbefalte alternativet for å diagnostisere de fleste BSOD-er.

Denne dumpen lagres som MEMORY.DMP i %SystemRoot% (som standard C:\Windows\MEMORY.DMP ). Størrelsen avhenger av minnet som brukes av kjernen, men den er vanligvis mye større enn en minidump og mye mer håndterbar enn en full dump.

Fullfør minnedump

En fullstendig minnedump lagrer så godt som alt innholdet i RAM på feiltidspunktet: kjerne, brukerprosesser osv. Den er den mest detaljerte, men også den som tar opp mest plass og er den mest krevende når det gjelder konfigurasjon.

For at en komplett dump skal være gyldig, må flere krav være oppfylt:

• El personsøkerfil må være i samme partisjon der Windows er installert.
• Det må være diskplass minst lik størrelsen på det fysiske minnet av maskinen.
• Ikke flytt sidefilen til en annen fysisk disk hvis du vil unngå ødelagte dumpfiler.

I produksjonsmiljøer med mye RAM kan en full dump være upraktisk, men for svært komplekse eller intermitterende tilfeller kan det utgjøre hele forskjellen i å finne problemet.

Konfigurer Windows til å fange opp og logge BSOD-er

Før vi går i gang med WinDbg, er det viktig å sørge for at systemet genererer dumpene riktig og logger blåskjermhendelsen.

I vinduet «Start og gjenoppretting» finner vi flere relevante alternativer:

• Skriv en hendelse til systemloggenmå være aktivert for at feilsjekken skal registreres i hendelsesvisningen.
• Skriv feilsøkingsinformasjonHer velger vi Minidump, Kernel memory dump eller Complete memory dump.
• dumpfilstistandard %SystemRoot%\MEMORY.DMP for kjerne/full.
• Start automatisk på nyttDet er lurt å fjerne merket for det hvis vi vil se rolig på den blå skjermen og legg merke til hva som dukker opp.

For noen produsenter eller støtteavdelinger, som for eksempel for visse nettverkskort, blir brukeren bedt om å sende inn dumpfilen . Den ligger vanligvis i C:\Windows\memory.dmp , og det anbefales å finne den etter dato/klokkeslett for å identifisere den som tilsvarer den siste feilen.

Hvis det vi ønsker er å kunne fremtvinge en dump selv når systemet er frosset (uten at tastatur eller mus reagerer), finnes det også et veldig nyttig triks for PS/2-tastaturer (ikke USB/Bluetooth), som består av å konfigurere registeret til å utløse en dump med en tastekombinasjon.

Tving frem en dump ved hjelp av tastaturet i tilfelle frysing

For å generere en minnedump selv om skjermen er helt frossen, kan du bruke alternativet CrashOnCtrlScroll på PS/2-tastaturer. Denne metoden er ikke gyldig for USB- eller Bluetooth-tastaturer.

I registeret må vi opprette eller endre følgende nøkkel:

HKEY_LOCAL_MACHINE
  System
    CurrentControlSet
      Services
        i8042prt
          Parameters

Nombre: CrashOnCtrlScroll
Tipo:   REG_DWORD
Valor:  1

Etter omstart kan du når som helst (selv med fryst skjerm) utløse en kontrollert krasj og få systemet til å generere en minnedump ved å trykke på høyre CTRL- tast og deretter Scroll Lock-tasten to ganger . Dette er veldig nyttig for å undersøke harde krasj som ikke viser en BSOD på egenhånd.

Introduksjon til WinDbg for analyse av kjernedumper

WinDbg er Microsofts fremste verktøy for kjernefeilsøking og minnedumpanalyse . Det er tilgjengelig gratis (for tiden også i Microsoft Store som WinDbg Preview), og selv om det kan virke skremmende ved første øyekast, trenger du bare å forstå noen få grunnleggende alternativer for en innledende BSOD-analyse.

Vi kan installere WinDbg på selve den berørte maskinen eller på en hvilken som helst annen datamaskin . .dmp-filen kan kopieres over nettverket, via USB, eller til og med komprimeres til en CAB-fil. Prosessoren og Windows-versjonen der vi analyserer dumpen trenger ikke nødvendigvis å samsvare med maskinen som krasjet.

Start WinDbg med en dump fra kommandolinjen

En klassisk måte å åpne en minnedump i WinDbg på er å bruke kommandolinjen med `-z`- parameteren , som spesifiserer banen til dumpfilen. Dette kan kombineres med andre parametere, for eksempel symbol- eller binærbanen.

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

Modifikatoren -v aktiverer verbose-modus , som er veldig nyttig for å se mer kontekst. Foruten WinDbg finnes det også kd.exe , en konsollbasert feilsøkingsfunksjon som lar deg gjøre praktisk talt det samme, men uten et grafisk grensesnitt.

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

Åpne en dump fra det grafiske grensesnittet

Hvis WinDbg allerede er åpen i passiv modus, kan du laste inn en krasjdumpfil ved å bruke Fil → Åpne krasjdump- menyen eller snarveien Ctrl+D . Velg .dmp-filen (eller til og med en .cab-fil som inneholder den), og WinDbg vil laste inn krasjinformasjonen.

Et annet alternativ er å starte WinDbg, og når du er inne, kjøre kommandoen .opendump som spesifiserer banen til dumpfilen, og deretter kommandoen g (Go) for å starte feilsøkingsøkten for dumpfilen:

.opendump C:\Windows\Memory.dmp
g

WinDbg tillater til og med rydde opp i flere søppelfyllinger samtidiglegge til flere parametere -z på kommandolinjen eller ved å gjenta .opendump med forskjellige ruter og administrasjon av flerdestinasjonsøkten.

Konfigurer symbolbanen i WinDbg

Uten symboler fungerer WinDbg nesten blindt. Symboler (.pdb) inneholder feilsøkingsinformasjon om funksjoner, interne strukturer, variabler, forskyvninger osv. , og er essensielle for pålitelig analyse, spesielt når man arbeider med kjernen.

For å bruke Microsofts offentlige symboler uten å måtte laste dem ned manuelt, er det beste å konfigurere en symbolserver som peker til den offisielle Microsoft-serveren og en lokal hurtigbufferkatalog. For eksempel kan vi først opprette en mappe C:\symbols og deretter, i WinDbg, konfigurere symbolbanen som følger:

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

Dette kan gjøres fra Fil → Symbolfilbane- menyen , eller i WinDbg-forhåndsvisning fra Fil → Innstillinger → Feilsøkingsinnstillinger ved å justere «Standard symbolbane». Første gang du analyserer en dump fra et bestemt system, vil feilsøkingsprogrammet automatisk laste ned de nødvendige symbolene fra internett. Dette kan ta noen minutter avhengig av tilkoblingen din.

Det er viktig å merke seg at Microsofts offentlige symboler noen ganger ikke inkluderer all intern typeinformasjon , og du kan se advarsler som «Feilsøkingsprogrammet ditt bruker ikke de riktige symbolene» eller referanser til typer som ikke kan løses. For grunnleggende BSOD-analyse er offentlige symboler vanligvis tilstrekkelige, men hvis du trenger mer informasjon, vil det være begrensninger.

Første analyse: grunnleggende kommandoer og feilsjekk

Når dumpen er lastet inn og symbolene er konfigurert, viser WinDbg vanligvis en overskrift med systeminformasjon og en advarsel som "Bruk !analyze -v for å få detaljert feilsøkingsinformasjon." Det er vårt første stopp for en innledende analyse.

Kommandoen !analyze -v utfører en automatisk analyse av dumpen og gir vanligvis:

• Feilsjekkkoden (for eksempel 0xE3, 0xD1, 0x9F, 0x44…).
• Parametrene Arg1, Arg2, Arg3 og Arg4 fra feilsjekken.
• Den mest sannsynlige modulen eller driveren årsaken til feilen (Probably caused by).
• Den tilhørende prosessen i det øyeblikket (for eksempel Teams.exe).
• Kallestakken (stakksporing) av tråden som utløste krasjet.
• Bøtteinformasjon og feil-hasher, nyttige for å korrelere gjentatte feil.

For eksempel, i et reelt feilsøkingstilfelle RESOURCE_NOT_OWNED (0xE3) , kan analysen indikere at en tråd forsøkte å frigjøre en ressurs den ikke eier , viser Teams.exe som prosessen og peker til win32kbase.sys i en funksjon som DrvEnumDisplaySettings . Dette antyder at den feilende tråden spurte etter eller manipulerte skjerminnstillinger fra brukerområdet gjennom Windows-grafikklaget.

For å gå litt dypere inn i detaljene om stoppkoden og dens parametere, har vi også kommandoen .feilsjekksom igjen viser feilsjekken og de fire argumentene, noe som er nyttig hvis vi vil gjenta den informasjonen uten å kjøre alt på nytt. !analyze -v.

Praktiske tilfeller: drivere og typiske konflikter

BSOD-analyse dreier seg vanligvis om å identifisere defekte eller funksjonsfeilaktige drivere , driverkonflikter, feil minnetilgang, feil håndtering av IRP-er (I/O-forespørselspakker) og så videre. La oss se på noen praktiske eksempler fra virkelige tilfeller for å bedre forstå prosessen.

RESOURCE_NOT_OWNED (0xE3) tilknyttet Teams og win32kbase.sys

I et Windows 10-scenario der det etter flere dager med oppetid vises en BSOD med bugcheck 0xE3 (RESOURCE_NOT_OWNED) , viser minikernel-dumpen noe som ligner på:

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 feilsøkingsprogrammet at feilsøkingen utløses av en tråd tilknyttet Teams.exe , men koden som faktisk er på stacken i det kritiske øyeblikket tilhører win32kbase.sys , nærmere bestemt DrvEnumDisplaySettings -funksjonen . Dette betyr ikke nødvendigvis at Teams er den direkte synderen, men snarere at Teams kaller et bruker-API som resulterer i en synkroniserings- eller ressursutgivelsesfeil i grafikkundersystemet.

I denne typen diagnoser er konklusjonen ofte at det er en feil i Windows-grafikkstakken, en spesifikk skjermdriver eller samspillet mellom applikasjonen og driverne. Den faktiske løsningen kan innebære å oppdatere GPU-drivere, oppdatere Teams eller til og med installere spesifikke Windows-oppdateringer , i stedet for bare å vente på at det skal fikse seg selv.

DRIVER_IRQL_NOT_LESS_OR_EQUAL (0xD1) med IkkeMinFeil

Sysinternals' NotMyFault -verktøy er et pedagogisk verktøy som lar deg generere kjernefeil på en kontrollert måte for å lære hvordan du analyserer skjermbilder. Hvis du for eksempel starter alternativet Høy IRQL-feil (kjernemodus) fra NotMyFault og klikker på "Utfør feil", vil du fremtvinge en DRIVER_IRQL_NOT_LESS_OR_EQUAL (0xD1)-feil.

På den blå skjermen ser vi noe som DRIVER_IRQL_NOT_LESS_OR_EQUAL og muligens en kandidatdriver (for eksempel MyFault.sys , driveren som brukes av verktøyet). Når dumpen er generert og åpnet med WinDbg, kan den første utdataen se omtrent slik ut:

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

Selv om feilsøkingsprogrammet peker på minnekorrupsjon , vet vi at den virkelige årsaken er relatert til NotMyFault og driveren. For å bekrefte dette kan vi fortsette sporingen med kommandoer som !thread for å se hvilke kall tråden foretar på feiltidspunktet, og !irp for å analysere den involverte IRP-en hvis feilsjekken er relatert til I/O-operasjoner.

For eksempel, med `!thread <dir_thread>` kan vi se trådens stakkspor og finne instruksjonen der `myfault+0x403` vises , noe som indikerer hvor testdriveren har gjort feil. Derfra kan vi undersøke IRP, minnestatus og så videre, akkurat som vi ville gjort med en ekte feil.

MULTIPLE_IRP_COMPLETE_REQUESTS (0x44) og USB-konflikter

Et annet veldig illustrerende tilfelle er feilsjekken FLERE_IRP_FULLSTENDIGE_FORESPØRSLER (0x44)Denne feilen oppstår når En IRP (I/O-forespørselspakke) fullføres mer enn én gang, vanligvis fordi to forskjellige sjåfører tror de eier samme IRP og begge ringer IoCompleteRequest().

Analysen med !analyze -v kan gi en beskrivelse som ligner på 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 utgangspunktet ser det ut til at den mistenkte feilen er usbehci.sys , en Microsoft-driver for USB EHCI-kontrollere. Det er imidlertid relativt sjelden at en feil faktisk forårsakes av en innebygd Windows-driver uten noen tredjepartsinteraksjon. For å komme til poenget bruker vi IRP-adressen som leveres av feilsjekken (Arg1) og kjø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 siste linjen ser vi tydelig strengen \Driver\usbehci ax88172 , som viser at IRP-en har gått gjennom både usbehci.sys og en driver kalt ax88172.sys , som er tilknyttet et spesifikt USB-nettverksbrikkesett (AX88172). Derfor kan vi konkludere med at konflikten stammer fra denne tredjeparts USB NIC-driveren , ikke fra Microsofts generiske EHCI-driver.

I så fall innebærer løsningen å oppdatere USB-adapterdriveren, bytte ut enheten eller, om nødvendig, fjerne den . Denne typen IRP-analyse er spesielt nyttig for BSOD-er relatert til USB, lagring, nettverkskort og generelt alle komponenter som bruker intensiv I/O.

Nyttige WinDbg-kommandoer i kjernemodus

Utover !analyze -v og .bugcheck finnes det flere WinDbg-utvidelser og -kommandoer som er svært nyttige når vi ønsker å dykke litt dypere inn i kerneldumping.

Noen av de vanligste er:

• !trådViser detaljert informasjon om en tråd, inkludert dens kallestakk, tilstand, tilknyttede IRP-er osv. Den lar deg se de "siste handlingene" til tråden som kjørte da systemet krasjet.
• !prosess 0 0Denne listen viser alle aktive prosesser på tidspunktet for krasj. Den er nyttig for å identifisere om det var noen mistenkelige prosesser, tjenester, EDR, antivirus osv. som kjørte på maskinen.
• !irpanalyserer en spesifikk IRP og viser sporet av sjåførene den har gått gjennomI/O-kommandoen, flagg osv. er viktige i feil relatert til MULTIPLE_IRP_COMPLETE_REQUESTS og andre I/O-feil.
• !cpuinfo: gir informasjon om prosessoren (produsent, MHz, signaturer, egenskaper), nyttig for å verifisere maskinvaremiljøer.
• !pebviser detaljer om PEB (prosessmiljøblokken), for eksempel datamaskinnavn, Windows-installasjonssti, antall prosessorer osv.
• !token: gir informasjon om sikkerhetstokener, tillatelser og sikkerhetskontekst for prosessen eller tråden.
• .cls: tømmer kommandovinduet, som i en vanlig konsoll.

I tillegg lar mange spesifikke filsystemutvidelser (f.eks. for PnP, NTFS osv.) deg trekke ut enda mer informasjon fra dumpene. I noen tilfeller vil WinDbg indikere tilstedeværelsen av BLACKBOX* (BLACKBOXBSD, BLACKBOXNTFS, BLACKBOXPNP, BLACKBOXWINLOGON), som er tilleggsdatablokker som fanges opp under feilsjekken for å forenkle diagnosen av spesifikke systemområder.

Bruke Driver Verifier for å finne problematiske drivere

En svært høy andel av Windows Blue Screen of Death (BSOD)-feil er forårsaket av feilaktige eller dårlig programmerte drivere . For å proaktivt oppdage denne typen problemer inkluderer systemet et kraftig verktøy: Driver Verifier.

Driververifiseringen kjører i sanntid og utsetter utvalgte drivere for en rekke tester og stresstester: den sjekker for riktig minnebruk, kjernepoolbruk, IRQL, IRP osv. Hvis den oppdager at en driver oppfører seg feil, kan den fremtvinge en kontrollert BSOD slik at vi kan analysere en mye tydeligere dump, hvor synderen vanligvis er lett å identifisere.

For å starte Driver Verifier-behandleren, åpner du ganske enkelt en ledetekst med administratorrettigheter og skriver:

verifier

Derfra kan vi velge hvilke drivere vi vil verifisere. Det er lurt å være forsiktig: Verifikatoren legger til overhead for systemet og kan forringe ytelsen , så det anbefales å aktivere verifisering bare for færrest mulige mistenkelige drivere i stedet for å velge alt vilkårlig.

Når Verifier utløser en BSOD når den oppdager feil oppførsel, kan vi analysere kerneldumpen med WinDbg og forhåpentligvis tydelig se hvilken driver som ble fanget opp og hva den gjorde galt. Microsofts referanseartikler om Driver Verifier forklarer de ulike alternativene og bruksstrategiene i detalj.

Praktiske råd for ingeniører og teknikere

Enten du er en driverutvikler, en programvareutvikler som samhandler med kjernen, eller bare den teknikeren som får alle de blå skjermene, finnes det noen retningslinjer som er verdt å internalisere for å unngå å gå seg vill i jungelen av BSOD-er.

Det første trinnet, når feilen er relatert til din egen kode, er å systematisk bruke kjernefeilsøkingsprogrammet til å reprodusere og analysere problemet . Ved å koble et feilsøkingsprogram til målmaskinen (via nettverk, seriell osv.), vil en feilsjekk føre til at systemet stopper inne i feilsøkingsprogrammet i stedet for å vise den blå skjermen direkte. Derfra kan du inspisere minne, stabler, strukturer og korrigere koden.

I andre tilfeller kan feilsøking skyldes tredjepartsdrivere, maskinvare eller programvare som vi ikke kontrollerer. I slike tilfeller skifter målet fra å «fikse koden» til å isolere og redusere problemet.

• Identifiser den mistenkelige driveren eller maskinvarekomponenten ved hjelp av WinDbg og dumpanalyse.
• Oppdater eller tilbakestill driverversjoner, BIOS, fastvare eller relaterte applikasjoner.
• Fjern eller erstatt USB-enheter, grafikkort, nettverkskort konfliktfylt.
• Å lene seg på Hendelsesvisning, Sysinternals, nettverksovervåkings- og analyseverktøy for ytterligere kontekst.

Mange tilsynelatende mystiske problemer løses med grunnleggende feilsøkingsprosedyrer : gjennomgang av dokumentasjon, kontroll av filversjoner og datoer, reinstallering av viktige komponenter eller deaktivering av motstridende moduler. Å analysere dumpen gir oss en klar retning på hvor vi skal lete og sparer oss ofte for timer med prøving og feiling.

Det er også viktig å huske at i miljøer som det som forårsaket CrowdStrike Falcon- hendelsen og andre EDR-er, dreier de vanligste spørsmålene seg om hva som utløste BSOD-en og hvordan man raskt identifiserer den . Å ha WinDbg riktig konfigurert, med symboler og en tydelig prosedyre for å åpne og analysere dumpfiler, lar deg på få minutter begrense det som ellers ville ende med en "formatering og reinstallering" uten å egentlig forstå årsaken.

Kort sagt, en kombinasjon av en god minnedumpkonfigurasjon, disiplinert bruk av verktøy som WinDbg, Driver Verifier og Sysinternals, og vanen med å metodisk gjennomgå logger og stabler, gjør blåskjermbildene til en uforutsigbar fiende til en svært nøyaktig kilde til informasjon om hva som har feilet i kjernen , noe som hjelper oss å ta mye mer informerte tekniske beslutninger.