Partage via

Utilitaire de collecte et d’analyse de vidage (dotnet-dump)

Cet article s’applique à : ✔️ version 3.0.47001 et ultérieures

Notes

dotnet-dump pour macOS est pris en charge uniquement avec .NET 5 et versions ultérieures.

Installer

Il existe deux façons de télécharger et d’installer :

  • outil global dotnet :

    Pour installer la dernière version du package NuGet, utilisez la commande dotnet tool install :

    dotnet tool install --global dotnet-dump

  • Téléchargement direct :

    Téléchargez l’exécutable de l’outil qui correspond à votre plateforme :

    Système d''exploitation Plateforme
    Windows x86x64BrasArm-x64
    Linux x64BrasArm64musl-x64musl-Arm64

Notes

Pour utiliser sur une application x86, vous avez besoin d’une version x86 correspondante de l’outil.

Synopsis

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

Descriptif

L’outil global dotnet-dump est un moyen de collecter et d’analyser des vidages sur Windows, Linux et macOS sans débogueur natif impliqué. Cet outil est important sur les plateformes comme Alpine Linux où un outil entièrement opérationnel n’est pas disponible. L’outil vous permet d’exécuter des commandes SOS pour analyser les incidents et le récupérateur de mémoire (GC), mais il ne s’agit pas d’un débogueur natif. Les éléments tels que l’affichage d’images de frames de pile natives ne sont pas pris en charge.

Paramètres

  • --version

    Affiche la version de l’utilitaire dotnet-dump.

  • -h|--help

    Affiche l’aide en ligne de commande.

Commandes

Commande
dotnet-dump collecte
analyse dotnet-dump
dotnet-dump ps

dotnet-dump collecte

Capture un vidage d’un processus.

Synopsis

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

Paramètres

  • -h|--help

    Affiche l’aide en ligne de commande.

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

    Spécifie le numéro d’ID de processus à partir duquel collecter une image mémoire.

  • -n|--name <name>

    Spécifie le nom du processus à partir duquel collecter une image mémoire.

  • --type <Full|Heap|Mini>

    Spécifie le type d’image mémoire, qui détermine les types d’informations collectées à partir du processus. Il existe trois types :

    •  - Image mémoire la plus volumineuse contenant toutes les mémoires, y compris les images de module.
    •  - Image mémoire volumineuse et relativement complète contenant des listes de modules, des listes de threads, toutes les piles, des informations sur l’exception, la gestion des informations et toutes les mémoires, à l’exception des images mappées.
    •  - Petite image mémoire contenant des listes de modules, des listes de threads, des informations d’exception et toutes les piles.
    • - Un petit vidage contenant des listes de modules, des listes de threads, des informations d’exception, toutes les piles et des informations d’identification personnelle supprimées.

    S’il n’est pas spécifié, est la valeur par défaut.

  • -o|--output <output_dump_path>

    Chemin d’accès complet et nom de fichier où l’image mémoire collectée doit être écrite. Vérifiez que l’utilisateur sous lequel le processus dotnet est exécuté dispose d’autorisations d’écriture dans le répertoire spécifié.

    Si elle n'est pas spécifiée :

    • La valeur par défaut est .\dump_YYYYMMDD_HHMMSS.dmp sur Windows.
    • La valeur par défaut est ./core_YYYYMMDD_HHMMSS sur Linux et macOS.

    AAAAMMJJ est Year/Month/Day et HHMMSS est Hour/Minute/Seconde.

  • --diag

    Active la journalisation des diagnostics de collecte d’image mémoire.

  • --crashreport

    Active la génération de rapports d’incident.

Notes

Sous Linux et macOS, cette commande s’attend à ce que l’application cible et partagent la même variable d’environnement . Dans le cas contraire, la commande expire.

Notes

Pour collecter une image mémoire à l’aide de , il faut l’exécuter en tant que même utilisateur que l’utilisateur exécutant le processus cible ou en tant que racine. Sinon, l’outil ne parvient pas à établir une connexion avec le processus cible.

Notes

La collecte d’un vidage complet ou de tas peut entraîner la page du système d’exploitation dans une mémoire virtuelle importante pour le processus cible. Si le processus cible s’exécute dans un conteneur avec une limite de mémoire appliquée, l’utilisation accrue de la mémoire peut entraîner l’arrêt du système d’exploitation du conteneur si la limite a été dépassée. Nous vous recommandons de tester pour vous assurer que la limite de mémoire est suffisamment élevée. Une autre option consiste à modifier ou supprimer temporairement la limite avant la collecte de vidage si votre environnement le prend en charge.

analyse dotnet-dump

Démarre un interpréteur de commandes interactif pour explorer une image mémoire. L’interpréteur de commandes accepte diverses commandes SOS.

Synopsis

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

Les arguments

  • <dump_path>

    Spécifie le chemin d’accès au fichier d’image mémoire à analyser.

Paramètres

  • -c|--command <debug_command>

    Exécute la commande au démarrage. Plusieurs instances de ce paramètre peuvent être utilisées dans un appel pour chaîner des commandes. Les commandes sont exécutées dans l’ordre dans lequel elles sont fournies sur la ligne de commande. Si vous souhaitez que dotnet dump se termine après les commandes, votre dernière commande doit être « exit ».

Analyser les commandes SOS

Commande Fonction
analyzeoom Affiche les informations pour le dernier OOM qui s’est produit sur une requête d’allocation au tas GC.
clrmodules Répertorie les modules managés dans le processus.
clrstack Fournit uniquement une trace de la pile du code managé.
clrthreads Répertorie les threads managés en cours d’exécution.
clru Affiche un désassemblage annoté d’une méthode managée.
ou Vide le contenu de la mémoire.
dbgout Active/désactive () la journalisation SOS interne.
dso Affiche tous les objets managés recherchés dans les limites de la pile actuelle.
dumpalc Affiche des détails sur un AssemblyLoadContext pouvant être collecté sur lequel l’objet spécifié est chargé.
dumparray Affiche des détails sur un tableau managé.
dumpasync Affiche des informations sur les machines à états asynchrones sur le tas GC.
dumpassembly Affiche des détails sur un assembly.
dumpclass Affiche des informations sur la structure à l'adresse spécifiée.
dumpconcurrentdictionary Affiche le contenu du dictionnaire simultané.
dumpconcurrentqueue Affiche le contenu de file d’attente simultané.
dumpdelegate Affiche des informations sur un délégué.
dumpdomain Affiche des informations sur tous les assemblys au sein de tous les AppDomains ou de l’assembly spécifié.
dumpgcdata Affiche des informations sur les données GC.
dumpgen Affiche le contenu du tas pour la génération spécifiée.
dumpheap Affiche des informations sur le tas récupéré par le récupérateur de mémoire et des statistiques de collection concernant les objets.
dumpil Affiche le langage intermédiaire commun (CIL) associé à une méthode managée.
dumplog Écrit le contenu d'un journal de contrainte en mémoire dans le fichier spécifié.
dumpmd Affiche des informations sur la structure à l'adresse spécifiée.
dumpmodule Affiche des informations sur le module à l'adresse spécifiée.
dumpmt Affiche des informations sur la table de méthodes à l'adresse spécifiée.
dumpobj Affiche des informations sur l’objet à l’adresse spécifiée.
dumpruntimetypes Recherche tous les objets System.RuntimeType dans le tas GC et imprime le nom du type et la MethodTable auxquels ils font également référence.
dumpsig Vide la signature d’une méthode ou d’un champ spécifié par .
dumpsigelem Vide un élément unique d'un objet de signature.
dumpstackobjects Affiche tous les objets managés recherchés dans les limites de la pile actuelle.
dumpvc Affiche des informations sur les champs d’une classe de valeur.
eeheap Affiche des informations sur la mémoire du processus consommée par les structures de données internes du runtime.
eestack S’exécute sur tous les threads du processus.
eeversion Affiche des informations sur les versions du runtime et de SOS.
ehinfo Affiche les blocs de gestion des exceptions dans une méthode JIT.
ou Quitte le mode interactif.
finalizequeue Affiche tous les objets enregistrés pour la finalisation.
findappdomain Tente de résoudre l’AppDomain d’un objet GC.
gchandles Affiche des statistiques sur les handles du récupérateur de mémoire dans le processus.
gcheapstat Affiche des statistiques sur le récupérateur de mémoire.
gcinfo Affiche l’encodage GC JIT pour une méthode.
gcroot Affiche des informations sur les références (ou racines) à l’objet à l’adresse spécifiée.
gcwhere Affiche l’emplacement dans le tas GC de l’adresse spécifiée.
histclear Libère toutes les ressources utilisées par la famille de commandes Hist.
histinit Initialise les structures SOS du journal de contrainte enregistré dans l’élément débogué.
histobj Examine tous les enregistrements de réadressage du journal de contrainte et affiche la chaîne des réadressages de garbage collection qui ont pu mener à l’adresse passée comme un argument.
histobjfind Affiche toutes les entrées de journal qui référencent l’objet à l’adresse spécifiée.
histroot Affiche les informations liées aux promotions et aux réadressages de la racine spécifiée.
histstats Affiche les statistiques du journal de contrainte.
ip2md Affiche la structure à l'adresse spécifiée dans le code compilé juste-à-temps (JIT).
listnearobj Affiche l’objet qui précède et succède l’adresse spécifiée.
logopen Active la journalisation des fichiers de console.
logclose Désactive la journalisation des fichiers de console.
logging Active/désactive la journalisation SOS interne.
ou Affiche les modules natifs dans le processus.
name2ee Affiche les structures et pour le type ou la méthode spécifié dans le module spécifié.
objsize Affiche la taille de l'objet spécifié.
parallelstacks Affiche la pile des threads fusionnés de la même façon que le panneau Visual Studio « Piles parallèles ».
pathto Affiche le chemin d’accès GC de à .
ou Affiche et met en forme les champs de tous les objets dérivés de la classe à l'adresse spécifiée.
ou Affiche les registres du thread.
runtimes Liste les runtimes de la cible ou change le runtime par défaut.
setclrpath Définit le chemin pour charger des fichiers dac/dbi coreclr en utilisant .
setsymbolserver Active la prise en charge du serveur de symboles.
sos Exécute différentes commandes de débogage coreclr. Utilisez la syntaxe . Pour plus d’informations, consultez « soshelp ».
ou Affiche toutes les commandes disponibles.
ou Affiche la commande spécifiée.
syncblk Affiche des informations sur le conteneur syncBlock.
taskstate Affiche un état de tâche dans un format lisible par l’utilisateur.
threadpool Affiche des informations sur le pool de threads d’exécution.
threadpoolqueue Affiche les éléments de travail du pool de threads mis en file d’attente.
threadstate Pretty imprime la signification d’un état de threads.
ou Définit ou affiche l’ID de thread actuel pour les commandes SOS.
timerinfo Affiche des informations sur les minuteurs en cours d’exécution.
token2ee Affiche la structure MethodTable et la structure MethodDesc pour le jeton et le module spécifiés.
traverseheap Écrit les informations du tas dans un dans un format compris par le profileur CLR.
verifyheap Vérifie le tas GC pour détecter les signes d’altération.
verifyobj Vérifie l’objet passé comme argument à la recherche de signes d’altération.

Notes

Vous trouverez plus d’informations dans SOS Débogage extension pour .NET.

dotnet-dump ps

Répertorie les processus dotnet à partir desquels les images mémoires peuvent être collectées. version 6.0.320703 et versions ultérieures affichent également les arguments de ligne de commande avec lesquels chaque processus a été démarré, s’ils sont disponibles.

Synopsis

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

Exemple

Supposons que vous démarriez une application de longue durée à l’aide de la commande . Dans une autre fenêtre, vous exécutez la commande . La sortie que vous verrez est la suivante. Les arguments de ligne de commande, le cas échéant, sont affichés dans version 6.0.320703 et versions ultérieures.

> dotnet-dump ps

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

Utilisation de

La première étape consiste à collecter une image mémoire. Cette étape peut être ignorée si une image mémoire de cœur a déjà été générée. Le système d'exploitation ou la fonctionnalité intégrée de .NET Core runtime dump peut créer des vidages de base.

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

À présent, analysez l’image mémoire du cœur avec la commande  :

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

Cette action fait apparaître une session interactive qui accepte des commandes telles que :

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

Pour voir une exception non gérée qui a tué votre application :

> 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

Analyser les fuites de mémoire et les allocations

Les fuites de mémoire se produisent lorsque votre application contient des références à des objets qui ne sont plus nécessaires, ce qui empêche le garbage collector de récupérer de la mémoire. Permet d’identifier les fuites de mémoire, de rechercher les objets les plus volumineux et de comprendre où la mémoire est consommée.

Pour obtenir une procédure pas à pas complète du débogage d’une fuite de mémoire, consultez Debug une fuite de mémoire dans .NET.

Identifier les objets les plus volumineux

Utilisez la commande avec l’option pour afficher un résumé des objets sur le tas, triés par taille totale :

> 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

Cette sortie indique quels types consomment le plus de mémoire. Dans cet exemple, les objets consomment environ 19 Mo et les objets consomment environ 4,8 Mo.

Identifier les objets par espace de noms ou assembly

Pour rechercher les modules ou espaces de noms qui consomment de la mémoire, utilisez l’option avec un nom de type partiel pour filtrer les résultats :

> 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

Cette approche vous aide à identifier les parties de votre base de code qui sont responsables de la consommation de mémoire.

Rechercher le nombre le plus élevé d’instanciations

Pour voir quels types ont la plupart des instances, quelle que soit la taille totale, examinez la colonne Count dans la sortie. Les objets dont le nombre d’instances est élevé peuvent indiquer des problèmes de création ou de mise en cache d’objets inefficaces :

> dumpheap -stat

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

Cet exemple montre 206 770 instances et 200 000 instances.

Analyser les références d’objet avec gcroot

Après avoir identifié de grands objets ou de nombreux objets, utilisez cette fonction pour savoir pourquoi un objet n’est pas récupéré par la mémoire. La commande affiche la chaîne de références des racines GC vers un objet spécifique :

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

Cette sortie indique que l’objet est conservé par un objet, ce qui vous aide à identifier la source de la fuite dans votre code.

Analyser la mémoire par taille d’objet

Utilisez les options et les options pour filtrer les objets par taille :

> dumpheap -min 100000 -stat

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

Cette commande affiche uniquement des objets de plus de 100 000 octets, ce qui vous aide à vous concentrer sur les plus grands consommateurs de mémoire.

Trouver les blocages

Permet de diagnostiquer les situations de blocage où les threads sont bloqués en attente de ressources. Pour obtenir une procédure pas à pas complète de débogage de blocage, consultez Debug a deadlock in .NET.

Répertorier tous les threads

Utilisez la commande pour afficher tous les threads managés :

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

Examiner les piles de threads

Permet de voir les piles d’appels de tous les threads :

> clrstack -all

Recherchez des modèles dans lesquels plusieurs threads sont bloqués ou sur des primitives de synchronisation similaires.

Rechercher les propriétaires de verrous

Utilisez la commande pour voir quels threads contiennent des verrous et quels threads attendent :

> 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

La colonne MonitorHeld affiche le nombre de threads en attente du verrou. La colonne d’informations sur le thread propriétaire indique quel thread possède le verrou.

Scénarios avancés d’analyse de la mémoire

Comparer plusieurs vidages

Pour comprendre la croissance de la mémoire au fil du temps, collectez plusieurs vidages et comparez-les :

  1. Collectez un vidage de référence :
  2. Laissez votre application s’exécuter et consommer plus de mémoire.
  3. Collectez un deuxième vidage :
  4. Analysez les vidages et comparez les résultats.

Recherchez des types qui ont beaucoup plus d’instances ou des tailles totales supérieures dans le deuxième vidage.

Analyser la mémoire pour des types d’objets spécifiques

Pour vider toutes les instances d’un type spécifique :

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

Ensuite, utilisez cette fonction pour examiner des objets individuels :

> 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

Collecter un vidage dans un conteneur Docker

nécessite des fonctionnalités dans le conteneur. Une façon courante de les accorder consiste à démarrer le conteneur avec . Selon votre environnement, vous devrez peut-être également ajuster le profil seccomp du conteneur. Consultez les vidages : FAQ pour diagnostiquer les problèmes de configuration de la sécurité des conteneurs.

Pour installer dotnet-dump dans une image de production sans le KIT de développement logiciel (SDK) .NET, utilisez les liens de téléchargement direct à partir de la section Installer ou utilisez une build Docker multi-stage Docker pour copier les fichiers binaires à partir d’une image sdk. Pour obtenir des instructions complètes sur les diagnostics de conteneur, consultez Collecter les diagnostics dans les conteneurs Linux.

Dépannage des problèmes de collecte d’images mémoire

La collecte d’image mémoire nécessite que le processus puisse appeler . Si vous rencontrez des problèmes lors de la collecte des images mémoire, l’environnement sur lequel vous exécutez peut être configuré pour restreindre ces appels. Consultez nos images mémoire : FAQ pour obtenir des conseils de résolution des problèmes et des solutions potentielles aux problèmes courants.

Voir aussi

  • Collecter des diagnostics dans des conteneurs Linux
  • Blog sur la collecte et l’analyse des images mémoire
  • Outil d’analyse des tas (dotnet-gcdump)
  • Last updated on