hjem › Internett › Installere og konfigurere WinDBG for å analysere minnedumper. Windows Debugging Tools: diagnostisere og fikse BSOD Debugging-verktøy for Windows-bruk

Installere og konfigurere WinDBG for å analysere minnedumper. Windows Debugging Tools: diagnostisere og fikse BSOD Debugging-verktøy for Windows-bruk

Når en kritisk feil oppstår, krasjer Windows-operativsystemet og viser en Blue Screen of Death (BSOD). Innhold tilfeldig tilgangsminne og all informasjon om feilen som oppstår skrives til swap-filen. Neste gang oppstart av Windows en crash dump opprettes c feilsøkingsinformasjon basert på lagrede data. En kritisk feiloppføring opprettes i systemets hendelseslogg.

Merk følgende! En krasjdump opprettes ikke hvis diskundersystemet svikter eller det oppstår en kritisk feil under den innledende fasen av Windows-oppstart.

Typer Windows Crash Dumps

Bruke det gjeldende operativsystemet Windows 10 som et eksempel ( Windows Server 2016) vurdere hovedtypene minnedumper som systemet kan lage:

Mini minnedump(256 KB). Denne filtypen inneholder en minimal mengde informasjon. Den inneholder bare BSOD-feilmeldingen, informasjon om driverne, prosessene som var aktive på tidspunktet for krasjet, og hvilken prosess eller kjernetråd som forårsaket krasjet.
Kjerneminnedump. Vanligvis liten i størrelse – en tredjedel av den fysiske minnestørrelsen. En kjerneminnedump er mer detaljert enn en minidump. Den inneholder informasjon om drivere og kjernemodusprogrammer, inkluderer minne allokert til Windows-kjernen og hardwareabstraksjonslaget (HAL), og minne allokert til drivere og andre kjernemodusprogrammer.
Fullfør minnedump. Den største i størrelse og krever minne som tilsvarer systemets RAM pluss 1 MB som kreves av Windows for å lage denne filen.
Automatisk minnedump. Tilsvarer en kjerneminnedump når det gjelder informasjon. Den eneste forskjellen er hvor mye plass den bruker for å lage dumpfilen. Denne filtypen fantes ikke i Windows 7. Den ble lagt til i Windows 8.
Aktiv minnedump. Denne typen eliminerer elementer som ikke kan fastslå årsaken til en systemfeil. Dette ble lagt til Windows 10 og er spesielt nyttig hvis du bruker en virtuell maskin, eller hvis systemet ditt er en Hyper-V-vert.

Hvordan aktiverer du minnedumping i Windows?

Bruk Win+Pause, åpne systeminnstillingsvinduet, velg " Ekstra alternativer systemer"(Avanserte systeminnstillinger). i " I tillegg" (Avansert), seksjon "" (Oppstart og gjenoppretting) klikk på knappen " Alternativer"(Innstillinger). I vinduet som åpnes, konfigurer handlinger som skal utføres når systemet svikter. Undersøk " Logg hendelser til systemloggen" (Skriv en hendelse til systemloggen), velg typen dump som skal opprettes når systemet krasjer. Hvis i avmerkingsboksen " Erstatt eksisterende dumpfil"(Overskriv en eksisterende fil) merk av i boksen, filen vil bli overskrevet hver gang det er en feil. Det er bedre å fjerne merket for denne boksen, da vil du ha mer informasjon for analyse. Deaktiver også Automatisk omstart.

I de fleste tilfeller vil en liten minnedump være nok til å analysere årsaken til BSOD.

Nå, når en BSOD oppstår, kan du analysere dumpfilen og finne årsaken til feilen. Minidumpen lagres som standard i mappen %systemroot%\minidump. For å analysere dumpfilen anbefaler jeg å bruke programmet WinDBG(Microsoft Kernel Debugger).

Installere WinDBG på Windows

Nytte WinDBG inkludert i " Windows 10 SDK"(Windows 10 SDK). .

Filen kalles winsdksetup.exe, størrelse 1,3 MB.

Kjør installasjonen og velg hva du vil gjøre - installer pakken på denne datamaskinen eller last den ned for installasjon på andre datamaskiner. La oss installere pakken på den lokale datamaskinen.

Du kan installere hele pakken, men for å installere bare feilsøkingsverktøyet, velg Feilsøkingsverktøy for Windows.

Etter installasjonen finner du WinDBG-snarveier i startmenyen.

Sette opp tilknytning av .dmp-filer med WinDBG

For å åpne dumpfiler med et enkelt klikk, tilordne .dmp-utvidelsen til WinDBG-verktøyet.

Åpen kommandolinje som administrator og kjør kommandoene for et 64-bitssystem: cd C:\Program Files (x86)\Windows Kits\10\Debuggers\x64
windbg.exe –IA
for 32-biters system:
C:\Program Files (x86)\Windows Kits\10\Debuggers\x86
windbg.exe –IA
Som et resultat vil filtypene: .DMP, .HDMP, .MDMP, .KDMP, .WEW tilordnes til WinDBG.

Sette opp en feilsøkingssymbolserver i WinDBG

Feilsøkingssymboler (feilsøkingssymboler eller symbolfiler) er blokker med data generert under kompileringen av et program sammen med den kjørbare filen. Slike datablokker inneholder informasjon om variabelnavn, kalt funksjoner, biblioteker osv. Disse dataene er ikke nødvendig når du kjører programmet, men er nyttige når du feilsøker det. Microsoft-komponenter er kompilert med symboler distribuert gjennom Microsoft Symbol Server.

Konfigurer WinDBG til Microsoft bruker Symbolserver:

Åpne WinDBG;
Gå til menyen Fil –> Symbol filbane;
Skriv en linje som inneholder URL-en for nedlasting av feilsøkingssymboler fra Microsofts nettsted og mappen for lagring av hurtigbufferen: SRV*E:\Sym_WinDBG*http://msdl.microsoft.com/download/symbols I eksemplet lastes cachen ned til mappen E:\Sym_WinDBG, kan du angi hvilken som helst.
Ikke glem å lagre endringer i menyen Fil–>Lagre WorkSpace;

WinDBG vil søke etter symboler i den lokale mappen, og hvis den ikke finner de nødvendige symbolene i den, vil den automatisk laste ned symbolene fra det angitte nettstedet. Hvis du vil legge til din egen symbolmappe, kan du gjøre det slik:

SRV*E:\Sym_WinDBG*http://msdl.microsoft.com/download/symbols;c:\Symbols

Hvis du ikke har en Internett-tilkobling, last først ned symbolpakken fra ressursen Windows Symbol Packages.

Analyse av en krasjdump i WinDBG

WinDBG-debuggeren åpner dumpfilen og laster ned de nødvendige symbolene for feilsøking fra en lokal mappe eller fra Internett. Du kan ikke bruke WinDBG under denne prosessen. Nederst i vinduet (på debugger-kommandolinjen) vises meldingen Debugee er ikke tilkoblet.

Kommandoer legges inn på kommandolinjen nederst i vinduet.

Det viktigste å være oppmerksom på er feilkoden, som alltid er angitt i heksadesimal og har formen 0xXXXXXXXXX(angitt i ett av alternativene - STOPP: , 07/02/2019 0008F, 0x8F). I vårt eksempel er feilkoden 0x139.

Debuggeren tilbyr å kjøre kommandoen!analyze -v, bare hold musen over lenken og klikk. Hva er denne kommandoen for?

Den utfører foreløpig minnedumpanalyse og gir detaljert informasjon for å starte analysen.
Denne kommandoen vil vise STOPP-koden og det symbolske navnet på feilen.
Den viser stabelen med kommandoanrop som førte til krasjet.
I tillegg vises IP-adresse, prosess- og registerfeil her.
Teamet kan gi ferdige anbefalinger for å løse problemet.

Hovedpunktene du bør være oppmerksom på når du analyserer etter å ha utført kommandoen!analyze –v (oppføringen er ufullstendig).

1: kd> !analysere -v

* *
* Feilsjekkanalyse *
* *
*****************************************************************************
Symbolsk navn på STOP-feil (BugCheck)
KERNEL_SECURITY_CHECK_FAILURE (139)
Beskrivelse av feilen (En kjernekomponent har ødelagt en kritisk datastruktur. Denne korrupsjonen kan potensielt tillate en angriper å få kontroll over denne maskinen):

En kjernekomponent har ødelagt en kritisk datastruktur. Korrupsjonen kan potensielt tillate en ondsinnet bruker å få kontroll over denne maskinen.
Feilargumenter:

Argumenter:
Arg1: 0000000000000003, A LIST_ENTRY har blitt ødelagt (dvs. dobbel fjerning).
Arg2: ffffd0003a20d5d0, Adresse til fellerammen for unntaket som forårsaket feilsjekken
Arg3: ffffd0003a20d528, Adresse til unntaksposten for unntaket som forårsaket feilsjekken
Arg4: 0000000000000000, reservert
Feilsøkingsdetaljer:
------------------

Telleren viser hvor mange ganger systemet krasjet med en lignende feil:

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: FAIL_FAST_CORRUPT_LIST_ENTRY

STOP-feilkode i forkortet format:

BUGCHECK_STR: 0x139

Prosessen der feilen oppstod (ikke nødvendigvis årsaken til feilen, akkurat på tidspunktet for feilen kjørte denne prosessen i minnet):

PROCESS_NAME: sqlservr.exe

Feilkodebeskrivelse: Systemet har oppdaget en stabelbufferoverflyt i denne applikasjonen, noe som kan tillate en angriper å få kontroll over denne applikasjonen.

ERROR_CODE: (NTSTATUS) 0xc0000409 - Systemet oppdaget et overløp av en stabelbasert buffer i denne applikasjonen. Denne overkjøringen kan potensielt tillate en ondsinnet bruker å få kontroll over denne applikasjonen.
EXCEPTION_CODE: (NTSTATUS) 0xc0000409 - Systemet oppdaget et overløp av en stabelbasert buffer i denne applikasjonen. Denne overkjøringen kan potensielt tillate en ondsinnet bruker å få kontroll over denne applikasjonen.

Siste samtale på stabelen:

LAST_CONTROL_TRANSFER: fra fffff8040117d6a9 til fffff8040116b0a0

Anropsstabel ved feiltidspunktet:

STACK_TEXT:
ffffd000`3a20d2a8 fffff804`0117d6a9: 00000000`00000139 00000000`00000003 ffffd000`3a20d5d0 ffffd000`28a20Checkt5K3a20Checkt5
ffffd000`3a20d2b0 fffff804`0117da50: ffffe000`f3ab9080 ffffe000`fc37e001 ffffd000`3a20d5d0 fffff804`0116e2a2a2: nt!Check6KiBpatch: nt!
FFFFD000`3A20D3F0 FFFFF804`0117C150: 00000000`0000000000 0000000000`0000000000 00000000`00000000 0000000000`00000000: NT! KifastfailDispatch+0xd0
ffffd000`3a20d5d0 fffff804`01199482: ffffc000`701ba270 ffffc000`00000001 000000ea`73f68040 fffff804`0000006f0000006f9ecurity:Railcurity+SecurityK3F9
ffffd000`3a20d760 fffff804`014a455d: 00000000`00000001 ffffd000`3a20d941 ffffe000`fcacb000 ffffd000`3a20nt951: ?? ::FNODOBFM::`string"+0x17252
ffffd000`3a20d8c0 fffff804`013a34ac: 00000000`00000004 00000000`00000000 ffffd000`3a20d9d8 ffffe001`0a34c60Service:0a34c60
ffffd000`3a20d990 fffff804`0117d313: ffffffff`fffffffe 00000000`00000000 00000000`00000000 000000eb`a0cf1380:Writnt1380:W1380
ffffd000`3a20da90 00007ffb`475307da: 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 0000000000 0000000000 0000000000
000000ee`f25ed2b8 00000000`00000000: 00000000`00000000 00000000`00000000 00000000`000000000: 00000000`00000000 00000000`00000000 00000000`000000000 0 7da

Kodedelen der feilen oppsto:

FOLLOWUP_IP:
nt!KiFastFailDispatch+d0
fffff804`0117da50 c644242000 mov byte ptr ,0
FAULT_INSTR_CODE: 202444c6
SYMBOL_STACK_INDEX: 2
SYMBOL_NAME: nt!KiFastFailDispatch+d0
FOLLOWUP_NAME: Maskineier

Navnet på modulen i kjerneobjekttabellen. Hvis analysatoren var i stand til å oppdage problematisk sjåfør, navnet vises i MODULE_NAME- og IMAGE_NAME-feltene:

MODULE_NAME:nt
IMAGE_NAME: ntkrnlmp.exe

1: kd> lmvm nt
Bla gjennom hele modullisten
Lastet symbolbildefil: ntkrnlmp.exe
Tilordnet minnebildefil: C:\ProgramData\dbg\sym\ntoskrnl.exe\5A9A2147787000\ntoskrnl.exe
Bildebane: ntkrnlmp.exe
Bildenavn: ntkrnlmp.exe
Internt navn: ntkrnlmp.exe
Opprinnelig filnavn: ntkrnlmp.exe
Produktversjon: 6.3.9600.18946
Filversjon: 6.3.9600.18946 (winblue_ltsb_escrow.180302-1800)

I eksemplet som ble gitt, pekte analysen på kjernefilen ntkrnlmp.exe. Når minnedumpanalyse peker på en systemdriver (som win32k.sys) eller en kjernefil (som i vårt eksempel ntkrnlmp.exe), er det mest sannsynlig denne filen er ikke årsaken til problemet. Svært ofte viser det seg at problemet ligger i enhetsdriveren, BIOS-innstillinger eller utstyrsfeil.

Hvis du ser at BSOD ble forårsaket av en tredjeparts driver, vil navnet bli angitt i MODULE_NAME- og IMAGE_NAME-verdiene.

For eksempel:

Bildebane: \SystemRoot\system32\drivers\cmudaxp.sys
Bildenavn: cmudaxp.sys

Åpne egenskapene til driverfilen og sjekk versjonen. I de fleste tilfeller løses problemet med drivere ved å oppdatere dem.

den 22. juni 2010

Tidligere var Windbg tilgjengelig separat for nedlasting. Men for de nyeste versjonene beholder Microsoft den som en del av Windows SDK. Vennligst finn nedlastingslenkene nedenfor.

Windows 10

Den nyeste versjonen av Windbg for Windows 7 kan lastes ned fra lenken https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk

Windows 7

Last ned installasjonsprogrammer fra koblingene ovenfor. Merk at dette ikke laster ned hele SDK, det er bare et installasjonsprogram. Når du kjører filen, du kan velg hvilke verktøy du vil lastes ned. Hvis du bare er interessert i Windbg, kan du ekskludere alt annet og bare velge "Feilsøkingsverktøy" under "Common Utilities"

Pakken ovenfor installerer windbg 6.12-versjonen. Hvis du vil hurtiginstallere windbg, kan du gå for eldre versjon (6.11) som kan lastes ned fra
lenken som er gitt på slutten av dette innlegget.

Når du har utført installasjonen, kan du finne programmet i Start-menyen -> Alle programmer -> Feilsøkingsverktøy for Windows -> Windbg

Vi introduserer WinDBG - del 1

Alexander Antipov

WinDBG er en utmerket debugger. Den har kanskje ikke et veldig brukervennlig grensesnitt og har ikke svart bakgrunn som standard, men det er en av de kraftigste og mest stabile feilsøkerne på Windows OS for tiden. I denne artikkelen vil jeg introdusere deg til det grunnleggende om WinDBG slik at du kan komme i gang med det.

Dette er den første artikkelen i en serie dedikert til WinDBG. Liste over alle artiklene som er inkludert i denne serien:

Del 1 – installasjon, grensesnitt, symboler, ekstern/lokal feilsøking, hjelpesystem, moduler, registre.
Del 2 – bruddpunkter.
Del 3 – minneinspeksjon, trinn-for-steg programfeilsøking, tips og triks.

I denne artikkelen skal vi se på installasjon og feste til en prosess, og i de følgende artiklene skal vi se på bruddpunkter, trinn-for-trinn feilsøking og minneinspeksjon.

Installerer WinDBG

Sammenlignet med Windows 7 har installasjonsprosessen for WinDBG i Windows 8 gjennomgått mindre endringer. I denne delen skal vi se på installering av en feilsøker for begge operativsystemer.

Installere WinDBG på Windows 8

I Windows 8 er WinDBG inkludert i Windows Driver Kit (WDK). Du kan installere Visual Studio og WDK, eller installere pakken Feilsøkingsverktøy for Windows 8.1 separat, som inkluderer WinDBG.

Installasjonsprogrammet vil spørre om du vil installere WinDBG lokalt eller laste ned hele utviklingspakken for en annen datamaskin. Sistnevnte er i hovedsak ekvivalent offline installasjonsprogram, noe som er veldig praktisk hvis du ønsker å installere pakken på andre systemer i fremtiden.

Figur 1: Velge installasjonstype

I det neste vinduet må du fjerne merket for alle elementene bortsett fra "Feilsøkingsverktøy for Windows" og klikke på "Last ned" -knappen.

Når installasjonsprogrammet har fullført arbeidet, går du til katalogen der pakken ble lastet ned (som standard er det c:\Users\Username\Downloads\Windows Kits\8.1\StandaloneSDK) og gå gjennom installasjonsprosedyren.

Installere WinDBG på Windows 7 og tidligere

For Windows 7 og tidligere er WinDBG en del av "Debugging Tools for Windows"-pakken som følger med Windows SDK og .Net Framework. Du må laste ned installasjonsprogrammet og deretter velge "Feilsøkingsverktøy for Windows" under installasjonsprosessen.

Under installasjonen velger jeg alternativet "Debugging Tools" under "Redistribuerbare pakker" for å lage et frittstående installasjonsprogram for å gjøre fremtidige installasjoner enklere.

Figur 2: Velge installasjonsalternativer for å lage et frittstående installasjonsprogram

Når installasjonen er fullført, bør du ha WinDBG-installasjonsprogrammer for ulike plattformer (i katalogen c:\Program Files\Microsoft SDKs\Windows\v7.1\Redist\Debugging Tools for Windows\).

Figur 3: Mappe med WinDBG-installatører for ulike plattformer

WinDBG-grensesnitt

Figur 4: WinDBG-utseende

Første gang du ser utseende WinDGB, vil du innse at debuggeren er skremmende enkel. De fleste WinDBG-funksjoner læres under prosessfeilsøking. I stedet for å bruke tid på å beskrive grensesnittet, vil vi i de følgende delene kun dekke de viktigste punktene.

Det mest grunnleggende du trenger å vite om feilsøkingsgrensesnittet er kommandovinduet, som består av to områder. Første område: et vindu der resultatet av kommandoutførelse vises. Andre område: et lite tekstfelt for å legge inn kommandoer.

Figur 5: WinDBG kommandovindu

Symboler

I de fleste tilfeller krever ikke WinDBG noen spesielle innstillinger og fungerer korrekt ut av esken. Men en viktig ting som må konfigureres er karakterene. Symboler er filer som genereres sammen med den kjørbare filen når et program kompileres og inneholder feilsøkingsinformasjon (funksjoner og variabelnavn). Feilsøkingsinformasjon lar deg undersøke funksjonaliteten til en applikasjon mens du feilsøker eller demonterer. Mange Microsoft-komponenter er kompilert med symboler som distribueres gjennom Microsoft Symbol Server. Med resten av de kjørbare filene er ikke alt så rosenrødt - svært sjelden filer med feilsøkingsinformasjon er inkludert i applikasjonen. I de fleste tilfeller begrenser selskaper tilgangen til slik informasjon.

For å konfigurere WinDBG til å bruke Microsoft Symbol Server, gå til File:Symbol File Path og sett banen til SRV*C:\Symbols*http://msdl.microsoft.com/download/symbols. Det er selvfølgelig litt rart at stjerner brukes som skilletegn. Etter at du har konfigurert Microsoft Symbol Server, vil symbolene bli lastet ned til mappen C:\Symbols.

Figur 6: Sette opp Microsoft Symbol Server

WinDBG vil automatisk laste inn symboler for binære filer ved behov. Du kan også legge til din egen symbolmappe, slik:

SRV*C:\Symbols*http://msdl.microsoft.com/download/symbols;c:\SomeOtherSymbolFolder

Legge til symboler under feilsøking

Hvis du trenger å importere symboler mens du feilsøker, kan du gjøre dette ved å bruke .sympath (et kommandovindu vises når du kobler deg inn i prosessen). For å legge til mappen c:\SomeOtherSymbolFolder, skriv inn følgende kommando:

0:025> .sympath+ c:\SomeOtherSymbolFolder
Symbolsøkebanen er: SRV*C:\Symbols*http://msdl.microsoft.com/download/symbols;c:\SomeOtherSymbolFolder
Utvidet symbolsøkebane er: srv*c:\symbols*http://msdl.microsoft.com/download/symbols;c:\someothersymbolfolder

Det er en god idé å laste inn symbolene på nytt etter at du har lagt til eller endret stier:

0:025> .last på nytt
Lasting av gjeldende moduler
................................................................
...............................................

Kontrollerer innlastede symboler

For å se hvilke moduler som har symboler lastet, kan du bruke x*!-kommandoen. Selv om WinDBG bare laster inn symboler etter behov, er x*! vil vise symbolene som kan lastes inn. Du kan tvinge symbolene til å lastes ved å bruke ld *-kommandoen (dette kan ta en stund, og du kan stoppe prosessen ved å gå til Debug:Break).

Nå kan vi se symbolene for hver modul.

Figur 8: Liste over symboler

Feilsøking av en lokal prosess

Når du feilsøker en lokal prosess, har du to alternativer:

Koble deg til en allerede pågående prosess.
Start prosessen via WinDBG.

Hver metode har sine egne fordeler og ulemper. Hvis du for eksempel kjører et program gjennom WinDBG, så har du tilgang til noen spesielle feilsøkingsalternativer (for eksempel heap-debugging) som kan føre til at applikasjonen krasjer. På den annen side er det også programmer som krasjer når du kobler en debugger til dem. Noen applikasjoner (spesielt skadelig programvare) sjekker for tilstedeværelsen av en debugger i systemet under oppstart, og følgelig er det i dette tilfellet fornuftig å klamre seg til en allerede kjørende prosess. Noen ganger feilsøker du en Windows-tjeneste som setter noen parametere under oppstart, så for å forenkle feilsøkingsprosessen er det også bedre å koble seg til en kjørende prosess i stedet for å kjøre tjenesten gjennom en debugger. Noen mennesker hevder at å kjøre en prosess gjennom en feilsøker har en alvorlig innvirkning på ytelsen. Kort sagt, prøv begge deler og velg det som passer deg best. Hvis du av en eller annen grunn foretrekker en bestemt metode, del tankene dine i kommentarene!

Starter prosessen

Hvis du feilsøker et frittstående program som kjører lokalt og ikke kommuniserer med nettverket, vil du kanskje kjøre det gjennom WinDBG. Dette betyr imidlertid ikke at du ikke kan koble til en allerede pågående prosess. Velg metoden som passer best for deg.

Å starte prosessen er ikke vanskelig. Gå til "File: Open Executable" og velg den kjørbare filen du vil feilsøke. Du kan også spesifisere argumenter eller angi startkatalogen:

Figur 9: Utvalg kjørbar fil for feilsøking

Prosessforbindelse

Å koble til en allerede pågående prosess er heller ikke vanskelig. Vær imidlertid oppmerksom på at det i noen tilfeller kan ta tid å finne den nøyaktige prosessen du vil feilsøke. For eksempel oppretter noen nettlesere én overordnet prosess og deretter flere prosesser for hver fane. Så, avhengig av krasjdumpen du feilsøker, vil du kanskje koble deg inn i prosessen knyttet til fanen i stedet for den overordnede prosessen.

For å koble til en allerede kjørende prosess, gå til "Fil: Legg ved en prosess" og velg deretter PID eller navnet på prosessen. Husk at du må ha de nødvendige rettighetene for å delta i prosessen.

Figur 10: Velge prosessen som skal kobles til

Hvis applikasjonen pauser driften etter tilkobling, kan du bruke "Noninvaise"-modus ved å merke av i den aktuelle boksen.

Feilsøking av en ekstern prosess

Noen ganger må du feilsøke en prosess på et eksternt system. Det ville være mye mer praktisk å løse dette problemet ved å bruke en lokal debugger, i stedet for å bruke virtuell maskin eller RDP. Eller kanskje du feilsøker LoginUI.exe-prosessen, som bare er tilgjengelig når systemet er låst. I situasjoner som disse kan du bruke en lokal versjon av WinDBG og koble til prosesser eksternt. Det er to vanligste måter å løse disse problemene på.

Eksisterende feilsøkingsøkter

Hvis du allerede har begynt å feilsøke et program lokalt (ved å koble til eller kjøre en prosess gjennom WinDBG), kan du skrive inn en spesifikk kommando og WinDBG vil starte en "lytter" som den eksterne debuggeren kan koble til. For å gjøre dette, bruk .server-kommandoen:

Server tcp:port=5005

Etter å ha kjørt kommandoen ovenfor, kan du se en advarsel som denne:

Figur 11: Advarselsmelding som kan vises etter å ha kjørt kommandoen for å opprette en lytter

WinDBG vil da rapportere at serveren kjører:

0:005> .server tcp:port=5005
0: -fjernkontroll tcp:Port=5005,Server=BRUKER-PC

Du kan nå koble fra en ekstern vert til en eksisterende feilsøkingsøkt ved å gå til "Fil:Koble til en ekstern sesjon" og skrive inn noe sånt som følgende i tekstfeltet: tcp:Port=5005,Server=192.168.127.138

Figur 12: Ekstern tilkobling til en feilsøkingsøkt

Når du er koblet til, vil du motta bekreftelse på den eksterne klienten:

Server startet. Klienten kan koble seg til hvilken som helst av disse kommandolinjene
0: -fjernkontroll tcp:Port=5005,Server=BRUKER-PC
MACHINENAME\User (tcp 192.168.127.138:13334) koblet til mandag 16. desember 09:03:03 2013

og meldingen i den lokale versjonen av feilsøkeren:

MACHINENAME\User (tcp 192.168.127.138:13334) koblet til mandag 16. desember 09:03:03 2013

Opprette en ekstern server

Du kan også opprette en egen server med WinDBG, koble til den eksternt og velge en prosess som skal feilsøkes. Dette kan gjøres ved å bruke dbgsrv.exe-filen der du planlegger å feilsøke prosesser. For å starte en slik server, kjør følgende kommando:

dbgsrv.exe -t tcp:port=5005

Figur 13: Starte en ekstern server

Igjen kan du motta en sikkerhetsadvarsel som du bør godta:

Figur 14: Sikkerhetsmelding som kan vises under oppstart av feilsøkingsserveren

Du kan koble til feilsøkingsserveren ved å gå til Fil: Koble til Remote Stub og skrive inn følgende linje i tekstfeltet: tcp:Port=5005,Server=192.168.127.138

Figur 15: Kobler til feilsøkingsserveren

Når du er koblet til, vil du ikke motta noen signaler om at du har koblet til, men hvis du går til "Fil: Legg ved en prosess", vil du se en liste over feilsøkingsserverprosesser (der dbgsrv.exe kjører). Nå kan du koble deg inn i prosessen som om du gjorde det lokalt.

Hjelpesystem

Hjelpesystemet i WinDBG er flott. I tillegg til å lære noe nytt, bør du kunne få bakgrunnsinformasjon om en kommando. Bruk .hh-kommandoen for å få tilgang til WinDBG Help:

Du kan også få hjelpeinformasjon for en bestemt kommando. For eksempel, for å få hjelp med .reload-kommandoen, bruk følgende kommando:

windbg> .hh .reload

Eller bare gå til Help:Content-delen.

Moduler

Mens programmet kjører, importeres ulike moduler for å gi applikasjonens funksjonalitet. Derfor, hvis du vet hvilke moduler som importeres av applikasjonen, kan du bedre forstå hvordan det fungerer. I mange tilfeller vil du feilsøke den spesifikke modulen som er lastet av programmet, i stedet for selve den kjørbare filen.

Når den er koblet til prosessen, vil WinDBG automatisk vise de innlastede modulene. Nedenfor er for eksempel modulene etter at jeg koblet til calc.exe:

Microsoft (R) Windows Debugger versjon 6.12.0002.633 X86
Copyright (c) Microsoft Corporation. Alle rettigheter forbeholdt.

*** vent med ventende vedlegg
Symbolsøkestien er: SRV*C:\Symbols*http://msdl.microsoft.com/download/symbols
Kjørbar søkebane er:
ModLoad: 00a70000 00b30000 C:\Windows\system32\calc.exe
ModLoad: 77630000 7776c000 C:\Windows\SYSTEM32\ntdll.dll
ModLoad: 77550000 77624000 C:\Windows\system32\kernel32.dll
ModLoad: 75920000 7596a000 C:\Windows\system32\KERNELBASE.dll
ModLoad: 76410000 77059000 C:\Windows\system32\SHELL32.dll
ModLoad: 77240000 772ec000 C:\Windows\system32\msvcrt.dll
ModLoad: 76300000 76357000 C:\Windows\system32\SHLWAPI.dll
ModLoad: 75cd0000 75d1e000 C:\Windows\system32\GDI32.dll
ModLoad: 75fa0000 76069000 C:\Windows\system32\USER32.dll
ModLoad: 777b0000 777ba000 C:\Windows\system32\LPK.dll
ModLoad: 774b0000 7754d000 C:\Windows\system32\USP10.dll
ModLoad: 73110000 732a0000 C:\Windows\WinSxS\x86_microsoft.windows.gdiplus_
6595b64144ccf1df_1.1.7600.16385_none_72fc7cbf861225ca\gdiplus.dll
ModLoad: 75a80000 75bdc000 C:\Windows\system32\ole32.dll
ModLoad: 76360000 76401000 C:\Windows\system32\RPCRT4.dll
ModLoad: 777c0000 77860000 C:\Windows\system32\ADVAPI32.dll
ModLoad: 75be0000 75bf9000 C:\Windows\SYSTEM32\sechost.dll
ModLoad: 76270000 762ff000 C:\Windows\system32\OLEAUT32.dll
ModLoad: 74590000 745d0000 C:\Windows\system32\UxTheme.dll
ModLoad: 74710000 748ae000 C:\Windows\WinSxS\x86_microsoft.windows.common-
ModLoad: 703d0000 70402000 C:\Windows\system32\WINMM.dll
ModLoad: 74c80000 74c89000 C:\Windows\system32\VERSION.dll
ModLoad: 77770000 7778f000 C:\Windows\system32\IMM32.DLL
ModLoad: 75c00000 75ccc000 C:\Windows\system32\MSCTF.dll
ModLoad: 74130000 7422b000 C:\Windows\system32\WindowsCodecs.dll
ModLoad: 74260000 74273000 C:\Windows\system32\dwmapi.dll
ModLoad: 756d0000 756dc000 C:\Windows\system32\CRYPTBASE.dll
ModLoad: 75e60000 75ee3000 C:\Windows\system32\CLBCatQ.DLL
ModLoad: 6ef10000 6ef4c000 C:\Windows\system32\oleacc.dll

Senere i feilsøkingsprosessen kan du vise denne listen igjen ved å bruke lmf-kommandoen:

0:005>lmf
start slutt modul navn
00a70000 00b30000 calc C:\Windows\system32\calc.exe
6ef10000 6ef4c000 oleacc C:\Windows\system32\oleacc.dll
703d0000 70402000 WINMM C:\Windows\system32\WINMM.dll
73110000 732a0000 gdiplus C:\Windows\WinSxS\x86_microsoft.windows.gdiplus_6595b64144ccf1df_
1.1.7600.16385_none_72fc7cbf861225ca\gdiplus.dll
74130000 7422b000 WindowsCodecs C:\Windows\system32\WindowsCodecs.dll
74260000 74273000 dwmapi C:\Windows\system32\dwmapi.dll
74590000 745d0000 UxTheme C:\Windows\system32\UxTheme.dll
74710000 748ae000 COMCTL32 C:\Windows\WinSxS\x86_microsoft.windows.common-
controls_6595b64144ccf1df_6.0.7600.16385_none_421189da2b7fabfc\COMCTL32.dll
74c80000 74c89000 VERSJON C:\Windows\system32\VERSION.dll
756d0000 756dc000 CRYPTBASE C:\Windows\system32\CRYPTBASE.dll
75920000 7596a000 KERNELBASE C:\Windows\system32\KERNELBASE.dll
75a80000 75bdc000 ole32 C:\Windows\system32\ole32.dll
75be0000 75bf9000 sechost C:\Windows\SYSTEM32\sechost.dll
75c00000 75ccc000 MSCTF C:\Windows\system32\MSCTF.dll
75cd0000 75d1e000 GDI32 C:\Windows\system32\GDI32.dll
75e60000 75ee3000 CLBCatQ C:\Windows\system32\CLBCatQ.DLL
75fa0000 76069000 USER32 C:\Windows\system32\USER32.dll
76270000 762ff000 OLEAUT32 C:\Windows\system32\OLEAUT32.dll
76300000 76357000 SHLWAPI C:\Windows\system32\SHLWAPI.dll
76360000 76401000 RPCRT4 C:\Windows\system32\RPCRT4.dll
76410000 77059000 SHELL32 C:\Windows\system32\SHELL32.dll
77240000 772ec000 msvcrt C:\Windows\system32\msvcrt.dll
774b0000 7754d000 USP10 C:\Windows\system32\USP10.dll
77550000 77624000 kernel32 C:\Windows\system32\kernel32.dll
77630000 7776c000 ntdll C:\Windows\SYSTEM32\ntdll.dll
77770000 7778f000 IMM32 C:\Windows\system32\IMM32.DLL
777b0000 777ba000 LPK C:\Windows\system32\LPK.dll
777c0000 77860000 ADVAPI32 C:\Windows\system32\ADVAPI32.dll

Du kan også finne ut lasteadressen for en spesifikk modul ved å bruke "lmf m"-kommandoen:

0:005> lmf m kernel32
start slutt modul navn
77550000 77624000 kernel32 C:\Windows\system32\kernel32.dll

Du kan også få informasjon om bildeoverskriften til en bestemt modul ved å bruke!dh-utvidelsen ( Utropstegn indikerer en utvidelse):

0:005> !dh kjerne32

Filtype: DLL
VERDIER FOR FILOVERSKRIFT
14C-maskin (i386)
4 antall seksjoner
4A5BDAAD tidsdatostempel man 13. jul 21:09:01 2009

0 filpeker til symboltabell
0 antall symboler
E0 størrelse på valgfri topptekst
2102 egenskaper
Kjørbar
32-biters ordmaskin
DLL

VALGFRI OVERSKRIFTVERDIER
10B magisk #
9.00 linkerversjon
C4600 størrelse på kode
C800-størrelsen på initialiserte data
0 størrelse på uinitialiserte data
510C5-adressen til inngangspunktet
1000 grunnkode
----- ny -----
77550000 bildebase
1000 seksjonsjustering
200 filjustering
3 undersystem (Windows CUI)
6.01 operativsystemversjon
6.01 bildeversjon
6.01 undersystemversjon
D4000 størrelse på bildet
800 størrelse på overskrifter
D5597 kontrollsum
00040000 størrelse på stabelreserve
00001000 størrelsen på stabelen
00100000 størrelse på haugreserve
00001000 størrelse på heap commit
140 DLL-egenskaper
Dynamisk base
NX-kompatibel
B4DA8 [ A915] adresse til eksportkatalog
BF6C0 [ 1F4] adresse til Import Directory
C7000 [520]-adressen til ressurskatalogen
0 [ 0] adressen til unntakskatalogen
0 [ 0] adressen til sikkerhetskatalogen
C8000 [B098] adresse til Base Relocation Directory
C5460 [ 38] adresse til feilsøkingskatalogen
0 [ 0] adresse til beskrivelseskatalog
0 [ 0] adresse til Special Directory
0 [ 0] adresse til trådlagringskatalog
816B8 [ 40] adressen til Load Configuration Directory
278 [408] adresse til Bound Import Directory
1000 [DE8]-adressen til Import Address Table Directory
0 [ 0] adressen til Delay Import Directory
0 [ 0] adresse til COR20 Header Directory
0 [ 0] adresse til reservert katalog

SEKSJONTODER #1
.tekstnavn
C44C1 virtuell størrelse
1000 virtuell adresse
C4600-størrelsen på rådata
800 fil peker til rådata

0 antall flyttinger
0 antall linjenumre
60000020 flagg
Kode
(ingen justering er spesifisert)
Utfør Les

Feilsøkingskataloger (2)
Type Størrelse Adressepeker
cv 25 c549c c4c9c Format: RSDS, guide, 2, kernel32.pdb
(10) 4 c5498 c4c98

SEKSJONTODER #2
.datanavn
FEC virtuell størrelse
C6000 virtuell adresse
E00 størrelse på rådata
C4E00 filpeker til rådata
0 filpeker til flyttetabell
0 fil peker til linjenummer
0 antall flyttinger
0 antall linjenumre
C0000040 flagg
Initialiserte data
(ingen justering er spesifisert)
Les Skriv

SEKSJONTODER #3
.rsrc navn
520 virtuell størrelse
C7000 virtuell adresse
600 størrelse på rådata
C5C00-filpeker til rådata
0 filpeker til flyttetabell
0 fil peker til linjenummer
0 antall flyttinger
0 antall linjenumre
40000040 flagg
Initialiserte data
(ingen justering er spesifisert)
Kun lesetilgang

SEKSJONTODER #4
.reloc navn
B098 virtuell størrelse
C8000 virtuell adresse
B200 størrelse på rådata
C6200-filpeker til rådata
0 filpeker til flyttetabell
0 fil peker til linjenummer
0 antall flyttinger
0 antall linjenumre
42000040 flagg
Initialiserte data
Kan kasseres
(ingen justering er spesifisert)
Kun lesetilgang

Meldinger og unntak

Etter tilkobling til en prosess, vises først en liste over moduler, og deretter kan andre meldinger vises. For eksempel, når vi kobler til calc.exe, setter WinDBG automatisk et bruddpunkt (som ganske enkelt er en markør som brukes til å stoppe applikasjonen). Informasjon om bruddpunkt vises på skjermen:

(da8.b44): Unntak for pauseinstruksjon - kode 80000003 (første sjanse)

Denne spesielle meldingen er et unntak, nemlig et første sjanse unntak. I hovedsak er et unntak en spesiell tilstand som oppstår under kjøringen av et program. Et førstegangsunntak betyr at programmet stoppet umiddelbart etter at unntaket inntraff. Andre sjanse-unntak betyr at etter at unntaket oppstår, vil noen operasjoner bli utført, og da slutter programmet å fungere.

Registrerer

Etter å ha vist meldinger og unntak, viser feilsøkeren tilstanden til prosessorregistrene. Registre er spesielle variabler inne i prosessoren som lagrer små informasjonsbiter eller overvåker tilstanden til noe i minnet. Behandleren kan behandle informasjonen i disse registrene svært raskt. Dette er mye raskere enn å få informasjon over bussen fra RAM hver gang.

Etter tilkobling til calc.exe, viser WinDBG automatisk informasjon om følgende registre:

eax=7ffd9000 ebx=00000000 ecx=00000000 edx=776cd23d esi=00000000 edi=00000000
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246

Du kan duplisere denne informasjonen igjen senere ved å bruke r-kommandoen:

0:005>r
eax=7ffd9000 ebx=00000000 ecx=00000000 edx=776cd23d esi=00000000 edi=00000000
eip=77663540 esp=02affd9c ebp=02affdc8 iopl=0 nv up ei pl zr na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246
ntdll!DbgBreakPoint:
77663540 cc int 3

Hvis vi ønsker å få verdien av et spesifikt register, kan vi kjøre følgende kommando:

0:005> r eax
eax=7ffd9000

Informasjon kan hentes samtidig fra flere registre som følger:

0:005> r eax,ebp
eax=7ffd9000 ebp=02affdc8

Peker til instruksjon

Den siste kommandoen handler om instruksjonene for å kjøre. Her vises også informasjonen på skjermen, som ved r-kommandoen, om hva EIP-registeret inneholder. EIP er et register som inneholder plasseringen av neste instruksjon som skal utføres av prosessoren. Det WinDBG viser tilsvarer kommandoen u eip L1, hvoretter WinDBG går til adressen spesifisert i EIP-registeret, konverterer denne delen til monteringskode og viser den på skjermen.

ntdll!DbgBreakPoint:
77663540 cc int 3

holde kontakten

I fremtidige artikler skal vi se på hvordan du bruker WinDBG i feltet: bruddpunkter, trinnvis feilsøking og minnesurfing. Ikke bytt! J.

Feilsøkingsverktøy for Windows- Verktøy for feilsøking av driftskoder Windows-systemer. De er et sett med fritt distribuerte programmer fra Microsoft designet for feilsøking av brukermodus og kjernemoduskode: applikasjoner, drivere, tjenester, kjernemoduler. Verktøysettet inkluderer feilsøkere for konsoll- og GUI-modus, verktøy for å jobbe med symboler, filer, prosesser og verktøy for ekstern feilsøking. Verktøysettet inneholder verktøy som kan brukes til å finne årsakene til feil i ulike systemkomponenter. Feilsøkingsverktøy for Windows fra et visst tidspunkt og fremover ikke er tilgjengelig for nedlasting i form av en frittstående distribusjon og er en del av Windows SDK (Windows Software Development Kit). Sett med instrumental Windows-verktøy SDK-en er på sin side tilgjengelig som en del av MSDN-abonnementsprogrammet eller kan fritt lastes ned som en separat distribusjon fra msdn.microsoft.com. Ifølge utviklerne, det nyeste og mest gjeldende versjon Feilsøkingsverktøy for Windows finnes spesifikt i Windows SDK.

Feilsøkingsverktøy for Windows oppdateres og gjøres offentlig tilgjengelig ganske ofte, og denne prosessen avhenger ikke på noen måte av utgivelsen av operativsystemer. Sjekk derfor med jevne mellomrom for nye versjoner.

La oss nå se hva, spesielt, feilsøkingsverktøyene for Microsoft Windows:

Feilsøk lokale applikasjoner, tjenester, drivere og kjerne;
Feilsøk eksterne applikasjoner, tjenester, drivere og kjerne over nettverket;
Feilsøk kjørende applikasjoner i sanntid;
Analyser minnedumpfiler for applikasjoner, kjernen og systemet som helhet;
Arbeid med systemer basert på x86/x64/Itanium-arkitekturer;
Feilsøk brukermodus og kjernemodusprogrammer;

Følgende versjoner av feilsøkingsverktøy for Windows er tilgjengelige: 32-bit x86, Intel Itanium, 64-bit x64. Vi trenger to av dem: x86 eller x64.

Det er flere måter å installere feilsøkingsverktøy for Windows på; i denne artikkelen vil vi kun vurdere de viktigste:

Installasjon via nettinstallasjonsprogram.
Installere feilsøkingsverktøy for Windows fra ISO Windows-bilde SDK.
Installere feilsøkingsverktøy for Windows direkte fra dbg_amd64.msi / dbg_x86.msi-pakkene.

Det er fortsatt uklart på hvilket tidspunkt, hvorfor skal jeg installere feilsøkingsverktøy på datamaskinen min? Ofte står du overfor en situasjon hvor innblanding i arbeidsmiljøet er ekstremt uønsket! Og enda mer, å installere et nytt produkt, det vil si å gjøre endringer i registeret/systemfilene, kan være helt uakseptabelt. Eksempler inkluderer oppdragskritiske servere. Hvorfor vurderer ikke utviklere muligheten for bærbare versjoner av applikasjoner som ikke krever installasjon?
Fra versjon til versjon gjennomgår installasjonsprosessen av Feilsøkingsverktøy for Windows-pakken noen endringer. La oss nå gå direkte til installasjonsprosessen og se på måtene du kan installere verktøysettet på.

Installere feilsøkingsverktøy for Windows ved hjelp av nettinstallasjonsprogrammet

Gå til Windows SDK-arkivsiden og finn en seksjon kalt Windows 10 og under elementet "Windows 10 SDK (10586) og enhetsemulator med Windows 10 Mobile (Microsoft) (versjon 10586.11)".

Klikk på elementet INSTALL SDK. Etter å ha klikket, last ned og kjør filen sdksetup.exe, som starter den elektroniske installasjonsprosessen av Windows SDK. I det innledende stadiet vil installasjonsprogrammet sjekke om .NET Framework-pakken er installert på systemet siste versjon(V dette øyeblikket dette er 4,5). Hvis pakken mangler, vil installasjonen bli tilbudt og stasjonen vil starte på nytt når den er fullført. Umiddelbart etter omstart, på brukerautorisasjonsstadiet, starter installasjonsprosessen av selve Windows SDK.

Ofte, når du velger alle komponentene i en pakke uten unntak, kan det oppstå feil under installasjonsprosessen. I dette tilfellet anbefales det å installere komponenter selektivt, minimumskravet.

Etter at installasjonen av feilsøkingsverktøy for Windows er fullført, vil plasseringen av feilsøkingsfilene når denne metoden Vår installasjon vil være som følger:

64-biters versjoner: C:\Program Files (x86)\Windows Kits\x.x\Debuggers\x64
32-biters versjoner: C:\Program Files (x86)\Windows Kits\x.x\Debuggers\x86

* hvor x.x er en spesifikk versjon av utviklingssettet;
Vi la merke til at versjon 8 og høyere, installasjonsveiene er merkbart forskjellige fra de klassiske for alle tidligere versjoner Feilsøkingsverktøy?

Et stort pluss denne metoden Installering av feilsøkingsverktøy for Windows innebærer å installere versjoner av feilsøkingsverktøy for alle arkitekturer samtidig.

Installere feilsøkingsverktøy for Windows fra Windows SDK ISO

Denne metoden innebærer å installere feilsøkingsverktøy for Windows ved å bruke hele installasjonsbildet for Windows SDK (Software Developers Kit). Last ned inntil et bestemt tidspunkt ISO-bilde for det tilsvarende systemet var det mulig på Windows SDK-arkivsiden. For øyeblikket kan du imidlertid få et ISO-bilde av SDK ved å kjøre nettinstallasjonsprogrammet sdksetup.exe og velge Last ned Windows Software Development Kit i installasjonsprogrammets startvindu:

Som vi fant ut, er den forrige installasjonsmetoden ved å bruke et nettinstallasjonsprogram ganske lunefull og ender ofte med feil. På rene systemer installeres den uten problemer, men på tilstrekkelig belastede systemer oppstår det mange problemer. Hvis dette er ditt tilfelle, bruk denne metoden.

Følgelig, på siden må du velge den nødvendige distribusjonen, for meg (og jeg tror for mange) for øyeblikket er det "Windows SDK for Windows 7 og .NET Framework 4" og rett under klikk på lenken "Få en ISO bilde av en DVD".

Når du jobber med nettstedet msdn.microsoft.com, anbefaler jeg å bruke en nettleser Internet Explorer, siden det har vært tilfeller av konkurrerende produkter som ikke fungerer!

Følgelig er det nødvendig å velge utelukkende etter nødvendighet. Vanligvis samsvarer bitheten til Debugging Tools for Windows med bitheten til systemet. Mine systemer er for det meste 64-bit, så i de fleste tilfeller laster jeg ned bildet for et 64-bit system GRMSDKX_EN_DVD.iso.
Så, etter å ha lastet ned bildet, må vi på en eller annen måte jobbe med det eksisterende ISO-bildet. Den tradisjonelle metoden er selvfølgelig å brenne en CD, men dette er en ganske lang og noen ganger kostbar metode. Jeg foreslår at du bruker gratis verktøy for å lage virtuelle diskenheter i systemet. Personlig foretrekker jeg å bruke DEAMON Tools Lite til dette formålet. Noen kan ha andre preferanser, mer direkte eller lette verktøy, avhengig av smak og farge, som de sier .. Etter å ha installert DAEMON Tools Lite, dobbeltklikker jeg ganske enkelt på bildefilen GRMSDKX_EN_DVD.iso og en ny virtuell dukker opp i systemet CD:

Deretter, ved å dobbeltklikke, aktiverer jeg autoload og starter Windows SDK-installasjonen:

Når det er på tide å velge komponenter som skal installeres fra listen, deaktiverer vi absolutt alle alternativer bortsett fra de som er merket på skjermbildet. Dette vil hjelpe oss å unngå unødvendige feil nå.

Alt er akkurat slik, i skjermbildet er det to alternativer merket: "Windows Performance Toolkit" og "Feilsøkingsverktøy for Windows". Velg begge, fordi Windows Performance Toolkit vil sikkert komme godt med i arbeidet ditt! Deretter, etter å ha klikket på "Neste"-knappen, fortsetter installasjonen som vanlig. Og på slutten vil du se påskriften "Installation Complete".
Når installasjonen er fullført, vil arbeidskatalogene til Feilsøkingsverktøy for Windows-pakken være som følger:

For x86-versjon:
For x64-versjon:

På dette tidspunktet kan installasjonen av feilsøkingsverktøy for Windows anses som fullført.

Installere feilsøkingsverktøy for Windows via .msi-fil

Hvis det oppstår problemer når du installerer Feilsøkingsverktøy for Windows ved hjelp av de to foregående metodene, har vi fortsatt en til på lager, den mest pålitelige og tidstestede, som har kommet til unnsetning, så å si, mer enn én gang. En gang i tiden, før integrering i Windows SDK, var feilsøkingsverktøy for Windows tilgjengelig som et eget installer.msi, som fortsatt kan finnes, men allerede i innvollene i Windows SDK-distribusjonen. Siden vi allerede har et ISO-bilde av Windows SDK i våre hender, kan vi ikke montere det i systemet, men bare åpne det ved å bruke det allerede velkjente WinRAR-arkivet, eller et annet produkt som fungerer med innholdet på ISO-disker.

Etter å ha åpnet bildet, må vi gå til "Setup" -katalogen som ligger i roten og deretter velge en av katalogene:

Slik installerer du 64-bitsversjonen: \Setup\WinSDKDebuggingTools_amd64 og pakk ut filen dbg_amd64.msi fra denne katalogen.
Slik installerer du 32-bitsversjonen: \Setup\WinSDKDebuggingTools og pakk ut filen dbg_x86.msi fra denne katalogen.

Når installasjonen er fullført, vil arbeidskatalogene til Feilsøkingsverktøy for Windows-pakken være som følger:

For x86-versjon: C:\Program Files (x86)\Debugging Tools for Windows (x86)
For x64-versjon: C:\Program Files\Debugging Tools for Windows (x64)

På dette tidspunktet kan installasjonen av feilsøkingsverktøy for Windows anses som fullført.

tilleggsinformasjon

Jeg vet ikke hva dette er forbundet med, kanskje på grunn av uforsiktighet, men etter å ha installert feilsøkingsverktøy for Windows, setter ikke installasjonsprogrammet banen til katalogen med feilsøkeren i systembanevariabelen Path. Dette pålegger visse begrensninger for å starte ulike feilsøkingsoppgaver direkte fra konsollen. Derfor, hvis det ikke er noen sti, skriver jeg uavhengig i vinduet Miljøvariabler vei til feilsøkingsverktøy:

C:\Program Files (x86)\Windows Kits\10\Debuggers\x86
C:\Program Files (x86)\Windows Kits\10\Debuggers\x64

* I ditt tilfelle kan banene variere både på grunn av bruken av et OS med en annen bitstørrelse, og på grunn av bruken av en annen SDK-versjon.

Verktøyene til Debugging Tools for Windows-pakken kan fungere som bærbare applikasjoner; du trenger bare å kopiere katalogen fra arbeidssystemet Microsoft Windows Performance Toolkit og bruke den som en bærbar versjon på en produksjonsserver. Men ikke glem å ta hensyn til systemkapasiteten!! Selv om du har fullført en fullstendig installasjon av pakken på et kritisk system, kan du begynne å jobbe rett etter installasjonen, ingen omstart er nødvendig.

Sammensetning av feilsøkingsverktøy for Windows

Og nå, endelig, her er sammensetningen av feilsøkingsverktøy for Windows:

Fil	Hensikt
adplus.doc	Dokumentasjon for ADPlus-verktøyet.
adplus.exe	En konsollapplikasjon som automatiserer arbeidet til cdb-debuggeren for å lage dumps og loggfiler for en eller flere prosesser.
agestore.exe	Et verktøy for å fjerne foreldede filer fra lagring som brukes av en symbolserver eller kildeserver.
breakin.exe	Et verktøy som lar deg sende en tilpasset pausekombinasjon til prosesser, på samme måte som å trykke CTRL+C.
cdb.exe	Debugger for brukermoduskonsoll.
convertstore.exe	Et verktøy for å konvertere symboler fra 2-lags til 3-lags.
dbengprx.exe	Repeater (proxy-server) for ekstern feilsøking.
dbgrpc.exe	Et verktøy for å vise RPC-anropsstatusinformasjon.
dbgsrv.exe	Serverprosess brukt for ekstern feilsøking.
dbh.exe	Et verktøy for å vise informasjon om innholdet i en symbolfil.
dumpchk.exe	Dumpkontrollverktøy. Et verktøy for raskt å sjekke en dumpfil.
dumpexam.exe	Et verktøy for å analysere en minnedump. Resultatet sendes ut til %SystemRoot%\MEMORY.TXT .
gflags.exe	Redaktør for globale systemflagg. Verktøyet administrerer registernøkler og andre innstillinger.
i386kd.exe	Innpakning for kd. Var det det kd en gang ble kalt for systemer basert på Windows NT/2000 for x86-maskiner? Sannsynligvis forlatt av kompatibilitetsgrunner.
ia64kd.exe	Innpakning for kd. Ble det en gang kalt kd for systemer basert på Windows NT/2000 for ia64-maskiner? Sannsynligvis forlatt av kompatibilitetsgrunner.
kd.exe	Debugger for kjernemoduskonsoll.
kdbgctrl.exe	Kjernefeilsøkingsadministrasjonsverktøy. Verktøy for å administrere og konfigurere kjernefeilsøkingstilkobling.
kdsrv.exe	Tilkoblingsserver for KD. Verktøyet er et lite program som kjører og venter på eksterne tilkoblinger. kd kjører på klienten og kobler til denne serveren for ekstern feilsøking. Både serveren og klienten må være fra samme Debugging Tools-sammenstilling.
kill.exe	Et verktøy for å avslutte prosesser.
list.exe	Et verktøy for å vise innholdet i en fil på skjermen. Dette miniatyrverktøyet ble inkludert med ett formål - visning av store tekst- eller loggfiler. Den tar lite minneplass fordi den laster inn teksten i deler.
logger.exe	En miniatyr debugger som bare kan fungere med én prosess. Verktøyet injiserer logexts.dll i prosessområdet, som registrerer alle funksjonskall og andre handlinger i programmet som studeres.
logviewer.exe	Et verktøy for å vise logger registrert av logger.exe-feilsøkeren.
ntsd.exe	Microsoft NT Symbolic Debugger (NTSD). En debugger som er identisk med cdb, bortsett fra at den lager et tekstvindu når den startes. Som cdb er ntsd i stand til å feilsøke både konsollapplikasjoner og grafiske applikasjoner.
pdbcopy.exe	Et verktøy for å fjerne private symboler fra en symbolfil, kontrollere offentlige symboler inkludert i symbolfilen.
remote.exe	Et verktøy for fjernfeilsøking og fjernkontroll av alle konsollfeilsøkere KD, CDB og NTSD. Lar deg kjøre alle disse konsollfeilsøkerne eksternt.
rtlist.exe	Ekstern oppgavevisning. Verktøyet brukes til å vise en liste over kjørende prosesser gjennom DbgSrv-serverprosessen.
symchk.exe	Et verktøy for å laste ned symboler fra Microsofts symbolserver og lage en lokal symbolbuffer.
symstore.exe	Et verktøy for å lage et nettverk eller lokal symbollagring (2-lags/3-lags). Symbollagring er en spesialisert katalog på disk, som er bygget i samsvar med en bestemt struktur og inneholder symboler. En struktur av undermapper med navn som er identiske med navnene på komponentene opprettes i rotkatalogen med symboler. På sin side inneholder hver av disse undermappene nestede undermapper som har spesielle navn oppnådd ved å hashe binære filer. Symstore-verktøyet skanner komponentmapper og legger til nye komponenter til symbollageret, der enhver klient kan hente dem. Det sies at symstore brukes til å motta symboler fra 0-lags lagring og legge dem inn i 2-lags/3-lags lagring.
tlist.exe	Oppgaveviser. Et verktøy for å vise en liste over alle kjørende prosesser.
umdh.exe	Dumphaugverktøy i brukermodus. Et verktøy for å analysere hauger av den valgte prosessen. Lar deg vise ulike parametere for haugen.
usbview.exe	USB Viewer. Et verktøy for visning av USB-enheter koblet til en datamaskin.
vmdemux.exe	Virtuell maskin demultiplekser. Oppretter flere navngitte rør for én COM-tilkobling. Kanaler brukes til å feilsøke ulike virtuelle maskinkomponenter
windbg.exe	Brukermodus og kjernemodus feilsøker med GUI.

For å identifisere årsakene blå skjermer(BSOD) en minnedumpanalyse er nødvendig. I de aller fleste tilfeller er en minidump, som opprettes av systemet ved kritiske feil, tilstrekkelig.
Denne artikkelen inneholder trinn-for-trinn instruksjon om å installere og konfigurere WinDBG - et kraftig feilsøkingsverktøy som lar deg identifisere den sanne årsaken til BSOD.

Trinn 1 - Konfigurering av små minnedumper

Trinn 2 - Installere WinDBG

For å analysere minnedumper, må du installere WinDBG debugger, som er inkludert i Windows SDK. I skrivende stund er det siste tilgjengelig Windows-versjoner SDK:

Windows 10 SDK (nedlasting av nettverksinstallasjon)
Windows 8.1 SDK (nedlasting av nettverksinstallasjon)

Trinn 3 - Tilordning av .dmp-filer til WinDBG

For å gjøre det enklere å lese og analysere minnedumper, tilordne .dmp-filer til WinDBG. Dette vil tillate deg å åpne dumpfiler fra Explorer direkte i WinDBG uten først å starte den.

Trinn 4 — Sette opp en symbolserver for å motta feilsøkingssymbolfiler

Installasjon og innledende konfigurasjon av WinDBG er fullført. For å endre utseendet kan du gå til menyen Utsikt- du finner fontinnstillinger ved å velge Font, og konsollvindusinnstillingene i Alternativer.

Populært i kategorien: