Hulpprogramma voor dumpverzameling en -analyse (dotnet-dump)

Dit artikel is van toepassing op: ✔️ dotnet-dump versie 3.0.47001 en nieuwere versies

Installeren

Er zijn twee manieren om te downloaden en installeren dotnet-dump:

• dotnet global tool:

  Als u de nieuwste versie van het NuGet-pakket wilt installeren, gebruikt u de installatieopdracht van het dotnet-dumpdotnet-hulpprogramma:

  dotnet tool install --global dotnet-dump
  

• Directe download:

  Download het uitvoerbare hulpprogramma dat overeenkomt met uw platform:

  Besturingssysteem	Platvorm
  Windows	x86 | x64 | Arm | Arm-x64
  Linux	x64 | Arm | Arm64 | musl-x64 | musl-Arm64

Samenvatting

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

Beschrijving

Het dotnet-dump globale hulpprogramma is een manier om dumps te verzamelen en te analyseren op Windows, Linux en macOS zonder dat er systeemeigen foutopsporingsprogramma betrokken is. Dit hulpprogramma is belangrijk op platforms zoals Alpine Linux, waar een volledig werkende lldb versie niet beschikbaar is. Met dotnet-dump het hulpprogramma kunt u SOS-opdrachten uitvoeren om crashes en de garbagecollector (GC) te analyseren, maar het is geen systeemeigen foutopsporingsprogramma, zodat het weergeven van systeemeigen stackframes niet wordt ondersteund.

Opties

• --version

  Geeft de versie van het dotnet-dump-hulpprogramma weer.

• -h|--help

  Toont opdrachtregelhulp.

Opdracht

dotnet-dump verzamelen

Legt een dump vast van een proces.

Samenvatting

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

Opties

• -h|--help

  Toont opdrachtregelhulp.

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

  Hiermee geeft u het proces-id-nummer voor het verzamelen van een dump van.

• -n|--name <name>

  Hiermee geeft u de naam van het proces voor het verzamelen van een dump van.

• --type <Full|Heap|Mini>

  Hiermee geeft u het dumptype op, waarmee wordt bepaald welke soorten informatie uit het proces worden verzameld. Er zijn drie typen:

  • Full - De grootste dump met alle geheugen inclusief de module-installatiekopieën.
  • Heap - Een grote en relatief uitgebreide dump met modulelijsten, threadlijsten, alle stacks, uitzonderingsinformatie, handle-informatie en alle geheugen, met uitzondering van toegewezen afbeeldingen.
  • Mini - Een kleine dump met modulelijsten, threadlijsten, uitzonderingsgegevens en alle stacks.
  • Triage - Een kleine dump met modulelijsten, threadlijsten, uitzonderingsgegevens, alle stacks en PII verwijderd.

  Als dit niet is opgegeven, Full is dit de standaardwaarde.

• -o|--output <output_dump_path>

  Het volledige pad en de bestandsnaam waarin de verzamelde dump moet worden geschreven. Zorg ervoor dat de gebruiker waaronder het dotnet-proces wordt uitgevoerd schrijfmachtigingen heeft voor de opgegeven map.

  Als dit niet is opgegeven:

  • De standaardinstelling is .\dump_YYYYMMDD_HHMMSS.dmp op Windows.
  • Standaard ingesteld op ./core_YYYYMMDD_HHMMSS in Linux en macOS.

  JJJJMMDD is Year/Month/Day en HHMMSS is Hour/Minute/Second.

• --diag

  Hiermee schakelt u diagnostische logboekregistratie van dumpverzamelingen in.

• --crashreport

  Hiermee schakelt u het genereren van crashrapporten in.

dotnet-dump analyseren

Start een interactieve shell om een dump te verkennen. De shell accepteert verschillende SOS-opdrachten.

Samenvatting

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

Argumenten

• <dump_path>

  Hiermee geeft u het pad naar het dumpbestand dat moet worden geanalyseerd.

Opties

• -c|--command <debug_command>

  Hiermee voert u de opdracht uit bij het starten. Meerdere exemplaren van deze parameter kunnen worden gebruikt in een aanroep om opdrachten te koppelen. Opdrachten worden uitgevoerd in de volgorde waarin ze zijn opgegeven op de opdrachtregel. Als u wilt dat dotnetdump na de opdrachten wordt afgesloten, moet de laatste opdracht 'exit' zijn.

SOS-opdrachten analyseren

dotnet-dump ps

Een overzicht van de dotnet-processen waaruit dumps kunnen worden verzameld. dotnet-dump versie 6.0.320703 en latere versies geven ook de opdrachtregelargumenten weer waarmee elk proces is gestart, indien beschikbaar.

Samenvatting

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

Opmerking

Stel dat u een langlopende app start met behulp van de opdracht dotnet run --configuration Release. In een ander venster voert u de dotnet-dump ps opdracht uit. De uitvoer die u ziet, is als volgt. De opdrachtregelargumenten, indien aanwezig, worden weergegeven in dotnet-dump versie 6.0.320703 en hoger.

> dotnet-dump ps

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

Het gebruiken van dotnet-dump

De eerste stap is het verzamelen van een dump. Deze stap kan worden overgeslagen als er al een kerndump is gegenereerd. Het besturingssysteem of de ingebouwde dumpgeneratiefunctie van de .NET Core-runtime kunnen elke kerndump maken.

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

Analyseer nu de kerndump met de analyze opdracht:

$ 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.
>

Met deze actie wordt een interactieve sessie weergegeven die opdrachten accepteert zoals:

> 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]

Als u een onverwerkte uitzondering wilt zien die uw app heeft gedood:

> 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

Geheugenlekken en toewijzingen analyseren

Geheugenlekken treden op wanneer uw app verwijzingen bevat naar objecten die niet meer nodig zijn, waardoor de garbagecollector geen geheugen meer kan vrijmaken. Gebruik dotnet-dump dit om geheugenlekken te identificeren, de grootste objecten te vinden en te begrijpen waar geheugen wordt verbruikt.

Zie Debug a memory leak in .NET voor een volledige procedure voor het opsporen van fouten in een geheugenlek.

De grootste objecten identificeren

Gebruik de dumpheap opdracht met de -stat optie om een samenvatting van objecten op de heap weer te geven, gesorteerd op totale grootte:

> 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

In deze uitvoer ziet u welke typen het meeste geheugen verbruiken. In dit voorbeeld System.String verbruiken objecten ongeveer 19 MB en Customer verbruiken objecten ongeveer 4,8 MB.

Objecten identificeren op naamruimte of assembly

Als u wilt zoeken welke modules of naamruimten geheugen verbruiken, gebruikt u de -type optie met een gedeeltelijke typenaam om resultaten te filteren:

> 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

Met deze aanpak kunt u bepalen welke onderdelen van uw codebasis verantwoordelijk zijn voor geheugenverbruik.

Het hoogste aantal instantiëringen zoeken

Als u wilt zien welke typen de meeste exemplaren hebben, ongeacht de totale grootte, bekijkt u de kolom Aantal in de dumpheap -stat uitvoer. Objecten met een hoog aantal exemplaren kunnen duiden op inefficiënte problemen met het maken of opslaan van objecten in cache:

> dumpheap -stat

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

In dit voorbeeld ziet u 206.770 String exemplaren en 200.000 Customer exemplaren.

Objectverwijzingen analyseren met gcroot

Nadat u grote of talrijke objecten hebt geïdentificeerd, gebruikt gcroot u om erachter te komen waarom een object niet wordt verzameld. De gcroot opdracht toont de referentieketen van GC-roots naar een specifiek object:

> 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.

Deze uitvoer laat zien dat het Customer object wordt vastgehouden door een CustomerCache object, waarmee u de bron van het lek in uw code kunt identificeren.

Geheugen analyseren op objectgrootte

Gebruik de -min en -max opties om objecten te filteren op grootte:

> dumpheap -min 100000 -stat

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

Met deze opdracht worden alleen objecten weergegeven die groter zijn dan 100.000 bytes, zodat u zich kunt richten op de grootste geheugengebruikers.

Vind impasses

Gebruik dotnet-dump dit om impassesituaties te diagnosticeren waarbij threads worden geblokkeerd op resources. Zie Debug a deadlock in .NET voor een volledige impassefoutopsporing.

Alle threads weergeven

Gebruik de threads opdracht om alle beheerde threads weer te geven:

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

Threadstacks onderzoeken

Gebruik clrstack -all dit om de aanroepstacks van alle threads weer te geven:

> clrstack -all

Zoek naar patronen waarbij meerdere threads worden geblokkeerd op Monitor.Enter of vergelijkbare synchronisatieprimitieven.

Vergrendelingseigenaren zoeken

Gebruik de syncblk opdracht om te zien welke threads vergrendelingen bevatten en welke threads wachten:

> 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

In de kolom MonitorHeld ziet u het aantal threads dat wacht op de vergrendeling. In de kolom Threadinfo wordt weergegeven welke thread eigenaar is van de vergrendeling.

Scenario's voor geavanceerde geheugenanalyse

Meerdere dumps vergelijken

Als u de geheugengroei in de loop van de tijd wilt begrijpen, verzamelt u meerdere dumps en vergelijkt u deze:

1. Verzamel een basislijndump: dotnet-dump collect -p <pid> -o baseline.dmp
2. Laat uw app uitvoeren en meer geheugen verbruiken.
3. Verzamel een tweede dump: dotnet-dump collect -p <pid> -o after.dmp
4. Analyseer zowel dumps als vergelijk de dumpheap -stat resultaten.

Zoek naar typen met aanzienlijk meer exemplaren of grotere totale grootten in de tweede dump.

Geheugen analyseren voor specifieke objecttypen

Alle exemplaren van een specifiek type dumpen:

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

Gebruik vervolgens dumpobj om afzonderlijke objecten te onderzoeken:

> 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

Een dump verzamelen in een Docker-container

dotnet-dump vereist ptrace mogelijkheden in de container. Een veelgebruikte manier om ze te verlenen, is door de container te starten met --cap-add=SYS_PTRACE. Afhankelijk van uw omgeving moet u mogelijk ook het seccomp-profiel van de container aanpassen. Zie de dumps: veelgestelde vragen over het diagnosticeren van problemen met de configuratie van containerbeveiliging.

Als u dotnet-dump wilt installeren in een productieinstallatiekopie zonder de .NET SDK, gebruikt u de direct downloadkoppelingen uit de sectie Installeren of gebruikt u een multi-stage Docker-build om de binaire bestanden van een SDK-installatiekopie te kopiëren. Zie Diagnostische gegevens verzamelen in Linux-containers voor volledige richtlijnen voor containerdiagnose.

Problemen met dumpverzameling oplossen

Dumpverzameling vereist dat het proces kan worden aangeroepen ptrace. Als u problemen ondervindt met het verzamelen van dumps, is de omgeving waarop u werkt mogelijk geconfigureerd om dergelijke aanroepen te beperken. Zie onze dumps: veelgestelde vragen over het oplossen van tips en mogelijke oplossingen voor veelvoorkomende problemen.

Zie ook

• Diagnostische gegevens verzamelen in Linux-containers
• Blog geheugendumps verzamelen en analyseren
• Hulpprogramma voor heap-analyse (dotnet-gcdump)