Ответ 1
Общее решение этой проблемы отсутствует.
Невозможно определить, висит ли какой-то конкретный процесс или нет, потому что термин "зависание" полностью зависит от контекста выполняемого процесса.
Процесс подвески всегда будет делать то, что он кодировал. Разработчик, возможно, плохо кодировал его, но Windows не может делать предположения о том, что правильно/неправильно.
Возможные идеи:
-
Process.Responding будет указывать, отвечает ли процесс, выполняющий цикл сообщений Windows.
-
Одним из возможных решений для более общего случая может быть опрос использования памяти для процесса с интервалами, и если он не изменится через некоторое время, предположите, что он висит. Вы можете сделать это с помощью
Process.WorkingSet64
. Тем не менее, я ожидаю, что это вызовет ряд ложных срабатываний - стабильные процессы, которые не обрабатывают ничего, могут оказаться висящими. Это также привело бы к ложным негативам, когда висячий процесс, который имел утечку памяти, как представляется, делал что-то полезное, когда на самом деле он застрял в цикле. -
Если процесс записывает в потоки StandardError/StandardOutput (как это делают многие консольные приложения), вы можете попробовать прослушать такой вывод:
Process.BeginOutputReadLine
иProcess.BeginErrorReadLine
. Если в течение определенного периода нет такого вывода, вы можете определить, что он висел.
Но вы не найдете ничего, что работает в общем случае.