Solucionar problemas de alto uso da CPU pelo processo "System"

Isso pode ser causado por um driver defeituoso ou outro módulo carregado pelo sistema. Para examinar o processo do sistema, você pode usar uma ferramenta como Process Explorer .

Faça o download e execute-o, selecione o processo Sistema, clique com o botão direito do mouse e selecione Propriedades:

Alterne para a guia Threads (ignore a caixa de diálogo que menciona símbolos):

Isso mostrará qual arquivo está usando o uso excessivo da CPU, a partir do qual você pode tentar diagnosticá-lo.

Como outros já disseram nos comentários, você realmente precisa se afastar das versões de Preview o mais rápido possível!

Para diagnosticar os problemas de uso da CPU, você deve usar o Rastreamento de eventos para Windows (ETW) para capturar dados/perfil de amostragem de CPU.

Para capturar os dados, instale o Windows Performance Toolkit , que é parte do Windows SDK .

O Windows 10 WPT pode ser usado no Windows 8/Server 2012, Windows 8.1/Server 2012R2 e Windows 10/Server 2016. Se você ainda usa o Windows 7, use o SDK/WPT com Build 15086 .

^{(todas as outras entradas podem ser desmarcadas)}

Agora execute WPRUI.exe, selecione First Level, sob Resource select uso da CPU e clique em start .

Agora capture 1 minuto do uso da CPU. Após 1 minuto, clique em Salvar .

Agora analisa o arquivo ETL gerado com o Windows Performance Analyzer arrastando e soltando o gráfico CPU Usage (sampled) no analysis pane e ordenando as colunas como você vê na figura:

Dentro do WPA, carrega os símbolos de depuração e expande Stack do processo SYSTEM. Nesta demonstração, o uso da CPU vem do driver nVIDIA.

Na demonstração a seguir, o uso da CPU vem do driver Realtek NIC:

Quando você vê chamadas como ntoskrnl.exe! Vi KeTrimWorkerThreadRoutine, ntoskrnl.exe! Mm Verifier TrimMemory, ntoskrnl.exe! Verificador KeLeaveCriticalRegion , isso significa que você tem o Driver Verifier ativado . Isso também prejudica muito o desempenho e causa alto uso do sistema. Disable Driver Verifier e reinicialize.

Neste demo, o driver iai2ce.sys (driver Intel Serial IO GPIO Controller) faz com que:

Neste exemplo, o uso da CPU vem do arquivo rtsuvc.sys, que parece ser o Realtek UVC webcam Driver

Esta demonstração mostra que o driver do Bitdefender ignis.sys

No exemplo a seguir, o uso da CPU é seguido pelo driver de rede broadcom bcmwl664.sys

Quando você vê ntoskrnl.exe!MiZeroWorkerPages como causa, é mais complicado. Isso significa que a função do kernel que zera a memória antes de poder ser usada novamente causa o alto uso da CPU:

Não há uma maneira real de detectar qual processo causa isso, mas sei que o Chrome pode causar isso se você tiver a aceleração de hardware ativada no Chrome. Então, se você vir isso e usar o Chrome, desative a aceleração de hardware no Chrome.

Quando você vir essas chamadas ntoskrnl.exe! RtlpGenericRandomPatternWorker, ntoskrnl.exe! RtlpTestMemoryRandomUp

o uso da CPU vem do kernel para testar a memória para problemas (memtest). Esse uso é acionado por meio da tarefa de manutenção inativa do Windows 8.1/10. Você pode usar o Agendador de Tarefas para desabilitar a tarefa ociosa.

No Windows 10, a tarefa é chamada RunFullMemoryDiagnostics em Microsoft> Windows> MemoryDiagnostic> RunFullMemoryDiagnostic .

Nesse caso, o uso da CPU parece vir do recurso Data Deduplication (dedup.sys!DdpPostCreate) do Windows Server:

Nesta demonstração, o uso da CPU é causado pelo driver da placa WIFI athrx.sys

Procurar por uma atualização de driver, se você ver isso.

Na demonstração a seguir, um driver citrix está envolvido:

Portanto, entre em contato com sua TI para saber como resolver os problemas da Citrix.

Nesta demonstração, a função usbhub.sys!UsbhPortRecycle causa o uso da CPU:

Alterando as portas USB 2.0 para velocidade 1.1 ou conectando unidades USB a outras portas USB 2.0 ajudou alguns usuários.

Neste caso, uma pequena quantidade de uso do sistema vem do driver da Acronis tdrpm251.sys:

Nesta demonstração, o uso da CPU ntoskrnl.exe!KeAcquireSpinLockRaiseToDpc e ntoskrnl.exe!KeReleaseSpinLock.

então um driver está usando SpinLocks muito fortemente. Desative alguns dispositivos/drivers até ver um deles.

Nesse caso, o uso da CPU é causado pelo driver L1C62x64.sys

Este é o driver qualcomm atheros AR8171/8175 PCI-E gigabit Ethernet. Então, atualize o driver se você vê-lo na pilha.

Aqui, o uso da CPU vem da verificação do arquivo host (netbt.sys! DelayedScanLmHostFile)

verifique se o arquivo de hosts não é muito grande para evitar esse uso.

Nesse caso, o uso da CPU vem de SRTSP64.SYS da Symantec.

Atualize seu produto da Symantec usado para a versão mais recente.

Aqui, o uso da CPU vem do driver AMD GPU (atikmdag.sys)

se você ver isso, acesse o site da AMD e obtenha o driver mais recente para sua placa AMD.

Aqui, os drivers TMXPFlt.sys e VsapiNt.sys causam o alto uso da CPU.

Pelo que vejo, esses arquivos fazem parte do pacote Trend Micro AV. Atualize a ferramenta ou remova-a.

Neste exemplo, o uso da CPU vem da função ntoskrnl.exe!MmGetPageFileInformation

Esta função obtém informações sobre o arquivo de paginação.

Rotina Descrição: Esta rotina retorna informações sobre os arquivos de paginação ativos no momento.

Desative o arquivo de paginação, reinicialize e ative novamente e veja se isso o corrige. Além disso, a remoção de serviços da Intel (por exemplo, o serviço Intel Content Protection HECI) parece ter corrigido para um usuário .

Aqui, você pode ver que o driver Netwtw04.sys (Intel Wifi driver) chama a função flushCompleteAllPendingFlushRequests e isso causa um alto uso da CPU.

Como os símbolos de depuração são carregados, o driver da caixa de entrada do Windows é usado. Só aqui podemos obter símbolos de depuração para ver o callstack com o nome da função flushCompleteAllPendingFlushRequests.

Aqui, você deve instalar o driver mais recente da Intel para consertá-lo.

O caso mais complicado de uso do sistema é o uso de ACPI.sys no callstack:

Line #, DPC/ISR, Module, Stack, Count, Process, Weight (in view) (ms), TimeStamp (s), % Weight
6, , ,   |    |- ACPI.sys!ACPIWorkerThread, 40246, , 39.992,941063, , 4,13
7, , ,   |    |    ACPI.sys!RestartCtxtPassive, 40246, , 39.992,941063, , 4,13
8, , ,   |    |    ACPI.sys!InsertReadyQueue, 40246, , 39.992,941063, , 4,13
9, , ,   |    |    ACPI.sys!RunContext, 40246, , 39.992,941063, , 4,13
10, , ,   |    |    ntoskrnl.exe!KeReleaseSpinLock, 40246, , 39.992,941063, , 4,13
11, , ,   |    |    ntoskrnl.exe!KiDpcInterrupt, 40246, , 39.992,941063, , 4,13
12, , ,   |    |    ntoskrnl.exe!KiDispatchInterruptContinue, 40246, , 39.992,941063, , 4,13
13, , ,   |    |    ntoskrnl.exe!KxRetireDpcList, 40246, , 39.992,941063, , 4,13
14, , ,   |    |    ntoskrnl.exe!KiRetireDpcList, 40246, , 39.992,941063, , 4,13
15, , ,   |    |    |- ntoskrnl.exe!KiExecuteAllDpcs, 40198, , 39.945,173325, , 4,13
16, , ,   |    |    |    |- ACPI.sys!ACPIInterruptDispatchEventDpc, 27565, , 27.408,930428, , 2,83
17, , ,   |    |    |    |    |- ACPI.sys!ACPIGpeEnableDisableEvents, 24525, , 24.384,921620, , 2,52
18, , ,   |    |    |    |    |    ACPI.sys!ACPIWriteGpeEnableRegister, 24525, , 24.384,921620, , 2,52
19, , ,   |    |    |    |    |    |- hal.dll!HalpAcpiPmRegisterWrite, 24421, , 24.281,015516, , 2,51
20, , ,   |    |    |    |    |    |    |- hal.dll!HalpAcpiPmRegisterWritePort, 24166, , 24.027,316013, , 2,48

isso é extremamente difícil de depurar. Em um sysinternals topic , listei alguns conselhos:

• certifique-se de que a CPU não superaquece por causa da poeira no ventilador da CPU
• atualizar ou re-flash o (mesmo) BIOS/UEFI
• carregar configurações padrão do BIOS/UEFI
• verifique se a bateria não está danificada, remova a bateria do notebook ou desative a bateria no gerenciador de dispositivos.
• change jumperno HDD caddy se você substituiu o DVD/Blue-Ray Drive por um Caddy para instalar um SSD próximo ao seu HDD antigo

• desabilitar alguns dispositivos como recomendado por este usuário
• se você usar um chipset Intel, tente instalar Intel® Rapid storage Technology (RST) para substituir o driver padrão AHCI do Windows. Isso também parece ter ajudado .
• o usuário Shaynadescobri , que usando Process Hacker (iniciado como admin) suspender os threads dos problemas ACPI.sys "corrige" o problema para ele. Portanto, tente sua solução alternativa se todas as outras etapas não resolverem isso para você.

Na demonstração a seguir, o driver Intel HD igdkmd64.sys na versão .4574 para o Intel HD 630 causa o problema:

A solução é atualizar para o driver com versão de pelo menos .4590.

No caso a seguir, o uso da CPU do processo do sistema é causado pelo driver stdriverx64.sys

Este parece ser um driver de streaming de áudio . Então atualize este software/driver se você ver isso no WPA.

Se você vir um driver chamado risdxc64.sys na pilha de chamadas do SYSTEM que causa o alto uso da CPU, atualize o driver Ricoh PCIe SDXC/MMC Host Controller ou desative o SD leitor de cartão no gerenciador de dispositivos se nenhuma atualização de driver o corrigir.

Este leitor de cartão SD parece estar embutido em muitos dispositivos Lenovo.

Uma observação sobre o carregamento de símbolos de depuração para adicionar a a excelente resposta de magicandre1981 : se o carregamento dos símbolos no Windows Performance Analyzer funcionar corretamente, após marcar Trace> Load Symbols você deve ver uma barra de progresso na parte superior com Carregando símbolos que mostra nomes de arquivos ao lado e leva vários minutos para ser concluído. Além disso, você deve ver várias linhas, como a abaixo, no Console de Diagnóstico:

SYMSRV:  File: Accessibility.ni.pdb

SYMSRV:  Notifies the client application that a proxy has been detected.
SYMSRV:  Connecting to the Server: http://msdl.Microsoft.com/download/symbols.
SYMSRV:  Successfully connected to the Server.
SYMSRV:  Sending the information request to the server.
SYMSRV:  Successfully sent the information request to the server.
SYMSRV:  Waiting for the server to respond to a request.
SYMSRV:  Successfully received a response from the server.
SYMSRV:  Closing the connection to the Server.
SYMSRV:  Successfully closed the connection to the Server.
SYMSRV:  Get File Path: /download/symbols/Accessibility.ni.pdb/7B46178957827CDAB7EE4C86EDEE1DAE1/Accessibility.ni.pdb

Se você não vir nenhum desses, carregar símbolos de depuração provavelmente não funcionou e você não conseguirá interpretar corretamente seu rastreio.

No meu caso, carregar inicialmente os símbolos de depuração não funcionou. Eu consertei seguindo estas instruções :

1. Descobrir se você está usando a versão x86 ou x64 do Windows Performance Toolkit.

   Isso é fácil em compilações x86 do Windows. Em x64 compilações, você pode verificar o Gerenciador de tarefas para a marca * 32. Se não estiver lá, você está executando a versão x64.

   Observe que o WPT sempre é instalado em Arquivos de Programas (x86), independentemente da arquitetura.

2. Copie os arquivos dbghelp.dll e symsrv.dll do diretório correto do depurador para o diretório do Windows Performance Toolkit. No meu sistema, os diretórios relevantes são:

   C:\Program Files (x86)\Windows Kits\10\Debuggers\x64 e C:\Program Files (x86)\Windows Kits\10\Windows Performance Toolkit

3. Reinicie o Windows Performance Analyzer para que a versão correta do dbghelp.dll seja selecionada.

Em primeiro lugar, a revisão e a informação fornecida são muito informativas, no entanto, normalmente você pode descobrir isso com muito menos inteligência! Eu simplesmente usei MSCOFIG.EXE e uma pesquisa binária para isolar o serviço ofensivo. Eu encontrei a maioria dos problemas como este são causados ​​pelo software Intel. Eu começo desabilitando qualquer serviço que não tenha um nome de empresa. Então eu começo nos serviços da Intel. Então a busca binária completa. Geralmente leva uma hora no máximo para corrigir o problema no PC de alguém. A Intel nunca foi uma boa empresa de computadores e seu software demonstra isso. Vamos admitir que a arquitetura Pentium tinha uma década quando foi lançada. Quem teria construído uma arquitetura de computador com memória paginada nos dias de VAX? Bem, eu não vou te entediar com a história. Não que eu seja fã da AMD ou da Microsoft também. Talvez um dia nós voltemos a construir computadores reais novamente.