Tendo um pouco de problema no servidor. A partir desta manhã, um de nossos servidores começou a não responder. Eu era incapaz de desktop remoto (que expira quando "esperando pelo serviço de perfil de usuário") para verificar, então tive que usar vnc (é em uma nuvem e vnc conecta direto) e encontrou conhost.exe estava usando um monte de cpu. Depois de fechar todos os programas de console e tudo o que não é essencial, este processo ainda estava rodando e usando todo o cpu.
Eu reiniciei a máquina no modo de segurança e descobri que os mesmos sintomas estão acontecendo - o servidor não está respondendo e o conhost.exe está usando 50% de CPU. Abaixo está uma imagem dos processos atuais em execução - como você pode ver, nada fora do comum está em execução. As únicas coisas que aconteceram com o servidor foram a instalação do SP1 (que fizemos agora para tentar consertá-lo) e a movimentação de um site para ele (desde que ele foi movido de volta, pois esse problema tem claramente problemas!). Você não pode desligar a máquina ou matar todos os processos, uma vez que apenas trava. Eu não consegui nem executar o msconfig para desabilitar nada!
Acontece que não posso postar imagens, então aqui está um link para a captura de tela
Alguém experimentou algo assim antes e, em caso afirmativo, o que você fez para corrigir isso? Este servidor precisa estar ativo e funcionando, já que hospeda o CRM da nossa empresa e eu fiquei sem ideias!
O servidor está executando o Windows 2008r2 x64, o IIS7.5 está tudo atualizado
Qualquer ajuda é muito apreciada!
Felicidades,
Tom.
O problema aconteceu novamente hoje. Depois de muito desativar e reiniciar, eu reduzi o problema para o backup do servidor de disco da selva. Não tenho certeza do que está fazendo (ele não deve estar sendo executado naquele momento), mas desabilitar o serviço pareceu parar o uso de alta CPU em conhost.exe
Esse conhost.exe é um processo do sistema usado para gerenciar janelas do console, portanto, executá-lo significa que algo está funcionando em um prompt de comando; geralmente há também cmd.exe ao redor. Esse makecab.exe é provavelmente o culpado, pois é um utilitário de linha de comando para (adivinhe) criar arquivos .CAB; o fato de que ele está rodando, e ainda mais o fato de que ele está rodando no contexto SYSTEM parece bastante errado para mim.
Meu primeiro palpite é que seu servidor detectou algum vírus / malware.
Tivemos um problema semelhante, exceto que percebemos que tanto o Conhost.exe quanto o CMD.exe estavam sendo executados e estavam consumindo cerca de 85-100% da CPU entre os dois processos. Isso foi em um de nossos servidores Windows executando o Windows Server 2008 R2 Datacenter.
Não havia nada de óbvio acontecendo que pudéssemos ver. Nós verificamos Sessões e arquivos abertos, mas ainda não conseguimos encontrar nada. Não pudemos ver nenhum aplicativo sendo executado e, depois de verificar os logs de erros e o monitor de recursos para suspeitos, estávamos desenhando um espaço em branco.
Em algum lugar, algo estava executando o CMD.EXE e estava emparelhado com o CONHOST.EXE. Então, depois de repensar o básico, nós simplesmente nos perguntamos: "O que pode executar o CMD.exe e fazê-lo em segundo plano para que ninguém saiba que ele está sendo executado ou executado para que ele possa ser executado sem supervisão?" Resposta (no nosso caso): Task Sheduler
Nosso problema era que uma tarefa agendada tinha sido configurada para ser executada com uma autoridade de conta de alto nível que executaria se o usuário estava logado ou não. O Agendador de Tarefas tinha, na verdade, executado um bom arquivo BAT baseado em DOS, que ficava parado enquanto aguardava para processar um arquivo que havia sido movido do caminho de localização que havia sido definido no arquivo .BAT. A tarefa não foi configurada para terminar automaticamente, então ela simplesmente tentou rodar, esperou e esperou ..... os executáveis do Conhost e do CMD estavam realmente fazendo algo e tentando fazer isso de uma maneira grande. Depois que a tarefa foi finalizada, o uso da CPU voltou ao normal em alguns segundos. O arquivo que o arquivo .BAT do Task Sheduler procurava estava localizado e voltou para onde pertencia, e a Tarefa foi modificada para finalizar automaticamente após algumas horas, se não fosse concluída.
