Dépannage de l'utilisation élevée du CPU par le processus "Système".

Introduction

Une utilisation élevée du CPU par le processus "Système" peut souvent être causée par un problème de pilote matériel (bug, ancienne version, incompatibilité, etc.).

Le processus Système charge (ou héberge) plusieurs pilotes matériels de différents fournisseurs qui nécessitent un niveau d'accès mémoire plus élevé. C'est pourquoi le diagnostic du coupable spécifique peut nécessiter un peu de travail de détective comme décrit ci-dessous.

Diagnostiquer le problème

Pour diagnostiquer les problèmes d'utilisation du CPU, vous devez utiliser Event Tracing for Windows (ETW) pour capturer les données/profils d'échantillonnage du CPU.

Pour capturer les données, installer le Windows Performance Toolkit qui fait partie de la SDK Windows .

Le WPT Windows 10 peut être utilisé sur Windows 8/Server 2012, Windows 8.1/Server 2012R2 et Windows 10/Server 2016. Si vous utilisez toujours Windows 7, utilisez le SDK/WPT avec Build 15086 .

(toutes les autres entrées peuvent être désélectionnées)

Exécutez maintenant WPRUI.exe , sélectionnez First Level sous la rubrique "Ressources", sélectionnez Utilisation du CPU et cliquez sur commencer .

Maintenant, capturez 1 minute de l'utilisation du CPU. Après 1 minute, cliquez sur Sauvez .

Maintenant analyser le fichier ETL généré avec l'Analyseur de performance Windows en faisant glisser et en déposant le CPU Usage (sampled) au graphique de la analysis pane et ordonner les colonnes comme vous le voyez dans l'image :

A l'intérieur du WPA, charger les symboles de débogage et élargir la pile du processus SYSTEM. Dans cette démo, l'utilisation du CPU provient du pilote nVIDIA.

---

Dans la démo suivante, l'utilisation du CPU provient du pilote Realtek NIC :

---

Quand vous voyez des appels comme ntoskrnl.exe ! Vi KeTrimWorkerThreadRoutine, ntoskrnl.exe!Mm Vérificateur TrimMemory, ntoskrnl.exe ! Vérificateur KeLeaveCriticalRegion cela signifie que vous avez activé Driver Verifier. Cela nuit également aux performances et entraîne une utilisation élevée du SYSTÈME. Désactiver le vérificateur de pilotes et redémarrer.

---

Dans cette démo, le conducteur iai2ce.sys (pilote du contrôleur Intel Serial IO GPIO) en est la cause :

---

Dans cet exemple, l'utilisation du CPU provient du fichier rtsuvc.sys qui semble être le Realtek UVC webcam Driver

---

Cette démo montre que le pilote Bitdefender ignis.sys

---

Dans l'exemple suivant, l'utilisation du CPU est causée par le pilote réseau Broadcom. bcmwl664.sys

---

Quand vous voyez ntoskrnl.exe!MiZeroWorkerPages comme cause, c'est plus délicat. Cela signifie que la fonction du noyau qui remet à zéro la mémoire avant qu'elle ne puisse être réutilisée est à l'origine de l'utilisation élevée du CPU :

Il n'y a pas vraiment de moyen de détecter quel processus en est la cause, mais je sais que Chrome peut le provoquer si l'accélération matérielle est activée dans Chrome. Donc, si vous voyez ce problème et que vous utilisez Chrome, désactivez l'accélération matérielle dans Chrome.

---

Quand vous voyez ces ntoskrnl.exe!RtlpGenericRandomPatternWorker, ntoskrnl.exe!RtlpTestMemoryRandomUp appelle

L'utilisation du CPU provient du noyau qui teste la mémoire pour des problèmes (memtest). Cette utilisation est déclenchée par la tâche de maintenance au ralenti de Windows 8.1/10. Vous pouvez utiliser le planificateur de tâches pour désactiver la tâche d'inactivité.

Dans Windows 10, la tâche s'appelle RunFullMemoryDiagnostics sous le nom de Microsoft > Windows > MemoryDiagnostic > RunFullMemoryDiagnostic .

---

Dans ce cas, l'utilisation du CPU semble provenir de l'application Data Deduplication Fonctionnalité ( dedup.sys!DdpPostCreate ) de Windows Server :

---

Dans cette démo, l'utilisation du CPU est causée par le pilote de la carte WIFI. athrx.sys

Recherchez une mise à jour du pilote si vous voyez ceci.

---

Dans la démo suivante, un pilote Citrix est impliqué :

Contactez donc votre service informatique pour savoir comment résoudre les problèmes liés à Citrix.

---

Dans cette démo, la fonction usbhub.sys!UsbhPortRecycle cause l'utilisation du CPU :

Passage des ports USB2.0 à la vitesse 1.1 ou la connexion de lecteurs USB à d'autres ports USB 2.0 ont aidé certains utilisateurs.

---

Dans ce cas, une petite partie de l'utilisation du SYSTÈME provient du pilote Acronis. tdrpm251.sys :

---

Dans cette démo, l'utilisation du CPU ntoskrnl.exe!KeAcquireSpinLockRaiseToDpc y ntoskrnl.exe!KeReleaseSpinLock .

donc un conducteur utilise SpinLocks très lourdement. Désactivez certains périphériques/pilotes jusqu'à ce que vous trouviez celui qui provoque le problème.

---

Dans ce cas, l'utilisation du CPU est causée par le pilote. L1C62x64.sys

C'est le qualcomm atheros AR8171/8175 PCI-E gigabit Ethernet conducteur. Mettez donc à jour le pilote si vous le voyez dans la pile.

---

Ici, l'utilisation du CPU provient de l'analyse du fichier hôte (netbt.sys!DelayedScanLmHostFile).

Assurez-vous que votre fichier hosts n'est pas trop volumineux pour éviter cette utilisation.

---

Dans ce cas, l'utilisation du CPU provient de SRTSP64.SYS de Symantec.

Mettez à jour votre produit symantec utilisé à la dernière version.

---

Ici, l'utilisation du CPU provient du pilote du GPU AMD (atikmdag.sys).

Si vous voyez cela, allez sur le site d'AMD et obtenez le dernier pilote pour votre carte AMD.

---

Ici, les pilotes TMXPFlt.sys et VsapiNt.sys sont à l'origine d'une utilisation élevée du processeur.

D'après ce que je vois, ces fichiers font partie de la suite Trend Micro AV. Mettez à jour l'outil ou supprimez-le.

---

Dans cet exemple, l'utilisation du CPU provient de la fonction ntoskrnl.exe!MmGetPageFileInformation

Cette fonction permet d'obtenir des informations sur le pagefile.

Description de la routine : Cette routine renvoie des informations sur les fichiers de pagination actuellement actifs. actuellement actifs.

Désactivez le pagefile, redémarrez et réactivez-le et voyez si cela résout le problème. Vous pouvez également supprimer les services Intel (par exemple, le service HECI de protection du contenu Intel). semble l'avoir réparé pour un utilisateur .

---

Ici, vous pouvez voir que le pilote Netwtw04.sys (pilote Intel Wifi) appelle la fonction flushCompleteAllPendingFlushRequests et cela entraîne une forte utilisation du CPU.

Comme les symboles de débogage sont chargés, le pilote inbox de Windows est utilisé. Ce n'est qu'ici que nous pouvons obtenir des symboles de débogage pour voir la pile d'appels avec le nom de la fonction. flushCompleteAllPendingFlushRequests .

Ici, vous devez installez le dernier pilote d'Intel pour le réparer.

---

Le cas le plus compliqué d'utilisation de SYSTEM est l'utilisation de ACPI.sys dans le 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

c'est extrêmement difficile à déboguer. Dans un sujet sysinternals j'ai listé quelques conseils :

• s'assurer que le CPU ne surchauffe pas à cause de la poussière dans le ventilateur du CPU
• mettre à jour ou re-flasher le (même) BIOS/UEFI
• charger les paramètres BIOS/UEFI par défaut
• pour vous assurer que la batterie n'est pas endommagée, retirez la batterie de l'ordinateur portable ou désactivez la batterie dans le gestionnaire de périphériques.
• changer le cavalier sur le support de disque dur si vous avez remplacé le lecteur de DVD/Blue-Ray par un Caddy pour installer un SSD à côté de votre ancien HDD

• désactiver certains appareils selon les conseils de cet utilisateur
• si vous utilisez un chipset Intel, essayez d'installer Technologie de stockage rapide Intel (RST) pour remplacer le pilote AHCI standard de Windows. Cela permet également semble avoir aidé .
• l'utilisateur Shayna a compris qu'en utilisant Process Hacker (commencé comme admin) pour suspendre les fils des problèmes d'ACPI.sys "résout" le problème pour lui. Essayez donc sa solution de contournement si toutes les autres étapes ne vous permettent pas de résoudre le problème.

---

Dans la démo suivante, le pilote Intel HD igdkmd64.sys dans la version .4574 pour l'Intel HD 630 cause le problème :

La solution consiste à mise à jour du pilote avec une version d'au moins .4590.

---

Dans le cas suivant, l'utilisation du processeur du processus SYSTEM est causée par le pilote. stdriverx64.sys

Cela semble être une conducteur de streaming audio . Donc mettez à jour ce logiciel/pilote si vous voyez ceci dans WPA.

---

Si vous voyez un pilote appelé risdxc64.sys dans la pile d'appels du SYSTÈME qui cause l'utilisation élevée du CPU, mettez à jour la pile d'appels du SYSTÈME. Contrôleur hôte PCIe SDXC/MMC de Ricoh ou désactivez le lecteur de carte SD dans le gestionnaire de périphériques si aucune mise à jour du pilote ne résout le problème.

Ce lecteur de carte SD semble être intégré à de nombreux appareils Lenovo.

---

L'utilisateur @stevemidgley a montré un nouveau problème d'utilisation du processeur plus élevé avec Wdf01000.sys!FxSystemWorkItem::_WorkItemThunk

Ici, vous pouvez voir un pilote UDE.sys qui en est la cause.

Dans le hub des symboles

Je peux voir qu'il appartient au pilote du modem et que les données PNP de la trace indiquent Fibocom L850-GL (LTE Modem) comme dispositif possible :

La solution consiste à désactiver le modem et le périphérique composite USB dans le gestionnaire de périphériques.

---

L'utilisateur @fajar a fourni le cas suivant :

Ici, l'utilisation du processeur est faible, mais si vous changez la vue pour l'utilisation DPC/ISR

vous pouvez voir que le pilote avgNetHub.sys utilise beaucoup de DPC.

Le nom indique que ce pilote fait partie du logiciel anti-virus AVG. Mettez donc à jour le logiciel ou supprimez-le si vous voyez ceci dans votre trace.

---

Cela peut être dû à un pilote défectueux ou à un autre module chargé par le système. Pour regarder à l'intérieur du processus du système, vous pouvez utiliser un outil tel que Explorateur de processus .

Téléchargez-le et exécutez-le, puis sélectionnez le processus Système, faites un clic droit et sélectionnez Propriétés :

Passez à l'onglet Fils (ignorez la boîte de dialogue qui mentionne les symboles) :

Cela montrera quel est le fichier qui utilise le CPU de manière excessive, à partir duquel vous pourrez ensuite tenter de le diagnostiquer.

Cependant, comme d'autres l'ont dit dans les commentaires, vous devez vraiment vous éloigner des versions Preview dès que possible !

Une note sur le chargement des symboles de débogage à ajouter à L'excellente réponse de magicandre1981 : si le chargement des symboles dans Windows Performance Analyzer fonctionne correctement, après avoir coché l'option Trace > Charger les symboles vous devriez voir une barre de progression en haut avec Chargement des symboles qui affiche les noms de fichiers à côté et qui prend plusieurs minutes pour se terminer. Vous devriez également voir de nombreuses lignes comme celles ci-dessous dans la console de diagnostic :

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

Si vous ne voyez ni l'un ni l'autre, le chargement des symboles de débogage n'a probablement pas fonctionné et vous ne serez pas en mesure d'interpréter correctement votre trace.

Dans mon cas, le chargement initial des symboles de débogage n'a pas fonctionné. Je l'ai résolu en suivant ces instructions :

1. Déterminez si vous utilisez la version x86 ou x64 du Windows Performance Toolkit.

   C'est facile sur les versions x86 de Windows. Sur les versions x64, vous pouvez vérifier le Gestionnaire des tâches pour la balise *32. Si elle n'est pas là, alors vous êtes vous exécutez la version x64.

   Notez que WPT s'installe toujours dans Program Files (x86), quelle que soit l'architecture. l'architecture.

2. Copiez le dbghelp.dll y symsrv.dll du répertoire correct du débogueur vers le répertoire Windows Performance Toolkit. Sur mon système, les répertoires concernés sont

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

3. Redémarrez Windows Performance Analyzer pour que la version correcte de dbghelp.dll soit récupérée.

Mon problème était que l'utilisation du CPU était ridiculement élevée lors du téléchargement de quoi que ce soit (jusqu'à 4 GHz). J'ai un predator Helios 300 avec une carte WiFi Killer, donc le pilote Killer était pré-installé. J'ai utilisé Process Explorer pour aller dans System Il a découvert que "kfeco10x64.sys" était à l'origine de l'utilisation élevée du processeur. Comme "kfeco10x64.sys" faisait partie du service réseau du tueur, je l'ai désactivé en exécutant msconfig et en décochant tous les services de "Rivet Networks".

Après un redémarrage, le problème a disparu pour moi. Plus important encore, il ne semble pas y avoir de réduction de vitesse lors du téléchargement. J'espère que cela aidera toute personne confrontée au même problème.

Réponse : ajouté par @magicandre1981 est la clé pour résoudre tout problème. Mon cas n'y était pas répertorié, mais j'ai trouvé un mot similaire dans la pile décrite sous The most complicated case of SYSTEM usage is ACPI.sys usage in the callstack: section. Dans mon cas, l'installation Intel Rapid Storage Le conducteur a été aidé. Je ne m'attendais pas à cela, car tout fonctionnait depuis longtemps sans ce pilote et sans aucun problème de processeur. Je mets ma pile ici, probablement quelqu'un trouvera cette réponse par des mots-clés similaires.

Line #, Process, Stack, Count, Weight (in view) (ms), TimeStamp (s), % Weight
3, , [Root], 45104, 45,300.439000, , 16.21
4, ,   ntoskrnl.exe!KiStartSystemThread, 45104, 45,300.439000, , 16.21
5, ,   ntoskrnl.exe!PspSystemThreadStartup, 45104, 45,300.439000, , 16.21
6, ,   |- ntoskrnl.exe!SMKM_STORE_MGR<SM_TRAITS>::SmCompressCtxWorkerThread, 38830, 38,997.540000, , 13.95
7, ,   |    |- ntoskrnl.exe!SMKM_STORE_MGR<SM_TRAITS>::SmCompressCtxProcessEntry, 38708, 38,874.943400, , 13.91
8, ,   |    |    |- ntoskrnl.exe!memcpy, 33888, 34,032.390100, , 12.18
9, ,   |    |    |    |- ntoskrnl.exe!memcpy<itself>, 33655, 33,795.069100, , 12.09
10, ,   |    |    |    |- ntoskrnl.exe!KiDpcInterrupt, 228, 232.331300, , 0.08
11, ,   |    |    |    |- ntoskrnl.exe!KiInterruptDispatchNoLockNoEtw, 4, 3.989700, , 0.00
12, ,   |    |    |    |- ntoskrnl.exe!KiInterruptDispatch, 1, 1.000000, , 0.00
13, ,   |    |    |- ntoskrnl.exe!RtlCompressBuffer, 2571, 2,585.541600, , 0.93
14, ,   |    |    |- ntoskrnl.exe!SMKM_STORE_MGR<SM_TRAITS>::SmCompressCtxProcessReadyQueue, 2015, 2,022.554900, , 0.72
15, ,   |    |    |- ntoskrnl.exe!MmBuildMdlForNonPagedPool, 129, 129.294600, , 0.05
16, ,   |    |    |- ntoskrnl.exe!SMKM_STORE_MGR<SM_TRAITS>::SmCompressCtxProcessEntry<itself>, 63, 62.901700, , 0.02
17, ,   |    |    |- ntoskrnl.exe!ExAcquireSpinLockExclusive, 31, 31.208200, , 0.01
18, ,   |    |    |- ntoskrnl.exe!MetroHash64::Hash, 10, 10.033100, , 0.00
19, ,   |    |    |- ntoskrnl.exe!KiDpcInterrupt, 1, 1.019200, , 0.00
20, ,   |    |- ntoskrnl.exe!SMKM_STORE_MGR<SM_TRAITS>::SmCompressCtxWorkerThread<itself>, 78, 78.477100, , 0.03
21, ,   |    |- ntoskrnl.exe!ExAcquireSpinLockExclusive, 39, 39.068100, , 0.01
22, ,   |    |- ntoskrnl.exe!KeWaitForSingleObject, 5, 5.051400, , 0.00
23, ,   |- ntoskrnl.exe!SMKM_STORE<SM_TRAITS>::SmStWorkerThread, 5420, 5,445.923200, , 1.95
24, ,   |- ntoskrnl.exe!SmKmStoreHelperWorker, 495, 496.265200, , 0.18
25, ,   |- ntoskrnl.exe!SMKM_STORE<SM_TRAITS>::SmStReadThread, 359, 360.710600, , 0.13
26, , n/a, 16760, 16,773.871200, , 6.00

Mise à jour : Malheureusement, le problème est revenu. Après le redémarrage, le PC fonctionne bien pendant un certain temps, mais ensuite la même fuite du processeur apparaît avec la même pile.