Como outros já apontaram, podemos ver a partir dessa captura de tela que a CPU que está trabalhando tão duro está gastando todo o seu tempo no modo kernel. (A cor vermelha.)
Executando o Powershell como administrador, digite:
Get-Process | Select Name, PrivilegedProcessorTime | '
Sort-Object PrivilegedProcessorTime -Descending
O processo no topo da lista é o processo atualmente usando a maior parte do tempo de CPU no modo kernel agora. Se esse processo for não "Sistema", você acabou de descobrir qual processo do modo de usuário está causando esse uso da CPU. Se o processo com o Maior Privileged Processor Time for System, o que eu suspeito que seja, então é um pouco mais complicado.
Abra o Process Explorer. Opcionalmente, configure seu servidor de símbolos. Verifique se você está executando com a elevação completa do UAC. Clique com o botão direito do mouse em "processo" do sistema e vá para Propriedades. Em seguida, vá para a guia Threads. Classifique os segmentos por uso da CPU. O encadeamento que está causando todo esse trabalho no modo kernel deve estar aqui. Se você olhar para o módulo listado em Endereço inicial, ele deverá fornecer uma pista sobre a relação do trabalho. Se é NDIS.sys, por exemplo, isso é um driver de interface de rede. Se você configurar o servidor de símbolos, deverá ver o nome de uma função dentro de um módulo (a menos que o módulo seja não-Microsoft), senão você verá apenas um deslocamento numérico do endereço inicial do módulo.
Como alternativa, use o Xperf do Windows Performance Toolkit para criar perfis de interrupções, DPCs, etc.
xperf -on PROC_THREAD+LOADER+DPC+INTERRUPT
e pare de gravar com xperf -d logfile.etl
O Xperf substitui a ferramenta antiga do Kernrate e pode fornecer alguns dados extremamente detalhados.
Quando uma CPU está trabalhando no modo kernel, a maioria das vezes está executando rotinas de serviço de interrupção. (ISRs) Quando ocorre uma interrupção, o trabalho no modo de usuário é suspenso nesse processador, e a CPU executa o ISR registrado nessa interrupção. Se você achar que sua CPU gasta uma quantidade excessiva de tempo nessas interrupções, isso geralmente indica um driver de dispositivo defeituoso que precisa ser atualizado.
O que me incomoda (sem trocadilhos) sobre esse cenário é que parece que qualquer tópico do kernel que esteja fazendo isso parece ser afinizado com aquele núcleo. Eu me pergunto por que o despachante parece estar apenas programando o encadeamento para rodar naquele núcleo aparentemente arbitrário. Então, tenho a sensação de que precisamos encontrar quem escreveu esse driver de dispositivo e mostrar a eles como fazer DPCs segmentados, e não definir explicitamente uma afinidade nos threads do kernel, etc.