В Windows Vista и более поздних версиях по умолчанию выполняются проверки на реагирование приложений на основе пользовательского интерфейса .
Это может привести к тому, что приложение будет помечено как "Не отвечает", либо когда оно находится на переднем плане (панель задач), либо когда его окно получает фокус (диалог).
Когда приложение не отвечает, и ОС может сделать вывод, что сбой связан с исключением в дочернем модуле, о котором само приложение не знает, Windows знает, что приложение не может отобразить свое собственное сообщение об ошибке, записать в системный журнал событий, и создать отчет о сбое, Windows отображает диалоговое окно, указывающее, что процесс "Перестал работать". Это немного отличается от сбоя приложения, потому что стек основного исполняемого файла сам по себе не падал; однако обычно он ожидает ответа от дочернего модуля, который никогда не придет. Журнал событий часто будет содержать информацию об исключении ребенка.
Приложение считается неотвечающим, когда Windows API не может обнаружить, что окно пользовательского интерфейса вошло в то место, где пользователь может манипулировать им через некоторое время. В C # вы можете запросить состояние окон, чтобы проверить его отзывчивость с помощью вызова Process.Responding() . Этот метод возвращает значение false (или вызывает исключение, если MainWindowHandle не существует) или значение true, если окно находится в состоянии ожидания и ожидает ввода.
Есть случаи, когда неотвечающая программа фактически выполняет большую работу, в точности так, как это должно быть, поэтому не отвечающее сообщение не всегда указывает на сбой (просто плохой код). Окно рабочего стола может со временем стать отзывчивым. Диалоговое окно "Остановленная работа" обычно указывает на постоянный сбой, и приложение необходимо будет прервать. Это не на 100% верно все время, но чаще всего так оно и есть.
Природа этих сообщений и связанных с ними проблем неотделима от методов программирования, используемых при выполнении работы и интеграции с внешними компонентами и сервисами, такими как внешние API. Microsoft выпустила некоторую полезную информацию о том, что делать и чего не делать, чтобы разработать адаптивный дизайн пользовательского интерфейса. Плохие стратегии потоков, синхронный и асинхронный доступ к внешним компонентам и конфликт ресурсов (блокировки / взаимоблокировки) являются общими причинами.
Для конечных пользователей, страдающих от проблем с приложениями, которые "перестали работать" Microsoft рекомендует использовать расширенный путь устранения неполадок, который можно найти здесь: http://support.microsoft.com/kb/2694911 Драйвер видеокарты часто отвечает за проблемы с Draw() цикл, и, таким образом, может вызвать неотзывчивость, как и системные API. Проверка установки драйвера и целостности самой ОС (с помощью SFC.exe) являются полезными шагами для определения того, что приложение тесно интегрируется с вашей системой, как и ожидалось. Аппаратные средства, такие как видеокарта и оперативная память, также должны работать правильно.
Надеюсь, это поможет
