我是WinDbg的新手，本周开始使用它来诊断ASP.NET 4应用程序中的内存泄漏。我采用了一个活动的IIS进程的内存转储，并试图确定哪些项目仍然可以在内存中，哪些不是。例如，我在内存中看到几个System.Web.UI对象，以及一个ASPX页面。我得到所有对象及其地址的列表，然后运行以下命令...
!gcroot [addr]
......但每次都会得到类似的结果......
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
这是否表示某个对象仍在内存中但等待GC？与我有关的大多数对象（在页面呈现并发送到客户端之后应该处理的UI元素）似乎没有我能找到的根。
有任何建议或澄清吗？
答案 0 :(得分：2)
是。如果!gcroot命令没有返回对象的根，则它只是在内存中等待收集。我相信仍然有一个WeakReference仍然可以抓住这个对象，所以它有可能在未来的某个时刻重新扎根。但是在!gcroot命令时，它可以收集。