Dumpinsamlings- och analysverktyg (dotnet-dump)

Den här artikeln gäller för version ✔️ dotnet-dump 3.0.47001 och senare versioner

Installera

Det finns två sätt att ladda ned och installera dotnet-dump:

• dotnet global tool:

  Om du vill installera den senaste versionen av dotnet-dumpNuGet-paketet använder du installationskommandot för dotnet-verktyget:

  dotnet tool install --global dotnet-dump
  

• Direkt nedladdning:

  Ladda ned det körbara verktyget som matchar din plattform:

  Olympiska Spelen (OS)	Plattform
  Windows	x86 | x64 | Arm | Arm-x64
  Linux	x64 | Arm | Arm64 | musl-x64 | musl-Arm64

Sammanfattning

dotnet-dump [-h|--help] [--version] <command>

beskrivning

Det globala verktyget dotnet-dump är ett sätt att samla in och analysera dumpar på Windows, Linux och macOS utan något inbyggt felsökningsprogram. Det här verktyget är viktigt på plattformar som Alpine Linux där en fullt fungerande lldb inte är tillgänglig. Med dotnet-dump verktyget kan du köra SOS-kommandon för att analysera krascher och skräpinsamlaren (GC), men det är inte ett internt felsökningsprogram, så saker som att visa interna stackramar stöds inte.

Alternativ

• --version

  Visar versionen av verktyget dotnet-dump.

• -h|--help

  Visar kommandoradshjälp.

Kommandon

dotnet-dump samla in

Samlar in en dump från en process.

Sammanfattning

dotnet-dump collect [-h|--help] [-p|--process-id] [-n|--name] [--type] [-o|--output] [--diag] [--crashreport]

Alternativ

• -h|--help

  Visar kommandoradshjälp.

• -p|--process-id <PID>

  Anger det process-ID-nummer som ska samlas in från en dump.

• -n|--name <name>

  Anger namnet på den process som en dump ska samlas in från.

• --type <Full|Heap|Mini>

  Anger dumptypen som avgör vilken typ av information som samlas in från processen. Det finns tre typer:

  • Full – Den största dumpen som innehåller allt minne, inklusive modulbilderna.
  • Heap – En stor och relativt omfattande dump som innehåller modullistor, trådlistor, alla staplar, undantagsinformation, hantera information och allt minne förutom mappade bilder.
  • Mini – En liten dump som innehåller modullistor, trådlistor, undantagsinformation och alla staplar.
  • Triage – En liten dump som innehåller modullistor, trådlistor, undantagsinformation, alla staplar och PII borttagen.

  Om det inte anges Full är standardvärdet.

• -o|--output <output_dump_path>

  Den fullständiga sökvägen och filnamnet där den insamlade dumpen ska skrivas. Kontrollera att användaren som dotnet-processen körs under har skrivbehörighet till den angivna katalogen.

  Om det inte anges:

  • Standardvärdet är .\dump_YYYYMMDD_HHMMSS.dmp på Windows.
  • Standardvärdet är ./core_YYYYMMDD_HHMMSS på Linux och macOS.

  YYYYMMDD är år/månad/dag och HHMMSS är timme/minut/sekund.

• --diag

  Aktiverar diagnostikloggning för dumpsamling.

• --crashreport

  Aktiverar generering av kraschrapporter.

dotnet-dump analysera

Startar ett interaktivt gränssnitt för att utforska en dump. Gränssnittet accepterar olika SOS-kommandon.

Sammanfattning

dotnet-dump analyze <dump_path> [-h|--help] [-c|--command]

Argument

• <dump_path>

  Anger sökvägen till dumpfilen som ska analyseras.

Alternativ

• -c|--command <debug_command>

  Kör kommandot vid start. Flera instanser av den här parametern kan användas i ett anrop till kedjekommandon. Kommandon körs i den ordning som de tillhandahålls på kommandoraden. Om du vill att dotnet-dumpen ska avslutas efter kommandona ska det sista kommandot vara "exit".

Analysera SOS-kommandon

dotnet-dump ps

Visar en lista över de dotnet-processer som dumpar kan samlas in från. dotnet-dump Version 6.0.320703 och senare versioner visar även de kommandoradsargument som varje process startades med, om den är tillgänglig.

Sammanfattning

dotnet-dump ps [-h|--help]

Exempel

Anta att du startar en tidskrävande app med kommandot dotnet run --configuration Release. I ett annat fönster kör du kommandot dotnet-dump ps. Utdata visas på följande sätt. Eventuella kommandoradsargument visas i dotnet-dump version 6.0.320703 och senare.

> dotnet-dump ps

  21932 dotnet     C:\Program Files\dotnet\dotnet.exe   run --configuration Release
  36656 dotnet     C:\Program Files\dotnet\dotnet.exe

Att använda dotnet-dump

Det första steget är att samla in en dump. Det här steget kan hoppas över om en kärndump redan har genererats. Operativsystemet eller .NET Core-körningens inbyggda dumpargenereringsfunktion kan var och en skapa kärndumpar.

$ dotnet-dump collect --process-id 1902
Writing minidump to file ./core_20190226_135837
Written 98983936 bytes (24166 pages) to core file
Complete

Analysera nu kärndumpningen analyze med kommandot :

$ dotnet-dump analyze ./core_20190226_135850
Loading core dump: ./core_20190226_135850
Ready to process analysis commands. Type 'help' to list available commands or 'help [command]' to get detailed help on a command.
Type 'quit' or 'exit' to exit the session.
>

Den här åtgärden ger en interaktiv session som accepterar kommandon som:

> clrstack
OS Thread Id: 0x573d (0)
    Child SP               IP Call Site
00007FFD28B42C58 00007fb22c1a8ed9 [HelperMethodFrame_PROTECTOBJ: 00007ffd28b42c58] System.RuntimeMethodHandle.InvokeMethod(System.Object, System.Object[], System.Signature, Boolean, Boolean)
00007FFD28B42DD0 00007FB1B1334F67 System.Reflection.RuntimeMethodInfo.Invoke(System.Object, System.Reflection.BindingFlags, System.Reflection.Binder, System.Object[], System.Globalization.CultureInfo) [/root/coreclr/src/mscorlib/src/System/Reflection/RuntimeMethodInfo.cs @ 472]
00007FFD28B42E20 00007FB1B18D33ED SymbolTestApp.Program.Foo4(System.String) [/home/mikem/builds/SymbolTestApp/SymbolTestApp/SymbolTestApp.cs @ 54]
00007FFD28B42ED0 00007FB1B18D2FC4 SymbolTestApp.Program.Foo2(Int32, System.String) [/home/mikem/builds/SymbolTestApp/SymbolTestApp/SymbolTestApp.cs @ 29]
00007FFD28B42F00 00007FB1B18D2F5A SymbolTestApp.Program.Foo1(Int32, System.String) [/home/mikem/builds/SymbolTestApp/SymbolTestApp/SymbolTestApp.cs @ 24]
00007FFD28B42F30 00007FB1B18D168E SymbolTestApp.Program.Main(System.String[]) [/home/mikem/builds/SymbolTestApp/SymbolTestApp/SymbolTestApp.cs @ 19]
00007FFD28B43210 00007fb22aa9cedf [GCFrame: 00007ffd28b43210]
00007FFD28B43610 00007fb22aa9cedf [GCFrame: 00007ffd28b43610]

Så här ser du ett ohanterat undantag som dödade din app:

> pe -lines
Exception object: 00007fb18c038590
Exception type:   System.Reflection.TargetInvocationException
Message:          Exception has been thrown by the target of an invocation.
InnerException:   System.Exception, Use !PrintException 00007FB18C038368 to see more.
StackTrace (generated):
SP               IP               Function
00007FFD28B42DD0 0000000000000000 System.Private.CoreLib.dll!System.RuntimeMethodHandle.InvokeMethod(System.Object, System.Object[], System.Signature, Boolean, Boolean)
00007FFD28B42DD0 00007FB1B1334F67 System.Private.CoreLib.dll!System.Reflection.RuntimeMethodInfo.Invoke(System.Object, System.Reflection.BindingFlags, System.Reflection.Binder, System.Object[], System.Globalization.CultureInfo)+0xa7 [/root/coreclr/src/mscorlib/src/System/Reflection/RuntimeMethodInfo.cs @ 472]
00007FFD28B42E20 00007FB1B18D33ED SymbolTestApp.dll!SymbolTestApp.Program.Foo4(System.String)+0x15d [/home/mikem/builds/SymbolTestApp/SymbolTestApp/SymbolTestApp.cs @ 54]
00007FFD28B42ED0 00007FB1B18D2FC4 SymbolTestApp.dll!SymbolTestApp.Program.Foo2(Int32, System.String)+0x34 [/home/mikem/builds/SymbolTestApp/SymbolTestApp/SymbolTestApp.cs @ 29]
00007FFD28B42F00 00007FB1B18D2F5A SymbolTestApp.dll!SymbolTestApp.Program.Foo1(Int32, System.String)+0x3a [/home/mikem/builds/SymbolTestApp/SymbolTestApp/SymbolTestApp.cs @ 24]
00007FFD28B42F30 00007FB1B18D168E SymbolTestApp.dll!SymbolTestApp.Program.Main(System.String[])+0x6e [/home/mikem/builds/SymbolTestApp/SymbolTestApp/SymbolTestApp.cs @ 19]

StackTraceString: <none>
HResult: 80131604

Analysera minnesläckor och allokeringar

Minnesläckor uppstår när appen innehåller referenser till objekt som inte längre behövs, vilket hindrar skräpinsamlaren från att frigöra minne. Använd dotnet-dump för att identifiera minnesläckor, hitta de största objekten och förstå var minnet förbrukas.

En fullständig genomgång av felsökning av en minnesläcka finns i Felsöka en minnesläcka i .NET.

Identifiera de största objekten

dumpheap Använd kommandot med -stat alternativet för att se en sammanfattning av objekt på heapen, sorterad efter total storlek:

> dumpheap -stat

Statistics:
              MT    Count    TotalSize Class Name
00007f6c1eeefba8      576        59904 System.Reflection.RuntimeMethodInfo
00007f6c1dc021c8     1749        95696 System.SByte[]
00000000008c9db0     3847       116080      Free
00007f6c1e784a18      175       128640 System.Char[]
00007f6c1dbf5510      217       133504 System.Object[]
00007f6c1dc014c0      467       416464 System.Byte[]
00007f6c21625038        6      4063376 testwebapi.Controllers.Customer[]
00007f6c20a67498   200000      4800000 testwebapi.Controllers.Customer
00007f6c1dc00f90   206770     19494060 System.String
Total 428516 objects

De här utdata visar vilka typer som förbrukar mest minne. I det här exemplet System.String förbrukar objekt cirka 19 MB och Customer objekt förbrukar cirka 4,8 MB.

Identifiera objekt efter namnområde eller sammansättning

Om du vill ta reda på vilka moduler eller namnområden som förbrukar minne använder du -type alternativet med ett partiellt typnamn för att filtrera resultat:

> dumpheap -type MyCompany.Data -stat

Statistics:
              MT    Count    TotalSize Class Name
00007f6c21625038    15000      3600000 MyCompany.Data.CustomerRecord
00007f6c21625040     8000      2560000 MyCompany.Data.OrderHistory
00007f6c21625048     2000       960000 MyCompany.Data.ProductCache
Total 25000 objects, 7120000 bytes

Den här metoden hjälper dig att identifiera vilka delar av kodbasen som ansvarar för minnesförbrukning.

Hitta det högsta antalet instansieringar

Om du vill se vilka typer som har flest instanser, oavsett total storlek, tittar du på kolumnen Antal i dumpheap -stat utdata. Objekt med högt antal instanser kan tyda på ineffektiva problem med att skapa eller cachelagra objekt:

> dumpheap -stat

Statistics:
              MT    Count    TotalSize Class Name
00007f6c1dc00f90   206770     19494060 System.String
00007f6c20a67498   200000      4800000 testwebapi.Controllers.Customer
00007f6c1dc021c8     1749        95696 System.SByte[]

Det här exemplet visar 206 770 String instanser och 200 000 Customer instanser.

Analysera objektreferenser med gcroot

När du har identifierat stora eller många objekt kan du använda gcroot för att ta reda på varför ett objekt inte är skräpinsamling. Kommandot gcroot visar referenskedjan från GC-rötter till ett specifikt objekt:

> dumpheap -mt 00007f6c20a67498
         Address               MT     Size
00007f6ad09421f8 00007f6c20a67498       24
...

> gcroot 00007f6ad09421f8

Thread 3f68:
    00007F6795BB58A0 00007F6C1D7D0745 testwebapi.Controllers.CustomerCache.GetAll()
        rbx:  (interior)
            ->  00007F6BDFFFF038 System.Object[]
            ->  00007F69D0033570 testwebapi.Controllers.Processor
            ->  00007F69D0033588 testwebapi.Controllers.CustomerCache
            ->  00007F69D00335A0 System.Collections.Generic.List`1[[testwebapi.Controllers.Customer]]
            ->  00007F6C000148A0 testwebapi.Controllers.Customer[]
            ->  00007F6AD0942258 testwebapi.Controllers.Customer

Found 1 root.

Det här utdata visar att Customer objektet innehas av ett CustomerCache objekt, vilket hjälper dig att identifiera källan till läckan i koden.

Analysera minne efter objektstorlek

-min Använd alternativen och -max för att filtrera objekt efter storlek:

> dumpheap -min 100000 -stat

Statistics:
              MT    Count    TotalSize Class Name
00007f6c21625038        6      4063376 testwebapi.Controllers.Customer[]
00007f6c1dc014c0       12       416464 System.Byte[]
Total 18 objects

Det här kommandot visar endast objekt som är större än 100 000 byte, vilket hjälper dig att fokusera på de största minneskonsumenterna.

Hitta dödlägen

Använd dotnet-dump för att diagnostisera dödlägen där trådar blockeras i väntan på resurser. En fullständig genomgång av felsökning av dödlägen finns i Felsöka ett dödläge i .NET.

Visa en lista över alla trådar

threads Använd kommandot för att se alla hanterade trådar:

> threads
*0 0x1DBFF (121855)
 1 0x1DC01 (121857)
 2 0x1DC02 (121858)
 ...

Granska trådstackar

Använd clrstack -all för att se anropsstackarna för alla trådar:

> clrstack -all

Leta efter mönster där flera trådar blockeras på Monitor.Enter eller liknande synkroniseringspri primitiver.

Hitta låsägare

syncblk Använd kommandot för att se vilka trådar som innehåller lås och vilka trådar som väntar:

> syncblk
Index         SyncBlock MonitorHeld Recursion Owning Thread Info          SyncBlock Owner
   43 00000246E51268B8          603         1 0000024B713F4E30 5634  28   00000249654b14c0 System.Object
   44 00000246E5126908            3         1 0000024B713F47E0 51d4  29   00000249654b14d8 System.Object

Kolumnen MonitorHeld visar antalet trådar som väntar på låset. Kolumnen Ägande trådinformation visar vilken tråd som äger låset.

Scenarier för avancerad minnesanalys

Jämföra flera dumpar

Om du vill förstå minnestillväxt över tid samlar du in flera dumpar och jämför dem:

1. Samla in en baslinjedump: dotnet-dump collect -p <pid> -o baseline.dmp
2. Låt appen köras och förbruka mer minne.
3. Samla in en andra dump: dotnet-dump collect -p <pid> -o after.dmp
4. Analysera båda dumparna och jämför dumpheap -stat resultatet.

Leta efter typer som har betydligt fler instanser eller större totalstorlekar i den andra dumpen.

Analysera minne för specifika objekttyper

Så här dumpar du alla instanser av en viss typ:

> dumpheap -type Customer
         Address               MT     Size
00007f6ad09421f8 00007f6c20a67498       24
00007f6ad0942210 00007f6c20a67498       24
...

Använd dumpobj sedan för att undersöka enskilda objekt:

> dumpobj 00007f6ad09421f8
Name:        testwebapi.Controllers.Customer
MethodTable: 00007f6c20a67498
EEClass:     00007f6c21625000
Size:        24(0x18) bytes
File:        /app/testwebapi.dll
Fields:
              MT    Field   Offset                 Type VT     Attr            Value Name
00007f6c1dc00f90  4000001        8        System.String  0 instance 00007f6ad09421f0 Name
00007f6c1dbf4c18  4000002       10         System.Int32  1 instance               42 Id

Samla in en dump i en Docker-container

dotnet-dump kräver ptrace funktioner i containern. Ett vanligt sätt att bevilja dem är att starta containern med --cap-add=SYS_PTRACE. Beroende på din miljö kan du också behöva justera containerns seccomp-profil. Se Dumpar: Vanliga frågor och svar om hjälp med att diagnostisera problem med containersäkerhetskonfiguration.

Om du vill installera dotnet-dump i en produktionsbild utan .NET SDK använder du nedladdningslänkarna direct från avsnittet Installera eller använder en multi-stage Docker-version för att kopiera verktygsbinärfilerna från en SDK-avbildning. Fullständig vägledning för containerdiagnostik finns i Samla in diagnostik i Linux-containrar.

Felsöka problem med dumpinsamling

Dumpinsamling kräver att processen kan anropa ptrace. Om du har problem med att samla in dumpar kan den miljö som du kör på konfigureras för att begränsa sådana anrop. Se våra dumpar: Vanliga frågor och svar om felsökningstips och potentiella lösningar på vanliga problem.

Se även

• Samla in diagnostik i Linux-containrar
• Blogg för att samla in och analysera minnesdumpar
• Heapanalysverktyg (dotnet-gcdump)