2013-01-03 03:52:20 +0000 2013-01-03 03:52:20 +0000
108
108

Dépannage Utilisation élevée du CPU par le processus "Système"

J'ai remarqué que mon système se bloque depuis un certain temps et que cela est probablement dû à l'utilisation élevée du CPU qui est causée par le processus système.

Toutes les applications que j'utilise sont Skype, TeamSpeak et Chrome, donc elles ne devraient pas consommer autant de CPU.

Vous pouvez voir le problème lui-même et les processus en cours d'exécution dans la capture d'écran ci-dessous : 002

Parfois, l'utilisation du CPU atteint 90%, mais l'utilisation moyenne est de 40-65%. 002 Mes paramètres PC : 002 - Windows 8 (aperçu client) - Intel Core i3 - 2350M - 8 GB RAM

J'apprécierais toute tentative d'aide ! Regards.

–MISE À JOUR–

Comme l'utilisateur ci-dessous a posté une excellente réponse, j'ai remarqué que le processus qui consomme le plus de CPU dans le système s'appelle Arthurx.sys, simple google dit que c'est un pilote TPLink (un adaptateur wifi, que j'ai acheté il y a environ 2 semaines !) ; les pilotes ont été installés à partir du MSDN de Windows, mais j'ai aussi essayé d'installer les pilotes à partir du CD joint, mais cela n'aide pas. Dès le début du système, il n'utilise que 5% du processeur, mais après 2 à 4 heures de travail, il grandit et atteint 40 à 60% de l'utilisation du processeur.

Nom du périphérique : TPLink WN722N

Antwoorden (5)

107
107
107
2017-01-06 20:34:09 +0000

Pour diagnostiquer les problèmes d'utilisation du CPU, vous devez utiliser le suivi des événements pour Windows (ETW) pour capturer les données d'échantillonnage du CPU / Profil.

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

Le Windows 10 WPT 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 Resource sélectionnez CPU usage et cliquez sur start.

Capturez maintenant 1 minute d'utilisation du CPU. Après 1 minute, cliquez sur Save.

Now analysez le fichier ETL généré avec le Windows Performance Analyzer en glissant et déposant le graphique CPU Usage (sampled) sur le analysis pane et en ordonnant les colonnes comme vous le voyez dans l'image :

Inside WPA, chargez les symboles de débogage et développez 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 :


Lorsque vous voyez des appels comme ntoskrnl.exe ! Vi KeTrimWorkerThreadRoutine, ntoskrnl.exe ! Mm Verifier TrimMemory, ntoskrnl.exe ! Verifier KeLeaveCriticalRegion, cela signifie que vous avez activé le Driver Verifier. Cela nuit aussi beaucoup aux performances et entraîne une forte utilisation du système. Désactiver Driver Verifier et redémarrer.


Dans cette démo, le pilote iai2ce.sys (Intel Serial IO GPIO Controller driver) 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 régie par le pilote de réseau broadcom bcmwl664.sys


Lorsque vous voyez ntoskrnl.exe!MiZeroWorkerPages comme cause, c'est plus délicat. Cela signifie que la fonction du noyau qui met à zéro la mémoire avant qu'elle ne puisse être utilisée à nouveau entraîne une forte utilisation du processeur :

Il n'y a pas de véritable moyen de détecter quel processus en est la cause, mais je sais que Chrome peut en être la cause si l'accélération matérielle est activée dans Chrome. Si vous voyez cela et que vous utilisez Chrome, désactivez l'accélération matérielle dans Chrome.


Lorsque vous voyez ces appels ntoskrnl.exe!RtlpGenericRandomPatternWorker, ntoskrnl.exe!RtlpTestMemoryRandomUp, l'utilisation du CPU provient du noyau pour tester la mémoire en cas de problème (memtest). Cette utilisation est déclenchée par la tâche de maintenance en attente de Windows 8.1/10. Vous pouvez utiliser le planificateur de tâches pour désactiver la tâche inactive.

Dans Windows 10, la tâche est appelée RunFullMemoryDiagnostics sous Microsoft > Windows > MemoryDiagnostic > RunFullMemoryDiagnostic. Dans ce cas, l'utilisation du CPU semble provenir de la fonction Data Deduplication (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 votre service informatique pour savoir comment résoudre les problèmes Citrix.


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

Changement des ports USB2.0 en vitesse 1.1 ou connexion de lecteurs USB à d'autres USB 2. 0 ports a 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 et ntoskrnl.exe!KeReleaseSpinLock.

donc un pilote utilise SpinLocks très fortement. Désactivez certains périphériques/pilotes jusqu'à ce que vous en voyiez un qui en est la cause.


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

Il s'agit du pilote qualcomm atheros AR8171/8175 PCI-E gigabit Ethernet. 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 hôte 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é avec la dernière version. Ici, l'utilisation du CPU provient du pilote GPU AMD (atikmdag.sys)

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


Ici, les pilotes TMXPFlt.sys et VsapiNt.sys provoquent une forte utilisation du CPU.

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


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

Cette fonction obtient des informations sur le fichier de page.

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

Désactiver le fichier de pagination, le redémarrer et l'activer à nouveau et voir si cela le corrige. En outre, la suppression des services Intel (par exemple le service HECI de protection de contenu Intel) semble avoir corrigé le problème pour un utilisateur .


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

Parce que les symboles de débogage sont chargés, le pilote de la boîte de réception 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 devriez installer le dernier pilote d'Intel pour le corriger.


Le cas le plus compliqué d'utilisation de SYSTEME est l'utilisation d'ACPI.sys dans la pile d'appels :

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 une rubrique sysinternals , j'ai énuméré quelques conseils :

  • assurez-vous que le CPU ne surchauffe pas à cause de la poussière dans le ventilateur du CPU
  • mettez à jour ou refaites le (même) BIOS/UEFI
  • chargez les paramètres par défaut du BIOS/UEFI
  • assurez-vous 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 caddy 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 disque dur

La solution est de mettre à jour le pilote avec une version d'au moins . 4590.


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

Il semble s'agir d'un pilote de streaming audio . Si vous voyez un pilote appelé risdxc64.sys dans la pile d'appels du SYSTÈME qui entraîne une forte utilisation du CPU, mettez à jour le pilote Ricoh PCIe SDXC/MMC Host Controller ou désactivez le lecteur de carte SD dans le gestionnaire de périphériques si aucune mise à jour du pilote ne le corrige.

Ce lecteur de carte SD semble être intégré à de nombreux périphériques Lenovo.


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

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

Dans le hub symbole

Je peux voir qu'il appartient au pilote Modem et les données PNP de la trace montrent Fibocom L850-GL (LTE Modem) comme périphérique possible :

Et la solution est de désactiver le modem et le périphérique composite USB dans le gestionnaire de périphériques.


93
93
93
2013-01-03 13:13:47 +0000

Cela peut être dû à un pilote défectueux ou à un autre module chargé par le système. Pour examiner le processus système, vous pouvez utiliser un outil comme Process Explorer .

Téléchargez et exécutez le processus système, puis sélectionnez le processus système, cliquez avec le bouton droit de la souris et sélectionnez Propriétés :

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

Cela montrera quel fichier utilise l'utilisation excessive du processeur, à partir duquel vous pourrez ensuite tenter de le diagnostiquer.

Comme d'autres l'ont dit dans les commentaires cependant, vous devez vraiment vous éloigner des versions de prévisualisation dès que possible !

4
4
4
2017-07-13 17:19:04 +0000

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é Trace > Load Symbols vous devriez voir une barre de progression en haut avec Loading symbols qui affiche les noms de fichiers à côté et prend plusieurs minutes à compléter. 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 aucune de ces lignes, 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 corrigé en suivant ces instructions :

  1. Vérifiez si vous utilisez la version x86 ou x64 du Windows Performance Toolkit.

  2. Copiez les fichiers dbghelp.dll et symsrv.dll du répertoire du débogueur correct dans le répertoire du Windows Performance Toolkit. Sur mon système, les répertoires pertinents sont :

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

-1
-1
-1
2014-12-27 21:50:04 +0000

J'avais le même problème, il a disparu quand j'ai retiré un des modules de RAM. Il semble qu'il était défectueux. Il fonctionne sous Windows 7, 32 bits.

-1
-1
-1
2018-02-11 21:19:31 +0000

Tout d'abord, l'examen et les informations fournies sont très instructifs, mais vous pouvez généralement le découvrir avec beaucoup moins d'intelligence ! J'ai simplement utilisé MSCOFIG.EXE et une recherche binaire pour isoler le service fautif. J'ai constaté que la plupart des problèmes de ce genre sont causés par des logiciels d'Intel. Je commence par désactiver tout service qui n'a pas de nom de société. Ensuite, je commence sur les services Intel. Puis la recherche binaire complète. En général, il faut une heure au maximum pour résoudre le problème sur le PC de quelqu'un. Intel n'a jamais été une bonne société informatique, et ses logiciels le démontrent. Avouons-le, l'architecture Pentium avait une dizaine d'années lorsqu'elle a été lancée. Qui aurait construit une architecture informatique avec une mémoire paginée à l'époque du VAX ? Eh bien, je ne vais pas vous ennuyer avec cette histoire. Non pas que je sois fan d'AMD ou de Microsoft non plus. Peut-être qu'un jour nous reviendrons à la construction de vrais ordinateurs.