Ваша проблема, вероятно, связана либо с классической утечкой (объекты, которые по-прежнему укоренены, когда их не должно быть), либо с фрагментацией большой кучи объектов (LOH).
Лучший инструмент, который я нашел для диагностики этого класса проблем, - это расширение Son of Strike (SOS) для отладчика Windows. Загрузите Microsoft Средства отладки для Windows , чтобы получить отладчики: CDB - консольный отладчик (который я предпочитаю, так как он кажется более отзывчивым), WinDbg - это то же самое, что и приложение MDI. Эти инструменты довольно низкоуровневые и имеют небольшую кривую обучения, но предоставляют все, что вам нужно знать, чтобы найти свою проблему.
В частности, запустите !DumpHeap -stat, чтобы увидеть, какие типы объектов поглощают вашу память. Эта команда также сообщит внизу списка, если заметит какую-либо существенную фрагментацию. !EEHeap выведет список сегментов кучи - если имеется много сегментов LOH, я бы заподозрил фрагментацию LOH.
0:000> .loadby sos mscorwks
0:000> !EEHeap -gc
Number of GC Heaps: 1
generation 0 starts at 0x00f7a9b0
generation 1 starts at 0x00e79c3c
generation 2 starts at 0x00b21000
ephemeral segment allocation context: none
segment begin allocated size
00b20000 00b21000 010029bc 0x004e19bc(5118396)
Large object heap starts at 0x01b21000
segment begin allocated size
01b20000 01b21000 01b8ade0 0x00069de0(433632)
Если имеется много сегментов LOH, я бы начал подозревать фрагментацию LOH.
Однако перед этим мне было бы интересно узнать:
- Использует ли приложение string.Intern ()?
- Есть ли в приложении временные объекты, которые подписываются на события с долгоживущими объектами?
(Причина, по которой я спрашиваю об этом, заключается в том, что 1. таблицы строк строки .NET реализованы таким образом, что они могут вызвать фрагментацию LOH, и 2. подписка на события обеспечивает дополнительный корень для объекта подписки, который легко забыть .)