Resolução de problemas Utilização elevada de CPU pelo processo "System"

Para diagnosticar os problemas de utilização da CPU, deverá utilizar o Event Tracing for Windows (ETW) para captar os dados de Amostragem de CPU / Perfil.

Para captar os dados, instalar o Windows Performance Toolkit , que faz parte do Windows SDK .

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

Agora corra WPRUI.exe, seleccione First Level, em Resource select CPU use e clique em start.

Agora capture 1 minuto de uso do CPU. Após 1 minuto, clique em Save.

Agora analisa o ficheiro ETL gerado com o analisador de performance do Windows arrastando e largando o gráfico CPU Usage (sampled) para o analysis pane e ordenando as colunas como vê na figura:

Inside WPA, carrega os símbolos de debug e expande o Stack do processo SYSTEM. Neste demo, o uso da CPU vem do driver nVIDIA.

No demo seguinte, 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! Verifier* KeLeaveCriticalRegion, isto significa que tem o Driver Verifier activado. Isto também prejudica muito o desempenho e causa uma elevada utilização do SYSTEM. Desabilitar Driver Verifier e reiniciar.

Nesta demonstração, o driver iai2ce.sys (Intel Serial IO GPIO Controller driver) causa-o:

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

Esta demo mostra que o driver Bitdefender ignis.sys

No exemplo a seguir, a utilização de CPU é casuística do driver de rede broadcom bcmwl664.sys

Quando se vê o ntoskrnl.exe!MiZeroWorkerPages como causa, é mais complicado. Isto significa que a função do kernel que zera a memória antes de poder ser usada novamente causa a alta utilização do CPU:

Não existe uma forma real de detectar qual o processo que a causa, mas sei que o Chrome pode causar se tiver a aceleração do hardware activada no Chrome. Por isso se vir isto e usar o Chrome, desligue a aceleração do hardware no Chrome.

Quando vir aqueles ntoskrnl.exe!RtlpGenericRandomPatternWorker, ntoskrnl.exe!RtlpTestMemoryRandomUp chama

a utilização do CPU vem do Kernel para testar a memória para problemas (memtest). Esta utilização é activada através da tarefa de manutenção em modo inactivo do Windows 8.1/10. Você pode usar o Task Scheduler para desativar a tarefa ociosa.

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

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

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

Procure por uma atualização do driver se você vir isto.

Nesta demonstração, um driver citrix está envolvido:

Entre em contato com a sua TI para saber como resolver problemas Citrix.

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

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

Neste demo, o uso da CPU ntoskrnl.exe!KeAcquireSpinLockRaiseToDpc e ntoskrnl.exe!KeReleaseSpinLock.

assim um driver está usando SpinLocks muito pesado. Desactive alguns dispositivos/controladores até ver um que o causa.

Neste caso, o uso do CPU é causado pelo driver L1C62x64.sys

Este é o driver qualcomm atheros AR8171/8175 PCI-E gigabit Ethernet. Por isso actualize o driver se o vir na pilha.

Aqui, a utilização do CPU vem da digitalização do ficheiro host (netbt.sys!DelayedScanLmHostFile)

Certifique-se de que o seu ficheiro host não é demasiado grande para evitar esta utilização.

Neste caso, a utilização do CPU vem de SRTSP64.SYS da symantec.

Actualize o seu produto symantec usado para a versão mais recente.

Aqui, a utilização do CPU vem do driver AMD GPU (atikmdag.sys)

Se vir isto, vá ao site da AMD e obtenha o driver mais recente para a sua placa AMD.

Aqui, os drivers TMXPFlt.sys e VsapiNt.sys causam a alta utilização de CPU.

Pelo que vejo, esses ficheiros fazem parte da suite Trend Micro AV. Actualize a ferramenta ou remova-a.

Neste exemplo, a utilização de CPU vem da função ntoskrnl.exe!MmGetPageFileInformation

Esta função obtém informação sobre o pagefile.

Descrição de Rotina: Esta rotina devolve informação sobre os ficheiros de paging actualmente activos.

Desactivar o pagefile, reiniciar e activá-lo novamente e ver se isto o corrige. Além disso, remover os serviços Intel (por exemplo, Intel Content Protection HECI Service) parece corrigi-lo para um utilizador .

Aqui, pode ver que o driver Netwtw04.sys (driver Intel Wifi) chama a função flushCompleteAllPendingFlushRequests e isto causa uma alta utilização do CPU.

Porque os símbolos de debug são carregados o driver da caixa de entrada do Windows é utilizado. Apenas aqui podemos obter símbolos de debug para ver o stack de chamadas com o nome da função flushCompleteAllPendingFlushRequests.

Aqui, você deve instalar o último driver da Intel para corrigi-lo.

O caso mais complicado de utilização do SYSTEM é a utilização do ACPI.sys no stack de chamadas:

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

isto é extremamente difícil de depurar. Num tópico sysinternals , listei alguns conselhos:

• certifique-se que a CPU não sobreaqueça por causa da poeira na ventoinha da CPU
• actualize ou volte a colocar a (mesma) BIOS/UEFI
• carregue as configurações padrão da BIOS/UEFI
• certifique-se que a bateria não está danificada, remova a bateria do notebook ou desactive a bateria no gestor do dispositivo.
• trocar o jumper no HDD caddy se tiver substituído o DVD/Blue-Ray Drive por um Caddy para instalar um SSD junto ao seu antigo HDD

• desactivar alguns dispositivos como aconselhado por este utilizador
• se utilizar um chipset Intel, tente instalar Intel Rapid Storage Technology (RST) para substituir o driver AHCI padrão do Windows. Isto também parece ajudar .
• o utilizador Shayna descobriu , que utilizando Process Hacker (iniciado como administrador) para suspender os threads dos problemas do ACPI.sys “corrige” o problema para ele. Então tente o seu trabalho se todos os outros passos não resolverem o problema para si.

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

A solução é update to driver com versão de pelo menos . 4590.

No caso seguinte, a utilização do CPU do processo SYSTEM é causada pelo driver stdriverx64.sys

Se vir um driver chamado risdxc64.sys no “calltack” do SYSTEM que causa a alta utilização do CPU, actualize o driver Ricoh PCIe SDXC/MMC Host Controller ou desactive o leitor de cartões SD no gestor de dispositivos se nenhuma actualização do driver o corrigir.

Este leitor de cartões SD parece estar incorporado em muitos dispositivos Lenovo.

O utilizador @stevemidgley mostrou um novo problema de maior utilização de CPU com Wdf01000.sys!FxSystemWorkItem::_WorkItemThunk

Aqui pode ver um driver UDE.sys a causá-lo.

No símbolo do hub

posso ver que pertence ao driver do Modem e os dados PNP dos trace shows Fibocom L850-GL (LTE Modem) como dispositivo possível:

E a solução é desactivar o modem e o dispositivo composto USB no gestor de dispositivos.

Isto pode ser causado por um condutor defeituoso ou outro módulo carregado pelo sistema. Para ver dentro do processo System, pode usar uma ferramenta como Process Explorer .

Faça o download e execute-o, depois seleccione o processo System, clique com o botão direito do rato e seleccione Properties:

Alternar para o separador Threads (ignore a caixa de diálogo que menciona os símbolos):

Isto irá mostrar qual o ficheiro que está a usar o uso excessivo de CPU, a partir do qual pode então tentar diagnosticá-lo.

Como outros já referiram nos comentários, no entanto, precisa mesmo de se afastar das versões Preview o mais depressa possível!

Uma nota sobre o carregamento de símbolos de depuração para adicionar à excelente resposta do magicandre1981 : se carregar os símbolos no Windows Performance Analyzer funcionar correctamente, depois de marcar Trace > Load Symbols deverá ver uma barra de progresso no topo com Loading symbols que mostra os nomes dos ficheiros ao lado e demora vários minutos a completar. Também deverá ver muitas linhas como as que se seguem na Consola 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 não vir nenhuma destas linhas, carregar símbolos de depuração provavelmente não funcionou e não será capaz de interpretar correctamente o seu traço.

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

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

2. Copie os ficheiros dbghelp.dll e symsrv.dll do directório correcto do depurador para o directório do Toolkit de Desempenho do Windows. No meu sistema, os directórios relevantes são:

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

Tive o mesmo problema, desapareceu quando removi um dos módulos da RAM. Parece que era defeituoso. Executando o Windows 7, 32 bits.

Em primeiro lugar, a revisão e as informações fornecidas são muito informativas, no entanto, normalmente consegue-se perceber isto com muito menos inteligência! Eu simplesmente usei MSCOFIG.EXE e uma pesquisa binária para isolar o serviço ofensivo. Descobri que a maioria dos problemas como este são causados pelo software Intel. Começo por desactivar qualquer serviço que não tenha um nome de empresa. Depois, começo pelos serviços da Intel. Depois, a pesquisa binária completa. Normalmente demora uma hora, no máximo, para resolver o problema no PC de alguém. A Intel nunca foi uma boa empresa informática, e o seu software demonstra-o. Sejamos realistas: a arquitectura Pentium já tinha uma década quando foi lançada. Quem teria construído uma arquitectura de computador com memória paginada nos dias do VAX? Bem, não te vou aborrecer com a história. Também não que eu seja fã da AMD ou da Microsoft. Talvez um dia voltemos a construir computadores a sério.