services.exe intermitentemente usando 10-20 GB de memória quando o Visual Studio 2013 está em execução

2

Quando executo o Visual Studio 2013 em uma de minhas máquinas, noto que o services.exe consome intermitentemente de 10 a 20 GB de memória. Isso acontece aleatoriamente e parece não ter relação com nada que eu faça; Eu posso apenas abrir um projeto e deixá-lo em segundo plano, e services.exe acabará por consumir memória excessiva.

Como resultado, todo o meu sistema se torna inutilizável (presumivelmente devido à troca de memória), e eu tenho que matar o Visual Studio. Mesmo depois de matá-lo, pode levar até 5 minutos antes de o uso da memória cair novamente. Em casos extremos, tenho que reinicializar minha máquina porque não consigo abrir o Gerenciador de Tarefas ou o Process Explorer.

Eu tenho três máquinas e apenas uma máquina enfrenta esse problema. A máquina em questão é um Mac Pro com 24 processadores e 16 GB de RAM, executando o Windows 7 Ultimate N. Estou usando o Bootcamp para executar o Windows. A máquina é razoavelmente limpa, tendo somente o Visual Studio e o Git para Windows instalados, em cima do Bootcamp. Outro desenvolvedor também usa o Bootcamp com especificações mais altas, e eles não encontram esse problema, então não parece ser um problema geral do Bootcamp.

Qual poderia ser o problema? Existe alguma maneira de diagnosticar isso?

    
por dauphic 14.01.2014 / 21:05

1 resposta

0

À primeira vista, pensei que isso poderia ter algo a ver com o Native Image Generation Service (ngen). Isso pode ser chamado diretamente ou ser executado como um serviço. Mas o nome do serviço é realmente mscorsvw.exe (eu acho; a menos que tenha mudado no .NET 4.5 / VS 2013). Além disso, esqueci que o services.exe é, na verdade, o Gerenciador de controle de serviços e não se refere a nenhum serviço em particular, porque nenhum serviço do Windows está realmente hospedado em services.exe.

O problema é que isso será super específico para sua configuração específica. Pode ser hardware; poderia ser um motorista; poderia concebivelmente ser um vírus sendo executado como um processo aparentemente legítimo para tentar se mascarar.

Verifique seu log de eventos do Windows em Ferramentas Administrativas. Está sendo spammed notoriamente? Acredito que gravações de log de eventos envolvem services.exe.

Também possivelmente de interesse é que os drivers de dispositivo hotplug (para periféricos USB e, atualmente, até placas gráficas) são carregados via services.exe. De wikipedia :

Services whose Type registry value is SERVICE_KERNEL_DRIVER or SERVICE_FILE_SYSTEM_DRIVER are handled specially: these represent device drivers for which ScStartService() calls the ScLoadDeviceDriver() function which loads the appropriate driver (usually a file with an extension .sys) which must be located in the %SystemRoot%\System32\Drivers\ directory. For that purpose, the NtLoadDriver system call is invoked, and the SeLoadDriverPrivilege is added to the SCM's process.

Portanto, o SCM, também conhecido como services.exe , tem uma interação frágil e altamente privilegiada com os drivers de dispositivo do sistema. Um driver poderia muito bem estar funcionando mal e periodicamente tentando se recarregar (talvez devido a uma falha), e comendo muita RAM no SCM durante sua rotina de inicialização, o que é feito em processo no services.exe.

Esta resposta é muito especulativa porque não tenho uma resposta precisa com base nas informações que você forneceu. Desculpe.

Coisas para experimentar:

  • Assista ao log de eventos como um falcão. Veja se alguma coisa é escrita na época em que você experimenta o atraso.
  • Veja se isso acontece sem o Visual Studio em execução.
  • Tente atualizar seus drivers. Eu sei que soa bobo, mas na verdade pode ser drivers.
por 14.01.2014 / 21:43