En général, si vous avez une fuite dans une application gérée, cela signifie que quelque chose n'est pas collecté. Les sources communes incluent
Les gestionnaires d'événements: Si l'abonné n'est pas supprimé l'editeur s'engage à le tenir.
La statique
Les finaliseurs: le blocage d'Un finaliseur permettra d'éviter le finaliseur fil de courir tous les autres outils de finalisation et ainsi éviter que ces instances soient recueillies.
De même, l'impasse thread va tenir à ce que les racines qu'il détient. Bien sûr, si vous avez l'impasse des threads qui affecteront probablement l'application sur plusieurs niveaux.
Pour résoudre ce problème, vous devez vérifier le tas managé. WinDbg + SOS (ou PSSCOR) qui vous permettra de le faire. L' !dumpheap -stat commande répertorie l'ensemble de tas managé.
Vous devez avoir une idée du nombre d'instances de chaque type d'attendre sur le tas. Une fois que vous trouvez quelque chose qui semble étrange, vous pouvez utiliser l' !dumpheap -mt <METHOD TABLE> de la commande à la liste de toutes les instances d'un type donné.
L'étape suivante consiste à analyser les racines de ces instances. Choisissez-en un au hasard et de faire un !gcroot sur qui. Pour montrer comment cette instance est enracinée. Regardez pour les gestionnaires d'événements et épinglé les objets (généralement de représenter les références statiques). Si vous voyez le finaliseur file d'attente de là, vous avez besoin d'examiner ce que le finaliseur thread est en train de faire. Utiliser l' !threads et !clrstack des commandes pour cet.
Si tout semble parfait pour cette instance de passer à une autre instance. Si cela ne donne rien, vous devrez peut-être revenir pour regarder le tas de nouveau et répétez la procédure à partir de là.
D'autres sources de fuites comprennent: les ensembles qui ne sont pas déchargées et de la fragmentation du Tas d'Objets Volumineux. SOS/PSSCOR peut vous aider à localiser ces derniers aussi bien, mais je vais passer les détails pour l'instant.
Si vous voulez en savoir plus je vous recommande de Tess blog. J'ai aussi fait quelques vidéos couvrant comment utiliser WinDbg + SOS (ici et ici).
Si vous avez l'option de débogage du processus alors qu'elle s'exécute, je recommande d'utiliser PSSCOR au lieu de SOS. PSSCOR est essentiellement une branche privé de la SOS sources qui a été amélioré avec des commandes supplémentaires et un grand nombre de commandes SOS ont été améliorés. E. g. le PSSCOR version de l' !dumpheap commande est très utile delta de la colonne, ce qui rend le dépannage des fuites de mémoire beaucoup plus facile.
Pour l'utiliser vous avez besoin pour commencer votre processus, joindre WinDbg et de la charge PSSCOR et faire un !dumpheap -stat. Ensuite, vous laissez le processus d'exécution de nouveau si les allocations sont effectuées. Pause l'exécution et répétez la commande. Maintenant PSSCOR va vous montrer le nombre d'instances qui ont été ajoutés ou supprimés depuis l'inspection précédente.
