Я отлаживаю проблему зависания в одном из наших приложений с помощью анализа дампа в DebugDiag. Длительно работающее (1-2 часа) консольное приложение. Net, непостоянно, перейдет в состояние, при котором оно, кажется, ничего не делает, но не завершает работу (т.е. зависает). На виртуальной машине, на которой она работает, много ресурсов, и она никогда не потребляет более 1/4 доступной памяти. Анализ подробно описывает то, что потоки ждут как таковые:
The following threads in "SomeApp.exe_Manual Dump.dmp" are waiting for .net garbage collection to finish. Thread 20 triggered the garbage collection.
( 11 13 16 17 18 19 22 24 25 26 27 )
30.56% of threads blocked (11 threads)
и вторая группа потоков, например:
The following threads in "SomeApp.exe_Manual Dump.dmp" are waiting in System.Threading.Monitor.Wait
( 0 14 28 29 30 31 )
16.67% of threads blocked (6 threads)
Мой вопрос для этого сообщения: указывает ли это, что сборщик мусора (G C) заблокирован или может быть другая проблема? Важно отметить, что процесс, кажется, зависает на неопределенный срок, иногда на несколько часов, прежде чем мы его заметим и завершим / перезапустим. Если G C заблокирован, как мне определить с помощью dmp, почему и на каком объекте? Я проверил код, и ни один из объектов, которые, как я знаю, мог быть источником, нет. Может быть также полезно, в разделе «. NET Threads Summary» DebugDiag есть только 1 поток, который имеет ненулевое (1) «Lock Count».
Любые мысли или советы по этому поводу очень признателен.
Заранее спасибо!