WinDbg - comment savoir si un objet est en mémoire mais attend d'être collecté

Question

Je suis nouveau sur WinDbg et j'ai commencé à l'utiliser cette semaine pour diagnostiquer les fuites de mémoire dans une application ASP.NET 4. J'ai pris un vidage de mémoire d'un processus IIS actif et j'essaie de déterminer quels éléments sont ok pour être encore en mémoire et ceux qui ne le sont pas. Par exemple, je vois plusieurs objets System.Web.UI en mémoire et une seule page ASPX. Je reçois une liste de tous les objets et leurs adresses, puis exécutez la commande suivante ...

!gcroot [addr] 

... mais finissent avec des résultats similaires à chaque fois ...

0:000> !gcroot 1112f704 
Note: Roots found on stacks may be false positives. 
Run "!help gcroot" for more info. 
Scan Thread 11 OSTHread e14 
Scan Thread 29 OSTHread 2590 
Scan Thread 31 OSTHread 65c 
Scan Thread 32 OSTHread 2180 
Scan Thread 33 OSTHread a18 
Scan Thread 10 OSTHread 404 
Scan Thread 35 OSTHread 12ec 
Scan Thread 19 OSTHread a54 
Scan Thread 3 OSTHread 251c 
Scan Thread 37 OSTHread dfc 
Scan Thread 38 OSTHread 1720 
Scan Thread 39 OSTHread 24a8 
Scan Thread 40 OSTHread 26a8 
Scan Thread 41 OSTHread 2784 
Scan Thread 42 OSTHread 1a24 
Scan Thread 44 OSTHread 1fc8 
Scan Thread 45 OSTHread 15f8 
Scan Thread 47 OSTHread 2394 
Scan Thread 48 OSTHread 1638 

Est-ce indicatif d'un objet qui est encore en mémoire mais qui attend d'être GCed? La plupart des objets qui me concernent (les éléments de l'interface utilisateur qui doivent être éliminés après le rendu et l'envoi de la page au client) semblent n'avoir aucune racine que je puisse trouver.

Des suggestions ou des clarifications?

Answer 1

Oui. Si la commande !gcroot ne renvoie aucune racine pour un objet, elle est simplement en attente de collecte. Je crois qu'il est possible qu'il y ait toujours un WeakReference pour toujours garder l'objet mais il y a donc le potentiel qu'il sera re-enraciné à un point futur. Mais au moment de la commande !gcroot, il est elligable pour la collecte.