Я новичок в 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
Указывает ли это на объект, который все еще находится в памяти, но ожидает GCed? Кажется, что большинство объектов, которые меня интересуют (те элементы пользовательского интерфейса, которые должны быть удалены после визуализации страницы и отправки клиенту), не имеют корня, который я могу найти.
Есть предложения или разъяснения?