Сервер не отвечает и conhost.exe высокая загрузка процессора (даже в безопасном режиме)
Возникла небольшая проблема с сервером. С этого утра один из наших серверов начал перестать отвечать на запросы. Мне не удалось подключиться к удаленному рабочему столу (тайм-аут при "ожидании службы профиля пользователя"), поэтому пришлось использовать vnc (он находится в облаке, а vnc подключается напрямую) и обнаружил, что conhost.exe использует много процессорных процессоров. После закрытия всех консольных программ и всего несущественного этот процесс все еще работал и использовал весь процессор.
Я перезапустил компьютер в безопасном режиме и обнаружил, что происходят те же симптомы - сервер не отвечает, а conhost.exe использует 50% ЦП. Ниже приведен скриншот текущих запущенных процессов - как видите, ничего необычного не запущено. Единственная вещь, которая произошла с сервером, была установка SP1 (что мы сделали только сейчас, чтобы попытаться исправить это) и перемещение сайта на него (с тех пор как он был перенесен назад, поскольку этот явно имеет проблемы!). Вы не можете выключить машину или убить какие-либо процессы, поскольку она просто зависает. Я даже не мог запустить msconfig, чтобы отключить что-либо!
Оказывается, я не могу публиковать изображения, так что вот ссылка на скриншот
http://i56.tinypic.com/53tkwn.png
Кто-нибудь испытывал что-то подобное раньше, и если да, что вы делали, чтобы это исправить? Этот сервер должен быть запущен и работает, так как на нем размещена наша компания crm, и у меня закончились идеи!
Сервер работает под управлением Windows 2008r2 x64, IIS7.5 все обновлено
Любая помощь с благодарностью!
Ура,
Том.
4 ответа
Проблема повторилась сегодня. После значительных отключений и перезапусков я сузил проблему до резервного копирования сервера диска. Не уверен, что он делает (он не должен быть запущен в то время), но отключение службы, по-видимому, остановило использование процессора в conhost.exe
У нас возникла похожая проблема, за исключением того, что мы заметили, что оба Conhost.exe и CMD.exe работали и потребляли около 85-100% ЦП между двумя процессами. Это было на одном из наших серверов Windows, работающих под управлением Windows Server 2008 R2 Datacenter.
Там не было ничего очевидного, что мы могли видеть. Мы проверили сеансы и открыли файлы, но все равно ничего не смогли найти. Мы не видели запущенных приложений, и после проверки журналов ошибок и монитора ресурсов на наличие подозреваемых мы рисовали пустую строку.
Где-то что-то было запущено CMD.EXE, и это было связано с CONHOST.EXE. Поэтому, переосмыслив основы, мы просто спросили себя: "Что может запустить CMD.exe и сделать это в фоновом режиме, чтобы никто не знал, что он запущен, или запустить его, чтобы он мог работать без присмотра?" Ответ (в нашем случае): Task Sheduler
Наша проблема заключалась в том, что запланированное задание было настроено для запуска с полномочиями учетной записи высокого уровня, которые будут выполняться независимо от того, вошел ли пользователь в систему или нет. Планировщик задач фактически запустил старый добрый файл.BAT на основе Dos, который остановился, ожидая обработки файла, который был перемещен из пути к местоположению, который был определен в файле.BAT. Задача не была настроена на автоматическое завершение, поэтому она просто пыталась запустить, ждала и ждала..... Исполняемые файлы Conhost и CMD действительно что-то делали и пытались сделать это с большим успехом. После того, как задача была завершена, загрузка ЦП вернулась к нормальной в течение нескольких секунд. Файл, который искал.BAT-файл Task Sheduler, был найден и перемещен обратно туда, где он находился, и Задача была изменена для автоматического завершения через несколько часов, если она не завершилась.
Тот conhost.exe системный процесс, используемый для управления консольными окнами, поэтому его запуск означает, что что-то работает в командной строке; обычно также есть cmd.exe вокруг. Тот makecab.exe вероятно, виновник, поскольку это утилита командной строки для (угадайте, что) создания файлов.CAB; тот факт, что он работает, и даже более того, он работает в контексте SYSTEM, выглядит для меня совершенно неверным.
Мое первое предположение было бы, что Ваш сервер поймал некоторый вирус / вредоносную программу.
Я знаю, что это старый вопрос, но сегодня я наткнулся на аналогичную проблему на рабочем столе Windows 10 Enterprise 21H2 (19044.2251) (фактически на ноутбуке). Небольшое расследование показало, что проблема заключалась в том, что видимо зависший файл, порожденный VS Code (1.74.3), находился в памяти после закрытия самого VS Code.
У меня нет хорошего решения, кроме написания сценария, который будет отслеживатьconhost.exeбез родительского процесса и через некоторое время убейте их :-/
