Installera och konfigurera WinDBG för att analysera minnesdumpar. Installera felsökningsverktyg för Windows Konfigurera ditt system

22 juni 2010

Tidigare fanns Windbg separat för nedladdning. Men för de senaste versionerna behåller Microsoft det som en del av Windows SDK. Vänligen hitta nedladdningslänkarna nedan.

Windows 10

Den senaste versionen av Windbg för Windows 7 kan laddas ner från länken https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk

Windows 7

Ladda ner installationsprogram från länkarna ovan. Observera att detta inte laddar ner hela SDK, det är bara ett installationsprogram. när du kör filen, du kan välj vilka verktyg du vill laddas ner. Om du bara är intresserad av Windbg kan du utesluta allt annat och bara välja "Felsökningsverktyg" under "Common Utilities"

Ovanstående paket installerar windbg 6.12 version. Om du snabbt vill installera windbg kan du gå till äldre version(6.11) som kan laddas ner från
länken i slutet av detta inlägg.

När du har gjort installationen kan du hitta programmet i Start-menyn -> Alla program -> Felsökningsverktyg för Windows -> Windbg

Introduktion till WinDBG - Del 1

Alexander Antipov

WinDBG är en bra debugger. Det kanske inte har ett särskilt användarvänligt gränssnitt och ingen svart bakgrund som standard, men det är en av de mest kraftfulla och stabila felsökningarna på Windows för närvarande. I den här artikeln går jag igenom grunderna i WinDBG så att du kan komma igång med det.

WinDBG är en bra debugger. Det kanske inte har ett särskilt användarvänligt gränssnitt och ingen svart bakgrund som standard, men det är en av de mest kraftfulla och stabila felsökningarna på Windows för närvarande. I den här artikeln går jag igenom grunderna i WinDBG så att du kan komma igång med det.

Detta är den första artikeln i en serie om WinDBG. Lista över alla artiklar som ingår i denna serie:

• Del 1 - installation, gränssnitt, symboler, fjärr/lokal felsökning, hjälpsystem, moduler, register.
• Del 2 - brytpunkter.
• Del 3 - minnesinspektion, program steg-för-steg felsökning, tips och tricks.

I den här artikeln kommer vi att titta på montering och anslutning till en process, och i de följande kommer vi att täcka brytpunkter, genomstegning och minnesinspektion.

Installerar WinDBG

Jämfört med Windows 7 har installationsprocessen av WinDBG på Windows 8 genomgått mindre ändringar. I det här avsnittet kommer vi att titta på installation av en debugger för båda operativsystem.

Installera WinDBG på Windows 8

I Windows 8 ingår WinDBG i Windows Driver Kit (WDK). Du kan installera Visual Studio och WDK, eller installera paketet Debugging Tools for Windows 8.1 separat, som inkluderar WinDBG.

Installationsprogrammet kommer att fråga om du vill installera WinDBG lokalt eller ladda ner hela utvecklingspaketet för en annan dator. Det senare är i huvudsak motsvarigheten offlineinstallationsprogram, vilket är väldigt praktiskt om du vill installera paketet på andra system i framtiden.

Figur 1: Välja installationstyp

I nästa fönster måste du avmarkera alla objekt utom "Felsökningsverktyg för Windows" och klicka på knappen "Ladda ner".

När installationsprogrammet har slutfört sitt arbete, gå till katalogen där paketet laddades ner (som standard är det c:\Users\Username\Downloads\Windows Kits\8.1\StandaloneSDK) och gå igenom installationsproceduren.

Installera WinDBG på Windows 7 och tidigare

För Windows 7 och tidigare är WinDBG en del av paketet "Debugging Tools for Windows", som ingår i Windows SDK och .Net Framework. Du måste ladda ner installationsprogrammet och sedan välja "Felsökningsverktyg för Windows" under installationsprocessen.

Under installationen väljer jag alternativet "Felsökningsverktyg" under "Redistributable Packages" för att skapa ett fristående installationsprogram för att underlätta efterföljande installationer.

Figur 2: Välja installationsalternativ för att skapa ett fristående installationsprogram

När installationen är klar bör du ha WinDBG-installationsprogram för olika plattformar (i katalogen c:\Program Files\Microsoft SDKs\Windows\v7.1\Redist\Debugging Tools for Windows\).

Figur 3: Mapp med WinDBG-installatörer för olika plattformar

WinDBG-gränssnitt

Figur 4: Utseende av WinDBG

Så fort du först ser utseende WinDGB kommer du att inse att felsökaren är skrämmande enkel. De flesta av WinDBG-funktionerna lärs in under processfelsökning. Istället för att slösa tid på att beskriva gränssnittet kommer vi i följande avsnitt bara att täcka de viktigaste punkterna.

Det mest grundläggande du behöver veta om felsökningsgränssnittet är kommandofönstret, som består av två områden. Det första området: ett fönster där resultatet av att utföra kommandon visas. Andra området: ett litet textfält för inmatning av kommandon.

Figur 5: WinDBG Kommandofönster

Symboler

I de flesta fall kräver WinDBG inga speciella inställningar och fungerar korrekt direkt ur lådan. Men en viktig sak som behöver justeras är symbolerna. Symboler är filer som genereras tillsammans med den körbara filen under programkompileringen och innehåller felsökningsinformation (funktioner och variabelnamn). Felsökningsinformation låter dig utforska funktionaliteten hos en applikation medan du felsöker eller demonterar. Många Microsoft-komponenter är kompilerade med symboler som distribueras via Microsoft Symbol Server. Med resten av de körbara filerna är allt inte så rosenrött - mycket sällan medföljer applikationen filer med felsökningsinformation. I de flesta fall begränsar företag tillgången till sådan information.

För att konfigurera WinDBG för Microsoft använder Symbol Server gå till File:Symbol File Path och ställ in sökvägen till SRV*C:\Symbols*http://msdl.microsoft.com/download/symbols. Visst är det lite konstigt att asterisker används som avgränsare. När du har ställt in Microsoft Symbol Server kommer symbolerna att laddas ner till mappen C:\Symbols.

Figur 6: Microsoft installation Symbol Server

WinDBG kommer automatiskt att ladda symboler för binära filer när det behövs. Du kan också lägga till din egen symbolmapp så här:

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

Lägga till symboler under felsökning

Om du behöver importera symboler medan du felsöker kan du göra det med .sympath (kommandofönstret visas när du kopplar in processen). För att till exempel lägga till mappen c:\SomeOtherSymbolFolder anger du följande kommando:

0:025> .sympath+ c:\SomeOtherSymbolFolder
Symbolsökvägen är: SRV*C:\Symbols*http://msdl.microsoft.com/download/symbols;c:\SomeOtherSymbolFolder
Utökad sökväg för symboler är: srv*c:\symbols*http://msdl.microsoft.com/download/symbols;c:\someothersymbolfolder

Det är en bra idé att ladda om symboler efter att du har lagt till eller ändrat sökvägar:

0:025> .reload
Laddar om aktuella moduler
................................................................
...............................................

Kontrollera laddade symboler

För att se vilka moduler som har symboler laddade kan du använda kommandot x*!. Även om WinDBG bara laddar symboler efter behov, är x*! kommer att visa symboler som kan laddas. Du kan tvinga symboler att laddas med kommandot ld * (detta kan ta lite tid och du kan stoppa denna process genom att gå till Debug:Break).

Nu kan vi se symbolerna för varje modul.

Figur 8: Lista över symboler

Felsökning av en lokal process

När du felsöker en lokal process har du två alternativ:

1. Koppla till en redan pågående process.
2. Startprocess via WinDBG.

Varje metod har sina egna fördelar och nackdelar. Om du till exempel kör programmet genom WinDBG, så har du några speciella felsökningsalternativ tillgängliga (till exempel heap-debugging) som kan få applikationen att krascha. Å andra sidan finns det även program som kraschar när du kopplar en debugger till dem. Vissa applikationer (särskilt skadlig programvara) kontrollerar närvaron av en debugger i systemet under uppstart och därför är det i det här fallet vettigt att hålla fast vid en redan pågående process. Ibland sker en felsökning av en Windows-tjänst som ställer in vissa parametrar vid uppstart, så för att förenkla felsökningsprocessen är det också bättre att koppla in sig på en pågående process istället för att starta tjänsten genom en debugger. Vissa människor hävdar att att köra en process genom en debugger har en allvarlig inverkan på prestandan. Kort sagt, prova båda och välj det som passar dig bäst. Om du av någon anledning föredrar en viss metod, dela dina tankar i kommentarerna!

Startar en process

Om du felsöker ett fristående program som körs lokalt och inte är nätverksanslutet, kanske du vill köra det via WinDBG. Detta betyder dock inte att du inte kan haka på en redan pågående process. Välj det mest bekväma sättet för dig.

Att starta processen är inte svårt. Gå till "File:Open Executable" och välj den körbara filen du vill felsöka. Du kan också ange argument eller ställa in startkatalogen:

Figur 9: Välja en körbar fil för felsökning

Processanslutning

Att ansluta till en redan pågående process är inte heller svårt. Observera dock att det i vissa fall kan ta tid att hitta den exakta process du vill felsöka. Till exempel skapar vissa webbläsare en överordnad process och sedan flera fler processer för varje flik. Så, beroende på kraschdumpen du felsöker, kanske du vill koppla inte till den överordnade processen, utan till processen som är kopplad till fliken.

För att koppla till en redan pågående process, gå till "File:Attach to a Process" och välj sedan PID eller processnamn. Kom ihåg att du måste ha lämpliga rättigheter för att ansluta dig till processen.

Figur 10: Välja en process att haka på

Om applikationen efter anslutning har avbrutit sitt arbete kan du använda läget "Noninvaise" genom att markera lämplig ruta.

Felsökning av en fjärrprocess

Du kan ibland behöva felsöka en process på ett fjärrsystem. Det skulle vara mycket bekvämare att hantera denna uppgift med en lokal debugger istället för att använda en virtuell maskin eller RDP. Eller så kanske du felsöker LoginUI.exe-processen, som bara är tillgänglig när systemet är låst. I sådana här situationer kan du använda den lokala versionen av WinDBG och koppla till processer på distans. För att lösa dessa problem finns det två vanligaste metoder.

Befintliga felsökningssessioner

Om du redan har börjat felsöka programmet lokalt (genom att bifoga eller starta en process genom WinDBG), kan du ange ett specifikt kommando och WinDBG kommer att starta en "lyssnare" (avlyssnare) som fjärrfelsökaren kan ansluta till. För att göra detta, använd kommandot .server:

Server tcp:port=5005

Efter att ha kört kommandot ovan kan du se en varning så här:

Figur 11: Varningsmeddelande som kan visas efter att ha kört kommandot för att skapa en "lyssnare"

Då kommer WinDBG att rapportera att servern körs:

0:005> .server tcp:port=5005
0: -remote tcp:Port=5005,Server=USER-PC

Du kan nu ansluta från en fjärrvärd till en redan befintlig felsökningssession genom att gå till "File:Anslut till en fjärrsession" och ange något så här i textfältet: tcp:Port=5005,Server=192.168.127.138

Figur 12: Fjärranslutning till felsökningssessionen

Efter anslutning får du en bekräftelse på fjärrklienten:

servern startade. Klienten kan ansluta till vilken som helst av dessa kommandorader
0: -remote tcp:Port=5005,Server=USER-PC
MACHINENAME\User (tcp 192.168.127.138:13334) ansluten på mån 16 dec 09:03:03 2013

och meddelandet i den lokala versionen av felsökaren:

MACHINENAME\User (tcp 192.168.127.138:13334) ansluten på mån 16 dec 09:03:03 2013

Skapa en fjärrserver

Du kan också skapa en separat WinDBG-server, ansluta till den på distans och välja en process att felsöka. Detta kan göras med hjälp av filen dbgsrv.exe där du planerar att felsöka processer. För att starta en sådan server, kör följande kommando:

dbgsrv.exe -t tcp:port=5005

Figur 13: Starta en fjärrserver

Och återigen kan du få en säkerhetsvarning som du bör acceptera:

Figur 14: Säkerhetsmeddelande som kan visas under felsökningsserverns start

Du kan ansluta till felsökningsservern om du går till filen "File: Connect to Remote Stub" och anger följande rad i textfältet: tcp:Port=5005,Server=192.168.127.138

Figur 15: Ansluter till felsökningsservern

Efter anslutning kommer du inte att få några signaler om att du har anslutit, men om du går till "Arkiv:Bifoga till en process" kommer du att se en lista med felsökningsserverprocesser (där dbgsrv.exe körs). Nu kan du koppla in i processen som om du gjorde det lokalt.

Hjälpsystem

Hjälpsystemet i WinDBG är jättebra. Förutom att lära dig något nytt ska du kunna ta emot bakgrundsinformation om vilket lag som helst. Använd kommandot .hh för att komma åt WinDBG-hjälpen:

Du kan också få hjälp med ett specifikt team. Till exempel, för att få hjälp med kommandot .reload, använd följande kommando:

windbg> .hh .reload

Eller gå bara till avsnittet "Hjälp: Innehåll".

Moduler

Medan programmet körs importeras olika moduler som ger applikationens funktionalitet. Därför, om du vet vilka moduler som importeras av en applikation, kan du bättre förstå hur det fungerar. I många fall kommer du att felsöka den specifika modulen som laddas av programmet, inte själva den körbara filen.

När WinDBG är ansluten till processen kommer automatiskt att visa de laddade modulerna. Till exempel nedan är modulerna efter att jag anslutit till calc.exe:

Microsoft (R) Windows Debugger version 6.12.0002.633 X86
Copyright (c) Microsoft Corporation. Alla rättigheter förbehållna.

*** vänta med väntande bifoga
Symbolsökvägen är: SRV*C:\Symbols*http://msdl.microsoft.com/download/symbols
Körbar sökväg är:
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

Senare i felsökningsprocessen kan du visa den här listan igen med kommandot lmf:

0:005>lmf
start-slut-modulnamn
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 VERSION 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 777ba000LPK C:\Windows\system32\LPK.dll
777c0000 77860000 ADVAPI32 C:\Windows\system32\ADVAPI32.dll

Du kan också ta reda på nedladdningsadressen för en specifik modul med kommandot "lmf m":

0:005> lmf m kernel32
start-slut-modulnamn
77550000 77624000 kernel32 C:\Windows\system32\kernel32.dll

Du kan också få information om bildhuvudet för en viss modul med tillägget !dh (utropstecknet indikerar en förlängning):

0:005> !dh kernel32

Filtyp: DLL
VÄRDEN FÖR FILHUVUD
14C-maskin (i386)
4 antal sektioner
4A5BDAAD tidsdatumstämpel mån 13 jul 21:09:01 2009

0 filpekare till symboltabell
0 antal symboler
E0 storlek på valfri rubrik
2102 egenskaper
Körbar
32 bitars ordmaskin
DLL

VALFRIHETSVÄRDEN
10B magiskt #
9.00 länkversion
Storlekskod C4600
C800 storlek på initierade data
0 storlek på oinitierad data
510C5 adress för ingångspunkten
1000 baskod
----- ny -----
77550000 bildbas
1000 sektionsinriktning
200 filjustering
3 delsystem (Windows CUI)
6.01 operativsystemversion
6.01 bildversion
6.01 delsystemversion
D4000 storlek bild
800 storlek rubriker
D5597 kontrollsumma
00040000 storlek på stackreserv
00001000 storlek på stack commit
00100000 storlek på högreserv
00001000 storlek på heap commit
140 DLL-egenskaper
dynamisk bas
NX-kompatibel
B4DA8 [A915] adress för Export Directory
BF6C0 [ 1F4] adress för Import Directory
C7000 [ 520] adress till resurskatalogen
0 [ 0] adressen till undantagskatalogen
0 [ 0] adressen till säkerhetskatalogen
C8000 [B098] adress för Base Relocation Directory
C5460 [ 38] adressen till Debug Directory
0 [ 0] adress för beskrivningskatalog
0 [ 0] adressen till Special Directory
0 [ 0] adressen till trådlagringskatalogen
816B8 [ 40] adress för Load Configuration Directory
278 [ 408] adressen till Bound Import Directory
1000 [DE8] adress för Import Address Table Directory
0 [ 0] adressen till Delay Import Directory
0 [ 0] adressen till COR20 Header Directory
0 [ 0] adressen till den reserverade katalogen

AVSNITTSRubrik #1
.textnamn
C44C1 virtuell storlek
1000 virtuella adresser
C4600 storlek på rådata
800 filpekare till rådata

0 antal flyttningar
0 antal radnummer
60000020 flaggor
Koda
(ingen justering specificerad)
Utför Läs

Felsökningskataloger(2)
Typ Storlek Adresspekare
cv 25 c549c c4c9c Format: RSDS, guide, 2, kernel32.pdb
(10) 4 c5498 c4c98

AVSNITTSRubrik #2
.datanamn
FEC virtuell storlek
C6000 virtuell adress
E00 storlek på rådata
C4E00-filpekare till rådata
0 filpekare till flytttabell
0 filpekare till radnummer
0 antal flyttningar
0 antal radnummer
C0000040 flaggor
initierade data
(ingen justering specificerad)
Läsa skriva

AVSNITTSRubrik #3
.rsrc-namn
520 virtuell storlek
C7000 virtuell adress
600 storlek på rådata
C5C00-filpekare till rådata
0 filpekare till flytttabell
0 filpekare till radnummer
0 antal flyttningar
0 antal radnummer
40000040 flaggor
initierade data
(ingen justering specificerad)
Endast läs

AVSNITTSRubrik #4
.relocname
B098 virtuell storlek
C8000 virtuell adress
B200 storlek på rådata
C6200-filpekare till rådata
0 filpekare till flytttabell
0 filpekare till radnummer
0 antal flyttningar
0 antal radnummer
42000040 flaggor
initierade data
Kan kasseras
(ingen justering specificerad)
Endast läs

Meddelanden och undantag

Efter att ha bifogats till en process, visas först en lista med moduler, och sedan kan andra meddelanden visas. Till exempel, när vi kopplar in calc.exe, ställer WinDBG automatiskt in en brytpunkt (som bara är en markör som används för att stoppa applikationen). Brytpunktsinformation visas på skärmen:

(da8.b44): Undantag för brytinstruktioner - kod 80000003 (första chansen)

Det här meddelandet är ett undantag, nämligen första-chans-undantaget. I huvudsak är ett undantag ett speciellt tillstånd som uppstår under körningen av ett program. Första-chans-undantag innebär att programmet stannade direkt efter att undantaget inträffade. Andra chans-undantag innebär att efter att undantaget inträffat kommer vissa operationer att utföras, och sedan kommer programmet att stoppa sitt arbete.

Register

Efter att ha visat meddelanden och undantag, matar felsökaren ut statusen för processorregistren. Register är speciella variabler inom processorn som lagrar små bitar av information eller håller reda på tillståndet för något i minnet. Behandlaren kan behandla informationen i dessa register mycket snabbt. Detta är mycket snabbare än att få information på bussen från RAM varje gång.

Efter anslutning till calc.exe visar WinDBG automatiskt information om följande register:

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

Senare kan du duplicera denna information igen med kommandot r:

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

Om vi ​​vill få värdet på ett visst register kan vi utföra följande kommando:

0:005> r eax
eax=7ffd9000

Information kan erhållas samtidigt från flera register enligt följande:

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

Pekare till instruktion

Det sista kommandot handlar om att köra instruktioner. Här visas också information, som i fallet med kommandot r, om vad som innehåller EIP-registret. EIP är ett register som innehåller platsen nästa instruktion som ska utföras av processorn. Det som WinDBG visar är motsvarigheten till kommandot u eip L1, varefter WinDBG går till adressen som anges i EIP-registret, konverterar denna sektion till assemblykod och visar den på skärmen.

ntdll!DbgBreakPoint:
77663540 cc int 3

hålla kontakten

I följande artiklar kommer vi att titta på hur man använder WinDBG i strid: brytpunkter, stegfelsökning och visning av minne. Byt inte! J.

Dessa typer av fel är vanligtvis förknippade med en felaktig drivrutin som kan vara svår att lokalisera. Men det förbättrade felspårningssystemet in Windows Vista(och inte bara i Vista!) kan ofta leda dig till en problematisk fil. Som ett resultat slutar de flesta frenetiskt att försöka arbeta på en instabil dator, spara dokument med paranoid regelbundenhet och hoppas på det bästa.

När Windows kraschar skapas vanligtvis en så kallad "minnesdump". Det senare kan utforskas med ett gratis felsökningsverktyg Windows-felsökning Verktyg som kan leda dig till källan till problemet. Därför är allt du behöver göra:

Ladda ner ett felsökningsverktyg själv

Du kan ladda ner Windows Debugging Tools direkt från Microsofts webbplats. Programmet fungerar med många operativsystem, som börjar med Windows NT 4 och slutar med Windows 2008, så du bör inte ha några problem med det. Ja, det kan inte sägas att det är stabilt under Windows 7 RC, men enligt våra tester fungerar det fortfarande. Därför kan även ett försök att diagnostisera ett problem under Windows 7 RC vara framgångsrikt.

Konfigurera ditt system

Under krascher måste din dator skapa minnesdumpar som senare kommer att fungera som en informationskälla för felsökaren. Därför är det viktigt att Windows är konfigurerat för att generera dumpar. Klicka på för att anpassa ditt operativsystem Högerklicka för musen över din dator och välj Egenskaper. Klicka sedan på fliken Avancerade systeminställningar, på den hittar du underavsnittet Start- och återställningsinställningar och se till att alternativet Skriv felsökningsinformation är inställt på Kernel memory dump ) eller Complete memory dump.

Klicka sedan på Start, gå till Program (Alla program), välj Felsökningsverktyg och kör WinDbg. I programmet går du till Arkiv-menyn och väljer Symbol File Path ... Skriv sedan följande rad i fönstret som öppnas:

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

Den senare definierar vägen till specialdata - de så kallade "symbolerna" (symboler), som kan hjälpa felsökningsverktyget att identifiera din kraschade fil.

När du har angett strängen klickar du på OK-knappen. Senare, när du arbetar med felsökaren, kommer den här raden att göra att symbolerna laddas ner från msdl.microsoft.com och sparas i mappen c:\symbols.

Lös ditt problem

Vänta nu på ett nytt blåskärmsfel och det efterföljande slutförandet av omstart av datorn. Kör sedan WinDbg igen (Vista-användare måste köra programmet som administratör), klicka på Arkiv-menyn, välj Öppna Crash Dump, öppna filen \Windows\MEMORY.DMP och programmet börjar omedelbart analysera den.

Tyvärr ger WinDbg väldigt lite information om vad det gör, så du kanske till och med tror att programmet har fastnat. Vänta dock. Förstå att det kan ta lite tid att analysera t.ex. 4 GB minne på en inte särskilt kraftfull dator, upp till timmar. Ha därför tålamod, men lämna hellre analysen över natten.

Men vanligtvis uppnås resultatet inom några minuter. Detta bevisas av Bugcheck Analysis-raden som säger något i stil med "Probably caused by: UACReplace.sys". Översatt till ryska betyder detta att problemet möjligen orsakas av filen UACReplace.sys. Skriv in den i sökfältet, till exempel Google så får du reda på dess verkliga ursprung. I synnerhet om det tillhör ett av programmen du installerade eller installerad drivrutin, då kan du bara försöka uppdatera den eller honom. Kanske kommer detta att lösa dina problem.

Det måste sägas att WinDbg då och då inte kan namnge en fil alls, eller bara väljer en av dem Windows DLL-filer. Om detta hände dig, klicka bara på kommandofönstret ovanför statusfältet och skriv kommandot:

Tryck sedan på Enter. Detta kommer att ge dig en mer detaljerad rapport som kan innehålla information om möjliga orsaker dina problem.

Om du inte har tur den här gången, misströsta inte. Felsökning är ganska svårt, även för experter. Så stäng bara WinDbg och kör analysatorn igen efter nästa krasch. Kanske kommer detta att ge dig lite mer information. Lycka till!

Vid tidpunkten för ett kritiskt fel slutar operativsystemet Windows att fungera och visas blåskärm död (BSOD). Innehåll random access minne och all information om felet som har uppstått skrivs till personsökningsfilen. Nästa gång Windows startar skapas en kraschdump med felsökningsinformation baserad på sparad data. En allvarlig felpost skapas i systemets händelselogg.

Uppmärksamhet! Crash dump genererades inte om misslyckades diskundersystem eller ett kritiskt fel inträffade i det inledande skedet av att ladda Windows.

Typer av Windows Crash Dumps

Med hjälp av exemplet med det nuvarande operativsystemet Windows 10 ( Windows Server 2016) överväga huvudtyperna av minnesdumpar som systemet kan skapa:

• Mini minnesdump (liten minnesdump)(256 KB). Denna typ av fil innehåller en minsta mängd information. Den innehåller bara ett meddelande om BSOD-fel, information om drivrutinerna, de processer som var aktiva vid tidpunkten för kraschen och vilken process eller kärntråd som orsakade kraschen.
• Kärnminnesdump. Som regel liten i storlek - en tredjedel av volymen fysiskt minne. Kärnminnesdumpen är mer detaljerad än minidumpen. Den innehåller information om drivrutiner och kärnlägesprogram, inkluderar minne som allokerats till Windows-kärnan och hårdvaruabstraktionslagret (HAL) och minne som allokerats till drivrutiner och andra kärnlägesprogram.
• Komplett minnesdump. Den största i storlek och kräver minne lika med ditt systems RAM plus de 1 MB som krävs av Windows för att skapa den här filen.
• Automatisk minnesdumpning. Motsvarar en kärnminnesdump vad gäller information. Det skiljer sig bara i hur mycket utrymme den använder för att skapa dumpfilen. Den här filtypen fanns inte i Windows 7. Den lades till i Windows 8.
• Aktiv minnesdump. Denna typ filtrerar bort element som inte kan fastställa orsaken till ett systemfel. Detta lades till i Windows 10 och är särskilt användbart om du kör en virtuell maskin eller om ditt system är en Hyper-V-värd.

Hur aktiverar man generering av minnesdump i Windows?

Använd Win + Pause, öppna systeminställningsfönstret, välj " Ytterligare systeminställningar" (Avancerade systeminställningar). I fliken " Dessutom" (Avancerat), avsnitt "" (Start och återställning), klicka på knappen " alternativ" (Inställningar). I fönstret som öppnas, konfigurera åtgärder vid systemfel. Markera kryssrutan " Skriv händelser till systemloggen» (Skriv en händelse till systemloggen), välj vilken typ av dump som ska genereras när systemet kraschar. Om i kryssrutan " Ersätt befintlig dumpfil» (Skriv över befintlig fil) markera rutan, filen kommer att skrivas över vid varje krasch. Det är bättre att avmarkera den här rutan, då får du mer information för analys. Inaktivera även den automatiska omstarten av systemet (Starta om automatiskt).

I de flesta fall räcker en liten minnesdump för att analysera orsaken till BSOD.

Nu, om en BSOD inträffar, kan du analysera dumpfilen och hitta orsaken till felen. En minidump lagras som standard i mappen %systemroot%\minidump. För att analysera dumpfilen rekommenderar jag att du använder programmet WinDBG(Microsoft Kernel Debugger).

Installera WinDBG på Windows

Verktyg WinDBG ingår i " Windows 10 SDK» (Windows 10 SDK). .

Filen kallas winsdksetup.exe, storlek 1,3 MB.

Kör installationen och välj om du vill installera paketet på den här datorn eller ladda ner det för installation på andra datorer. Installera paketet på den lokala datorn.

Du kan installera hela paketet, men välj bara för att installera felsökningsverktyget Felsökningsverktyg för Windows.

När de har installerats kan WinDBG-genvägar hittas i startmenyn.

Ställa in associeringen av .dmp-filer med WinDBG

För att öppna dumpfiler med ett enkelt klick, mappa filtillägget .dmp till verktyget WinDBG.

1. Öppna en kommandotolk som administratör och kör kommandona för ett 64-bitarssystem: cd C:\Program Files (x86)\Windows Kits\10\Debuggers\x64
   windbg.exe –IA
   för 32-bitars system:
   C:\Program Files (x86)\Windows Kits\10\Debuggers\x86
   windbg.exe –IA
2. Som ett resultat kommer filtyperna: .DMP, .HDMP, .MDMP, .KDMP, .WEW att mappas till WinDBG.

Konfigurera en felsökningssymbolserver i WinDBG

Felsökningssymboler (debug-symboler eller symbolfiler) är datablock som genereras i processen att kompilera ett program tillsammans med en körbar fil. Sådana datablock innehåller information om variabelnamn, kallade funktioner, bibliotek etc. Denna data behövs inte när du kör programmet, men användbar när du felsöker det. Microsoft-komponenter kompileras med symboler som distribueras via Microsoft Symbol Server.

Ställ in WinDBG för att använda Microsoft Symbol Server:

• Öppna WinDBG;
• Gå till menyn Fil –> Symbolfilsökväg;
• Skriv en sträng som innehåller URL:en för nedladdning av felsökningssymboler från Microsofts webbplats och mappen för att spara cachen: SRV*E:\Sym_WinDBG*http://msdl.microsoft.com/download/symbols I exemplet laddas cachen ner till mappen E:\Sym_WinDBG kan du ange vilken som helst.
• Glöm inte att spara ändringar i menyn Fil–>Spara WorkSpace;

WinDBG kommer att söka efter symboler i den lokala mappen och, om den inte hittar de nödvändiga symbolerna i den, kommer den automatiskt att ladda ner symbolerna från den angivna platsen. Om du vill lägga till din egen symbolmapp kan du göra det så här:

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

Om det inte finns någon internetanslutning laddar du först ned symbolpaketet från Windows Symbol Packages-resursen.

Crash dump analys i WinDBG

WinDBG-debuggern öppnar dumpfilen och laddar ner de nödvändiga symbolerna för felsökning från en lokal mapp eller från Internet. Under denna process kan du inte använda WinDBG. Längst ner i fönstret (i felsökningskommandoraden) visas inskriptionen Debugee inte ansluten.

Kommandon skrivs in på kommandoraden längst ner i fönstret.

Det viktigaste att vara uppmärksam på är felkoden, som alltid anges i hexadecimalt värde och ser ut 0xXXXXXXXXX(anges i ett av alternativen - STOPP:, 07/02/2019 0008F, 0x8F). I vårt exempel är felkoden 0x139.

Debuggern uppmanar dig att köra kommandot!analys -v, håll bara muspekaren över länken och klicka. Vad är detta kommando till för?

• Den utför en preliminär analys av minnesdumpen och tillhandahåller detaljerad information för att starta analysen.
• Detta kommando visar STOP-koden och det symboliska namnet på felet.
• Den visar anropsstacken för kommandona som ledde till kraschen.
• Dessutom visas IP-adress, process- och registerfel här.
• Teamet kan ge färdiga rekommendationer för att lösa problemet.

De viktigaste punkterna som du bör vara uppmärksam på när du analyserar efter att ha kört kommandot !analyze -v (listan är inte komplett).

1: kd> !analysera -v

* *
*Bugcheck Analysis*
* *
*****************************************************************************
Symboliskt namn på STOPP-felet (BugCheck)
KERNEL_SECURITY_CHECK_FAILURE (139)
Beskrivning av felet (En kärnkomponent har skadat en kritisk datastruktur. Denna korruption kan potentiellt tillåta en angripare att ta kontroll över den här maskinen):

En kärnkomponent har skadat en kritisk datastruktur. Korruptionen kan potentiellt tillåta en illvillig användare att få kontroll över den här maskinen.
Felargument:

Argument:
Arg1: 00000000000000003, A LIST_ENTRY har skadats (dvs dubbelt borttagning).
Arg2: ffffd0003a20d5d0, Adress till trapramen för undantaget som orsakade felkontrollen
Arg3: ffffd0003a20d528, Adress till undantagsposten för undantaget som orsakade buggkontrollen
Arg4: 0000000000000000, reserverad
Felsökningsdetaljer:
------------------

Räknaren visar hur många gånger systemet kraschade med ett liknande fel:

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: FAIL_FAST_CORRUPT_LIST_ENTRY

STOPP-felkod i förkortat format:

BUGCHECK_STR: 0x139

Processen som kraschade (inte nödvändigtvis orsaken till felet, bara den processen kördes i minnet vid tidpunkten för kraschen):

PROCESS_NAME: sqlservr.exe

Felkodsdekryptering: Systemet har upptäckt ett stackbuffertspill i denna applikation, vilket kan tillåta en angripare att ta kontroll över denna applikation.

ERROR_CODE: (NTSTATUS) 0xc0000409 - Systemet upptäckte ett överskridande av en stackbaserad buffert i denna applikation. Detta överskridande kan potentiellt tillåta en illvillig användare att få kontroll över denna applikation.
EXCEPTION_CODE: (NTSTATUS) 0xc0000409 - Systemet upptäckte ett överskridande av en stackbaserad buffert i denna applikation. Detta överskridande kan potentiellt tillåta en illvillig användare att få kontroll över denna applikation.

Sista samtalet på stacken:

LAST_CONTROL_TRANSFER: från fffff8040117d6a9 till fffff8040116b0a0

Ring stack vid tidpunkten för fel:

STACK_TEXT:
ffffd000`3a20d2a8 fffff804`0117d6a9: 00000000`00000139 00000000`00000003 ffffd000`3a20d5d0 ffffd000`28a20Checkt5K3a20nCheckt
ffffd000`3a20d2b0 fffff804`0117da50: ffffe000`f3ab9080 ffffe000`fc37e001 ffffd000`3a20d5d0 fffff804`0116e2a2a2: nt!Dick6KiBCh09: nt!
ffffd000`3a20d3f0 fffff804`0117c150: 00000000`00000000 00000000`00000000 00000000000000000
ffffd000`3a20d5d0 fffff804`01199482: ffffc000`701ba270 ffffc000`00000001 000000ea`73f68040 fffff804`000006f
ffffd000`3a20d760 fffff804`014a455d: 00000000`00000001 ffffd000`3a20d941 ffffe000`fcacb000 ffffd000`3a20nd951: ?? ::FNODOBFM::`string"+0x17252
ffffd000`3a20d8c0 fffff804`013a34ac: 00000000`00000004 00000000`00000000
ffffd000`3a20d990 fffff804`0117d313: ffffffff`fffffffe 00000000`00000000 00000000`00000000 000000eb`a0cf1380:Writnt1380:W 1380!
ffffd000`3a20da90 00007ffb`475307da: 00000000`00000000 00000000`00000000 00000000000000000
000000ee'f25ed2b8 00000000'00000000: 00000000'00000000 00000000'00000000 00000000'00000000

Kodens avsnitt där felet inträffade:

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: Maskinägare

Namnet på modulen i kärnobjekttabellen. Om analysatorn kunde upptäcka en problematisk drivrutin visas namnet i fälten MODULE_NAME och IMAGE_NAME:

MODULE_NAME: nt
IMAGE_NAME: ntkrnlmp.exe

1: kd > lmvm nt
Bläddra i hela modullistan
Laddad symbolbildfil: ntkrnlmp.exe
Mappad minnesbildfil: C:\ProgramData\dbg\sym\ntoskrnl.exe\5A9A2147787000\ntoskrnl.exe
Bildsökväg: ntkrnlmp.exe
Bildnamn: ntkrnlmp.exe
Internt namn: ntkrnlmp.exe
Originalfilnamn: ntkrnlmp.exe
Produktversion: 6.3.9600.18946
Filversion: 6.3.9600.18946 (winblue_ltsb_escrow.180302-1800)

I exemplet ovan pekade analysen på kärnfilen ntkrnlmp.exe. När minnesdumpningsanalys indikerar systemdrivrutinen(till exempel win32k.sys) eller en kärnfil (som i vårt exempel ntkrnlmp.exe), troligen given filär inte orsaken till problemet. Mycket ofta visar det sig att problemet ligger i drivrutinen, BIOS-inställningar eller fel på utrustningen.

Om du ser att BSOD beror på en drivrutin från tredje part, kommer dess namn att listas i värdena MODULE_NAME och IMAGE_NAME.

Till exempel:

Bildsökväg: \SystemRoot\system32\drivers\cmudaxp.sys
Bildnamn: cmudaxp.sys

Öppna egenskaperna för drivrutinsfilen och kontrollera dess version. I de flesta fall löses problemet med drivrutinerna genom att uppdatera dem.

Felsökningsverktyg för Windows- Verktyg för felsökning av driftkoder Windows-system. De är en uppsättning fritt distribuerade program från Microsoft designade för felsökning av användarläges- och kärnlägeskod: applikationer, drivrutiner, tjänster, kärnmoduler. Verktygslådan innehåller konsol- och GUI-felsökare, verktyg för att arbeta med symboler, filer, processer, verktyg för fjärrfelsökning. Verktygslådan innehåller verktyg med vilka du kan hitta orsakerna till fel i olika komponenter i systemet. Felsökningsverktyg för Windows från ett visst tillfälle inte är tillgängliga för nedladdning i form av en fristående distribution och är en del av Windows SDK (Windows Software Development Kit). Instrumental set Windows-verktyg SDK:n är i sin tur tillgänglig som en del av MSDN-prenumerationsprogrammet eller kan laddas ner gratis som en separat distribution från msdn.microsoft.com. Enligt utvecklarna, den senaste och bästa aktuell version Felsökningsverktyg för Windows finns i Windows SDK.

Felsökningsverktyg för Windows uppdateras och görs tillgängliga för allmänheten ganska ofta, och denna process beror inte på utgivningen av operativsystem. Kontrollera därför regelbundet efter nya versioner.

Låt oss nu se vad i synnerhet felsökningsverktygen för Microsoft Windows tillåter oss att göra:

• Felsökning av lokala applikationer, tjänster (tjänster), drivrutiner och kärna;
• Felsökning över nätverk fjärrapplikationer, tjänster (tjänster), drivrutiner och kärna;
• Felsöka program som körs i realtid;
• Analysera minnesdumpfiler för applikationer, kärnan och systemet som helhet;
• Arbeta med system baserade på x86/x64/Itanium-arkitekturer;
• Felsök program i användarläge och kärnläge;

Följande versioner av felsökningsverktyg för Windows är tillgängliga: 32-bitars x86, Intel Itanium, 64-bitars x64. Vi behöver två av dem: x86 eller x64.

Det finns flera sätt att installera felsökningsverktyg för Windows, i den här artikeln kommer vi bara att överväga de viktigaste:

• Installation via webbinstallationsprogram.
• Installera felsökningsverktyg för Windows från ISO Windows-bild SDK.
• Installera felsökningsverktyg för Windows direkt från dbg_amd64.msi /dbg_x86.msi-paketen.

Det är fortfarande oklart vid vilken tidpunkt, varför ska jag installera felsökningsverktyg på en dator? Ofta stöter man trots allt på en situation där ingrepp i arbetsmiljön är ytterst oönskat! Och ännu mer eftersom installationen av en ny produkt, det vill säga att göra ändringar i registret / systemfilerna, kan vara helt oacceptabelt. Verksamhetskritiska servrar är exempel. Varför överväger inte utvecklare bärbara versioner av applikationer som inte kräver installation?
Från version till version genomgår processen att installera paketet Debugging Tools for Windows vissa förändringar. Låt oss nu hoppa rakt in i installationsprocessen och titta på hur verktygslådan kan installeras.

Installera felsökningsverktyg för Windows med hjälp av webbinstalleraren

Gå till arkivsidan för Windows SDK och hitta ett avsnitt som heter Windows 10 och under objektet "Windows 10 SDK (10586) och Microsoft Windows 10 Mobile Device Emulator (version 10586.11)".

Klicka på ett objekt INSTALLERA SDK. Efter att ha klickat, ladda ner och kör filen sdksetup.exe, som initierar processen för onlineinstallation av Windows SDK. I det inledande skedet kommer installationsprogrammet att kontrollera om .NET Framework-paketet är installerat på systemet senaste versionen(för närvarande är det 4,5). Om paketet saknas kommer installationen att erbjudas och stationen kommer att startas om när den är klar. Omedelbart efter omstarten, vid användarauktoriseringsstadiet, startar installationsprocessen direkt med Windows SDK.

Ofta, när du väljer alla komponenter i paketet utan undantag, kan fel uppstå under installationsprocessen. I det här fallet rekommenderas det att installera komponenter selektivt, den minsta nödvändiga uppsättningen.

Efter installationen av felsökningsverktyg för Windows plats felsöka filer när den här metoden vår installation blir som följer:

• 64-bitars versioner: C:\Program Files (x86)\Windows Kits\x.x\Debuggers\x64
• 32-bitars versioner: C:\Program Files (x86)\Windows Kits\x.x\Debuggers\x86

* där x.x är en specifik version av utvecklingssatsen;
Har du märkt att version 8 och högre, installationsvägarna skiljer sig märkbart från de klassiska för alla tidigare versioner av felsökningsverktyg?

Ett stort plus den här metoden Att installera felsökningsverktyg för Windows är att installera versioner av felsökningsverktyg för alla arkitekturer samtidigt.

Installera felsökningsverktyg för Windows från Windows SDK ISO

Den här metoden innebär att du installerar felsökningsverktyg för Windows med den fullständiga installationsbilden för Windows SDK (Software Developers Kit). Till en viss tid, ladda ner iso-bild för lämpligt system kan du besöka sidan Windows SDK Archive. Men för närvarande kan du få en ISO-avbild av SDK:n genom att köra webbinstallationsprogrammet sdksetup.exe och välja objektet Ladda ner Windows Software Development Kit i installationsprogrammets startfönster:

Som det kom fram är den tidigare installationsmetoden med webbinstallationsprogrammet ganska nyckfull och misslyckas ofta. På rena system installeras den utan problem, men på tillräckligt laddade system uppstår många problem. Om detta är fallet för dig, använd den här metoden.

Följaktligen måste du på sidan välja det nödvändiga distributionspaketet, för mig (och jag tror för många) för tillfället är det " Windows-paket SDK för Windows 7 och .NET Framework 4" och klicka på länken "Hämta DVD ISO-bild" nedan.

När du arbetar med sajten msdn.microsoft.com rekommenderar jag att du använder en webbläsare Internet Explorer, eftersom det har observerats fall där konkurrerande produkter inte fungerar!

Följaktligen är det nödvändigt att välja endast efter behov. Vanligtvis är bitheten för Debugging Tools för Windows densamma som bitheten i systemet. Mina testsystem är mestadels 64-bitars, så i de flesta fall laddar jag ner bilden för 64-bitarssystemet GRMSDKX_EN_DVD.iso .
Sedan, efter att ha laddat ner bilden, måste vi på något sätt arbeta med den befintliga ISO-bilden. Det traditionella sättet är förstås att bränna en CD, men detta är en ganska lång och ibland kostsam metod. Jag föreslår att använda gratis verktyg för att skapa virtuella diskenheter i systemet. Personligen föredrar jag att använda programmet DEAMON Tools Lite för detta ändamål. Någon kan ha andra preferenser, mer direkta eller lätta verktyg, i smak och färg, som man säger .. Efter att ha installerat DAEMON Tools Lite dubbelklickar jag helt enkelt på bildfilen GRMSDKX_EN_DVD.iso och jag har en ny virtuell cd:

Sedan, genom att dubbelklicka, aktiverar jag autoload och startar installationen av Windows SDK:

När turen kommer att välja de komponenter som ska installeras från listan inaktiverar vi absolut alla alternativ förutom de som är markerade på skärmdumpen. Detta kommer att hjälpa oss att undvika onödiga misstag nu.

Det stämmer, skärmdumpen visar två alternativ: "Windows Performance Toolkit" och "Felsökningsverktyg för Windows". Välj båda, för Windows Performance Toolkit kommer säkert att komma väl till pass i ditt arbete! Efter att ha klickat på knappen "Nästa" fortsätter installationen i normalt läge. Och i slutet kommer du att se inskriptionen "Installation Complete".
När installationen är klar kommer arbetskatalogerna för Debugging Tools for Windows-satsen att vara följande:

• För x86-version:
• För x64-version:

Detta slutför installationen av felsökningsverktyg för Windows.

Installera felsökningsverktyg för Windows via .msi-fil

Om du stöter på problem med att installera felsökningsverktyg för Windows med två tidigare sätt, vi har fortfarande en till i lager, den mest pålitliga och beprövade, som hjälpte så att säga mer än en gång. En gång, innan integreringen i Windows SDK, var felsökningsverktyg för Windows tillgängliga som ett separat .msi-installationsprogram, som fortfarande kan hittas, men redan i Windows SDK-distribution. För det har vi redan Windows ISO SDK, då kan vi inte montera den i systemet, utan helt enkelt öppna den med hjälp av de redan välkända WinRAR arkiverare, ja, eller någon annan produkt som fungerar med innehållet på ISO-skivor.

Efter att ha öppnat bilden måste vi gå till katalogen "Setup" som finns i roten och sedan välja en av katalogerna:

• Så här installerar du 64-bitarsversionen: \Setup\WinSDKDebuggingTools_amd64 och packa upp filen dbg_amd64.msi från den här katalogen.
• Så här installerar du 32-bitarsversionen: \Setup\WinSDKDebuggingTools och packa upp filen dbg_x86.msi från den här katalogen.

När installationen är klar kommer arbetskatalogerna för Debugging Tools for Windows-satsen att vara följande:

• För x86-version: C:\Program Files (x86)\Debugging Tools for Windows (x86)
• För x64-version: C:\Program Files\Debugging Tools for Windows (x64)

Vid denna tidpunkt kan installationen av felsökningsverktyg för Windows anses vara avslutad.

ytterligare information

Jag vet inte vad det hänger ihop med, kanske med min slarv, men efter att ha installerat felsökningsverktygen för Windows ställer inte installationsprogrammet in sökvägen till katalogen med felsökaren i sökvägsvariabeln Path. Detta medför vissa begränsningar för att köra olika felsökningsuppgifter direkt från konsolen. Därför, i avsaknad av en väg, skriver jag själv i fönstret Miljövariabler väg till felsökningsverktyg:

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

* I ditt fall kan vägarna skilja sig både på grund av användningen av ett OS med ett annat bitdjup, och på grund av SDK-användning annan version.

Verktygen i paketet Debugging Tools for Windows kan fungera som bärbara applikationer, du behöver bara kopiera katalogen från arbetssystemet Microsoft Windows Performance Toolkit och använda den som en bärbar version på en produktionsserver. Men glöm inte att ta hänsyn till systemets kapacitet !! Även om du har gjort en komplett installation av paketet på ett kritiskt system kan du börja arbeta direkt efter installationen, ingen omstart krävs.

Felsökningsverktyg för Windows

Och nu, äntligen, här är sammansättningen av Debugging Tools for Windows: