Aktivera felsökning av postmortem

2025-04-04

Undantagshantering i användarläge

Undantag och brytpunkter

De vanligaste programfelen kallas undantag. Dessa omfattar åtkomstöverträdelser, division-med-noll-fel, numeriska överflöd, CLR-undantag och många andra typer av fel. Applikationer kan också orsaka brytpunktsavbrott. Dessa inträffar när Windows inte kan köra programmet (till exempel när en nödvändig modul inte kan läsas in) eller när en brytpunkt påträffas. Brytpunkter kan infogas i koden av ett felsökningsprogram eller anropas via en funktion som DebugBreak.

Undantagshanterares prioritet

Baserat på konfigurationsvärden och vilka felsökare som är aktiva hanterar Windows fel i användarläge på flera olika sätt. Följande sekvens visar prioriteten som används för felhantering i användarläge:

Om ett felsökningsprogram i användarläge för närvarande är kopplat till felprocessen gör alla fel att målet bryter sig in i det här felsökningsprogrammet.

Så länge felsökaren i användarläge är ansluten används inga andra felhanteringsmetoder – även om kommandot gn (Go With Exception Not Handled) används.
Om inget felsökningsprogram i användarläge är kopplat och den utförande koden har sina egna rutiner för undantagshantering (till exempel try - except), försöker den här undantagshanteringsrutinen hantera felet.
Om inget felsökningsprogram i användarläge är anslutet och Windows har en öppen kernel-felsökningsanslutning, och felet är ett brytpunktsavbrott, försöker Windows kontakta kernelfelsökaren.

Kernel-felsökningsanslutningar måste öppnas under Windows startprocess. Om du vill förhindra att ett avbrott i användarläge bryter sig in i kernelfelsökaren kan du använda verktyget KDbgCtrl med parametern -du . Mer information om hur du konfigurerar kernel-felsökningsanslutningar och hur du använder KDbgCtrl finns i Komma igång med felsökning.

I kernelfelsökaren kan du använda gh (Go With Exception Handled) för att ignorera felet och fortsätta att köra målet. Du kan använda gn (Go With Exception Not Handled) för att kringgå kernelfelsökaren och gå vidare till steg 4.
Om villkoren i steg 1, 2 och 3 inte gäller aktiverar Windows ett felsökningsverktyg som konfigurerats i AeDebug-registervärdena. Alla program kan väljas i förväg som det verktyg som ska användas i den här situationen. Det valda programmet kallas för felsökningsprogrammet postmortem.
Om villkoren i steg 1, 2 och 3 inte gäller och det inte finns något postmortem-felsökningsprogram registrerat, visar Windows Felrapportering (WER) ett meddelande och tillhandahåller lösningar om det finns några tillgängliga. WER skriver också en minnesdumpfil om lämpliga värden anges i registret. Mer information finns i Använda WER och att samla in User-Mode Dumpar.

Funktionen DebugBreak

Om ett postmortem-felsökningsprogram har installerats kan du avsiktligt bryta dig in i felsökningsprogrammet från ett program i användarläge genom att anropa funktionen DebugBreak .

Ange ett Felsökningsprogram för postmortem

I det här avsnittet beskrivs hur du konfigurerar verktyg som WinDbg som postmortem-felsökningsprogram. När det har konfigurerats startas felsökningsprogrammet för postmortem automatiskt när ett program kraschar.

Registernycklar för post mortem-felsökningsprogrammet

Windows Error Reporting (WER) skapar felsökningsprocessen postmortem med hjälp av värdena som anges i registernyckeln AeDebug.

HKLM\Mjukvara\Microsoft\Windows NT\CurrentVersion\AeDebug

Det finns två primära registervärden av intresse, Felsökningsprogram och Auto. Registervärdet för felsökaren anger kommandoraden för felsökningsprogrammet postmortem. Värdet för autoregister anger om felsökningsprogrammet för postmortem startas automatiskt, eller om en bekräftelsemeddelanderuta visas först.

Felsökningsprogram (REG_SZ)

Det här REG_SZ-värdet specificerar debuggern som ska hantera efterdödsfelsökning.

Den fullständiga sökvägen till felsökningsprogrammet måste anges om inte felsökningsprogrammet finns i en katalog som finns i standardsökvägen.

Kommandoraden genereras från felsökningssträngen via ett utskriftsformatanrop som innehåller 3 parametrar. Även om ordningen är fast, finns det inget krav på att använda någon eller alla tillgängliga parametrar.

DWORD (%ld) – Process-ID för målprocessen.

DWORD (%ld) – Händelsehandtag som dupliceras i felsökningsprocessen för postmortem. Om felsökningsprogrammet postmortem signalerar händelsen fortsätter WER målprocessen utan att vänta på att felsökningsprogrammet för postmortem ska avslutas. Händelsen ska bara signaleras om problemet har lösts. Om postmortem-felsökningsprogrammet avslutas utan att signalera händelsen fortsätter WER insamlingen av information om målprocesserna.

void* (%p) – Adress för en JIT_DEBUG_INFO struktur som allokerats i målprocessens adressutrymme. Strukturen innehåller ytterligare undantagsinformation och kontext.

Automatisk (REG_SZ) Det här REG_SZ värdet är alltid 0 eller 1.

Om Auto är inställt på 0 visas en bekräftelsemeddelanderuta innan felsökningsprocessen för postmortem startas.

Om Auto är inställt på 1 skapas felsökningsprogrammet för postmortem omedelbart.

När du redigerar registret manuellt gör du det mycket noggrant, eftersom felaktiga ändringar i registret kanske inte tillåter att Windows startar.

Exempel på kommandoradsanvändning

Många postmortem-felsökare använder en kommandorad som innehåller -p- och -e-växlar för att indikera att parametrarna är en PID respektive händelse. Om du till exempel installerar WinDbg via windbg.exe -I skapas följande värden:

Debugger = "<Path>\WinDbg -p %ld -e %ld -g"
Auto = 1

Det finns flexibilitet i hur WER-%ld %ld %p parametrar kan användas. Till exempel. det finns inget krav på att ange några växlar runt eller mellan WER-parametrarna. Om du till exempel installerar Windows Sysinternals ProcDump med hjälp av procdump.exe -i skapas följande värden utan växlar mellan WER-%ld %ld %p parametrarna:

Debugger = "<Path>\procdump.exe" -accepteula -j "c:\Dumps" %ld %ld %p
Auto = 1

32- och 64-bitars felsökningsprogram

På en 64-bitarsplattform definieras registervärdena Debugger (REG_SZ) och Auto (REG_SZ) individuellt för 64-bitars- och 32-bitarsprogram. En ytterligare Windows på Windows (WOW)-nyckel används för att lagra 32-bitars applikationens post-mortem-debuggningsvärden.

HKLM\Mjukvara\Wow6432Node\Microsoft\Windows NT\CurrentVersion\AeDebug

På en 64-bitarsplattform använder du en 32-bitars post-mortem-debugger för 32-bitarsprocesser och en 64-bitars debugger för 64-bitarsprocesser. Detta undviker ett 64-bitars felsökningsprogram som fokuserar på WOW64-trådarna i stället för 32-bitarstrådarna i en 32-bitarsprocess.

För många felsökningsprogram för postmortem, inklusive felsökningsverktyg för Windows postmortem-felsökningsprogram, innebär detta att du kör installationskommandot två gånger. en gång med x86-versionen och en gång med x64-versionen. Om du till exempel vill använda WinDbg som ett interaktivt postmortem-felsökningsprogram, ska kommandot windbg.exe -I köras två gånger, en gång för varje version.

64-bit installation:

C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\windbg.exe –I

Detta uppdaterar registernyckeln med dessa värden.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug
Debugger = "C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\windbg.exe" -p %ld -e %ld –g

32-bitarsinstallation:

C:\Program Files (x86)\Windows Kits\10\Debuggers\x86\windbg.exe –I

Detta uppdaterar registernyckeln med dessa värden.

HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows NT\CurrentVersion\AeDebug
Debugger = "C:\Program Files (x86)\Windows Kits\10\Debuggers\x86\windbg.exe" -p %ld -e %ld –g

Konfigurera felsökningsprogram efter obduktion

Felsökningsverktyg för Windows

Felsökningsverktygen för Windows stöder alla att ställas in som postmortem-debugger. Installationskommandot är avsett för att processen ska felsökas interaktivt.

WinDbg

Om du vill ange felsökaren för postmortem till WinDbg kör du windbg -I. (Måste I vara versalt.) Det här kommandot kommer att visa ett meddelande om framgång eller misslyckande efter att det har använts. Om du vill arbeta med både 32- och 64-bitarsprogram kör du kommandot för både 64- och 32-felsökarna.

C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\windbg.exe –I
C:\Program Files (x86)\Windows Kits\10\Debuggers\x86\windbg.exe –I

Så här kommer registerposten AeDebug att konfigureras när windbg -I körs.

Debugger = "<Path>\WinDbg -p %ld -e %ld -g"
Auto = 1

I exemplen <är Path> den katalog där felsökningsprogrammet finns.

Parametrarna -p och -e skickar process-ID och händelse enligt beskrivningen tidigare.

-g skickar kommandot g (Go) till WinDbg och fortsätter körningen från den aktuella instruktionen.

Not Det finns ett betydande problem med att skicka kommandot g (Go). Problemet med den här metoden är att undantag inte alltid upprepas, vanligtvis på grund av ett tillfälligt villkor som inte längre finns när koden startas om. Mer information om det här problemet finns i .jdinfo (Använd JIT_DEBUG_INFO).

Undvik det här problemet genom att använda .jdinfo eller .dump /j. Med den här metoden kan felsökaren finnas i kontexten för kodfel av intresse. För mer information, se Just In Time-felsökning (JIT) senare i det här avsnittet.

CDB

Om du vill ange postmortem-felsökaren till CDB kör du cdb -iae (Installera AeDebug) eller cdb -iaecKeyString (Installera AeDebug med kommando).

C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\cdb.exe -iae
C:\Program Files (x86)\Windows Kits\10\Debuggers\x86\cdb.exe -iae

När parametern -iaec används anger KeyString en sträng som ska läggas till i slutet av kommandoraden som används för att starta felsökningsprogrammet postmortem. Om KeyString innehåller blanksteg måste det omges av citattecken.

C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\cdb.exe -iaec [KeyString]
C:\Program Files (x86)\Windows Kits\10\Debuggers\x86\cdb.exe -iaec [KeyString]

Det här kommandot visar ingenting om det lyckas och ett felmeddelande om det misslyckas.

NTSD

Om du vill ange postmortem-felsökaren till NTSD kör du ntsd -iae (Installera AeDebug) eller ntsd -iaecKeyString (Installera AeDebug med kommando).

C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\ntsd.exe -iae
C:\Program Files (x86)\Windows Kits\10\Debuggers\x86\ntsd.exe -iae

C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\ntsd.exe -iaec [KeyString]
C:\Program Files (x86)\Windows Kits\10\Debuggers\x86\ntsd.exe -iaec [KeyString]

Det här kommandot visar ingenting om det lyckas, men ett fel visas i ett nytt konsolfönster vid misslyckande.

Not Eftersom -p %ld -e %ld -g parametrar alltid visas först på kommandoraden i postmortem-felsökningsprogrammet bör du inte använda -iaec-växeln för att ange parametern -server eftersom -server inte fungerar om den inte visas först på kommandoraden. Om du vill installera ett postmortem-felsökningsprogram som innehåller den här parametern måste du redigera registret manuellt.

Visual Studio JIT-felsökningsprogram

Om Visual Studio har installerats registreras vsjitdebugger.exe som postmortem-felsökare. Visual Studio JIT-felsökningsprogrammet avser att processen ska felsökas interaktivt.

Debugger = "C:\WINDOWS\system32\vsjitdebugger.exe" -p %ld -e %ld

Om Visual Studio uppdateras eller installeras på nytt skrivs den här posten om och eventuella alternativa värden skrivs över.

Window Sysinternals ProcDump

Verktyget Windows Sysinternals ProcDump kan också användas för postmortem dump capture. Mer information om hur du använder och laddar ned ProcDump finns i ProcDump.

Precis som kommandot .dump WinDbg kan ProcDump fånga en dump av kraschen icke-interaktivt. Avbildningen kan inträffa i alla Windows-systemsessioner.

ProcDump avslutas när dumpfilavbildningen är klar, WER rapporterar sedan felet och felprocessen avslutas.

Använd procdump -i för att installera ProcDump och -u för att avinstallera ProcDump för både 32-bitars och 64-bitars debug felsökning efter programkrasch.

<Path>\procdump.exe -i

Installations- och avinstallationskommandona visar registervärdena som ändrats vid framgång och felen vid misslyckande.

Kommandoradsalternativen för ProcDump i registret är inställda på:

Debugger = <Path>\ProcDump.exe -accepteula -j "<DumpFolder>" %ld %ld %p

ProcDump använder alla tre parametrarna – PID, Event och JIT_DEBUG_INFO. Mer information om parametern JIT_DEBUG_INFO finns i JIT-felsökning (Just In Time) nedan.

Storleken på den insamlade dumpen är standardmässigt Mini (process/trådar/handtag/moduler/adressutrymme) om ingen storleksalternativ är angiven, MiniPlus (Mini plus MEM_PRIVATE sidor) när -mp är inställt, eller Full (allt minne – motsvarande ".dump /mA") när -ma är inställt.

För system med tillräckligt med diskutrymme rekommenderas en Fullständig (-ma) avbildning.

Använd -ma med alternativet -i för att ange en fullständig minnesinsamling. Du kan också ange en sökväg för dumpfilerna.

<Path>\procdump.exe -ma -i c:\Dumps

För system med begränsat diskutrymme rekommenderas en MiniPlus-inspelningsmetod (-mp).

<Path>\procdump.exe -mp -i c:\Dumps

Mappen som dumpfilen ska sparas i är valfri. Standardvärdet är den aktuella mappen. Mappen ska skyddas med en ACL som är lika med eller bättre än vad som används för C:\Windows\Temp. Mer information om hur du hanterar säkerhet som rör mappar finns i Säkerhet under felsökning av postmortem.

Om du vill avinstallera ProcDump som felsökningsprogram för postmortem och återställa de tidigare inställningarna använder du alternativet -u (Avinstallera).

<Path>\procdump.exe -u

Mer information om ProcDump finns i ProcDump och Windows SysInternals Administrator's Reference av Mark Russinovich och Aaron Margosis som publicerats av Microsoft Press.

Just-In-Time-felsökning

Ange kontext till det felande programmet

Som tidigare nämnts är det mycket önskvärt att ange kontexten till det undantag som orsakade kraschen med hjälp av parametern JIT_DEBUG_INFO. Mer information om detta finns i .jdinfo (Använd JIT_DEBUG_INFO).

Felsökningsverktyg för Windows

Det här exemplet visar hur du redigerar registret för att köra ett inledande kommando (-c) som använder .jdinfo-adresskommandot <> för att visa ytterligare undantagsinformation och ändrar kontexten till platsen för undantaget (ungefär som hur .ecxr används för att ange kontexten till undantagsposten).

Debugger = "<Path>\windbg.exe -p %ld -e %ld -c ".jdinfo 0x%p"
Auto = 1

Parametern %p är adressen till en JIT_DEBUG_INFO struktur i målprocessens adressutrymme. Parametern %p läggs till i förväg med 0x så att den tolkas som ett hexvärde. Mer information finns i .jdinfo (Använd JIT_DEBUG_INFO).

Om du vill felsöka en blandning av 32- och 64-bitarsappar konfigurerar du både 32- och 64-bitars registernycklarna (beskrivs ovan) och anger rätt sökväg till platsen för 32-bitars och 64-bitars WinDbg.exe.

Skapa en dumpfil med hjälp av .dump

Om du vill samla in en dumpfil när ett fel inträffar som innehåller JIT_DEBUG_INFO data använder du .dump /j-adressen<>.

<Path>\windbg.exe -p %ld -e %ld -c ".dump /j %p /u <DumpPath>\AeDebug.dmp; qd"

Använd alternativet /u för att generera ett unikt filnamn för att tillåta att flera dumpfiler skapas automatiskt. Mer information om alternativen finns i .dump (Create Dump File).

Den skapade dumpen kommer att ha JITDEBUG_INFO data lagrade som standardundantagskontext. I stället för att använda .jdinfo för att visa undantagsinformationen och ange kontexten använder du .exr -1 för att visa undantagsposten och .ecxr för att ange kontexten. Mer information finns i .exr (Visa undantagspost) och .ecxr (Visa undantagskontextpost).

Windows-felrapportering – q/qd

Hur felsökningssessionen slutar avgör om Felrapportering i Windows rapporterar felet.

Om felsökningssessionen kopplas från med qd innan felsökningsprogrammet stängs rapporterar WER felet.

Om felsökningssessionen avslutas med q (eller om felsökningsprogrammet stängs utan att kopplas från) rapporterar WER inte felet.

Lägg till ; q eller ; qd till slutet av kommandosträngen för att anropa önskat beteende.

Om du till exempel vill att WER ska rapportera felet när CDB har avbildat en dump konfigurerar du den här kommandosträngen.

<Path>\cdb.exe -p %ld -e %ld -c ".dump /j 0x%p /u c:\Dumps\AeDebug.dmp; qd"

Det här exemplet skulle göra det möjligt för WER att rapportera felet efter att WinDbg har skapat en minnesdump.

<Path>\windbg.exe -p %ld -e %ld -c ".dump /j %p /u <DumpPath>\AeDebug.dmp; qd""

Säkerhetsrisker

Om du överväger att aktivera postmortem-felsökning på en dator som du delar med andra kan du läsa Security During Postmortem Debugging (Säkerhet under felsökning av postmortem).

Feedback

Var den här sidan till hjälp?