Je garde généralement mon ordinateur portable 24 heures sur 24, 7 jours sur 7, et à la fin de la journée, il est vraiment ennuyeux de me brûler les cuisses à cause d'une surchauffe.

La surchauffe semble résulter du fait que l'hôte fournisseur WMI (WmiPrvSE.exe) a augmenté l'utilisation de l'UC à 25% toutes les quelques minutes. Pourquoi cela arrive-t-il?

J'ai un HP Envy 14 (avec la merde fournie par HP) fonctionnant sous Windows 7 Home Premium.

(Remarque: d'après les observations antérieures de @ nhinkle , il semble que HP Wireless Manager pourrait en être le coupable. Y a-t-il un moyen de le confirmer?)

Cette question était une question de super utilisateur de la semaine .
Lisez l' entrée de blog du 28 février 2011 pour plus de détails ou soumettez votre propre question de la semaine.

Comme Sathya l'a mentionné dans sa question, j'ai déjà eu l'expérience de ce problème sur mon ordinateur portable HP similaire, et j'ai maintenant confirmé en utilisant la méthode scientifique que les pointes de processeur sur les ordinateurs portables HP sont causées par l'Assistant sans fil HP. Ou encore, HP CPU Assassin, comme je pourrais commencer à l'appeler.

Vue d'ensemble de l'expérience

• Question : Qu'est-ce qui cause la pointe du processeur sur les ordinateurs portables HP à des intervalles fréquents, en particulier le WmiPrvSE.exe processus?

• Hypothèse : l’ assistant sans fil HP (HPWA) est à l’origine du problème

• Méthode :

  1. Vérifiez si le problème commence à se produire lorsque HPWA est installé.
  2. Vérifiez si le processeur arrête de piquer et si le WmiPrvSE.exeprocessus cesse d'utiliser> 20% du processeur lorsque le processus HPWA est suspendu.
  3. Voir si le processeur recommence à piquer lorsque le processus HPWA est réactivé
  4. Répétez les étapes 2 et 3 pour plusieurs essais afin de garantir l'exactitude des résultats.
      

• Résultats : HPWA provoque une utilisation extrême du processeur

• Conclusion : vous devez désinstaller HPWA, cela ne sert à rien.

Informations d'arrière-plan

Lorsque j'ai eu mon ordinateur portable HP Pavillion dm4t, j'ai remarqué que le processeur atteignait souvent 50% d'utilisation, presque toutes les deux secondes. Cela épuisait la vie de la batterie et chauffait l'ordinateur portable; à peu près les mêmes symptômes que Sathya a connus. En regardant simplement le Moniteur de ressources dans Windows 7, j'ai pu constater que le processus WmiPrvSE.exeétait en cause.

Une recherche rapide sur Google a confirmé mon hypothèse selon laquelle il s’agissait du processus hôte WMI ( Windows Management Instrumentation ). En bref, WMI peut être utilisé pour interroger des informations système, telles que l'utilisation du processeur, les processus en cours d'exécution, les utilisateurs connectés et toutes sortes d'informations. Le processus hôte WMI exécute des requêtes WMI pour tout autre processus qui les crée. Par conséquent, ce WmiPrvSE.exen'était pas lui-même le coupable, c'était simplement un intermédiaire.

Afin de rechercher quel processus spécifique était à l'origine de ce problème, j'ai utilisé Systinternals Process Explorer . J'ai trouvé quelle instance du WmiPrvSE.exeprocessus utilisait une grande quantité de CPU et j'ai cliqué dessus pour ouvrir des informations détaillées.

Malheureusement, je ne voyais aucun moyen de savoir quel processus posait toutes les requêtes, mais comme je l'avais isolé comme source des pics de processeur et que je savais qu'il s'agissait d'un service, je suis allé voir le responsable des services. les services dépendaient de WMI, pensant que cela pourrait me conduire à un autre indice.

J'ai pensé qu'il ne s'agirait pas d'un service Windows intégré à l'origine du problème. C'est pourquoi, j'ai décidé de réduire la liste et d'essayer de désactiver chaque service afin de vérifier si le problème persistait. En haut de la liste se trouvait le service HP Wireless Assistant. Je suis retourné au menu des services et ai désactivé ce service. En regardant en arrière dans le gestionnaire de tâches, j'ai vu que l'utilisation du processeur était presque nulle. Je le service HPWA sur. L'utilisation du processeur a repris. J'avais maintenant assez de données pour former ma théorie. J'ai désinstallé le service HPWA et je n'ai plus jamais eu le problème.

Vérification de l'hypothèse

Plusieurs mois plus tard, Sathya pose cette question. J'ai décidé de prouver une fois pour toutes que c'était la faute de HPWA. J'ai réinstallé l'assistant sans fil HP, que je n'avais pas installé depuis des mois. Tout de suite, l'utilisation du processeur a augmenté. J'ai ensuite vécu l'expérience décrite ci-dessus.

Tout d'abord, j'ai isolé le processus responsable du service HPWA dans le moniteur de ressources. HPWA_Service.exeet HPWA_Main.exesont les deux. Voici à quoi ressemblait l'utilisation du processeur avec ces deux processus en cours d'exécution:

Ensuite, j'ai suspendu les deux processus. L'utilisation du processeur a immédiatement diminué; voici à quoi cela ressemblait après quelques instants pour que l'utilisation antérieure de la CPU sur le graphique s'efface:

J'ai activé à nouveau les processus pour voir si l'utilisation allait remonter. Ça faisait:

^{Le premier pic que j'active HPWA}

^{Peu de temps après j'ai activé HPWA}

En suspendant à nouveau les processus, l'utilisation du processeur a été réduite:

J'ai testé cela pour une itération supplémentaire, et lors du troisième essai, la même chose s'est produite à nouveau. J'ai considéré ces preuves suffisantes pour montrer que HP Wireless Assistant était à l'origine du problème, puis j'ai désactivé le service et je vais maintenant le désinstaller.

Tout ce que HPWA semble faire, c’est informer l’utilisateur lorsque son réseau sans fil est allumé ou éteint et engloutir le processeur. Vous ne pouvez rien en faire avec les outils de gestion sans fil intégrés. Je vous conseillerais donc de le supprimer si ce logiciel est installé.

Remarque: au moins une personne a signalé que la désinstallation de HPWA avait entraîné l'arrêt de son commutateur sans fil sur le clavier. Sur mon ordinateur portable, il a bien fonctionné après la désinstallation de HPWA, mais au cas où le vôtre ne fonctionnerait plus, vous pouvez toujours désactiver la carte sans fil à partir de Windows. Appuyez sur + xpour ouvrir le centre de mobilité Windows, puis cliquez sur le Turn Wireless Offbouton.

Selon une discussion sur les forums d'assistance HP, le problème a été résolu dans les versions plus récentes de l'Assistant sans fil HP. Si votre ordinateur portable a besoin de HPWA pour utiliser le bouton d'activation / désactivation du wifi, vous pouvez télécharger la dernière version à partir du site Web des pilotes HP et n'aura probablement plus ce problème. Néanmoins, si vous n'en avez pas besoin pour le bouton wifi on / off, l'installation de ce logiciel ne présente toujours aucun avantage.

Dépannage

1. Téléchargez ProcDump à partir de Microsoft Sysinternals.

2. Laissez-le prendre un cliché une fois que le fichier WmiPrvSE.EXE atteint 25% pendant 1 seconde:

   procdump.exe -c 25 -s 1 -x WmiPrvSE.EXE %HOMEPATH%\WmiPrvSE.dmp
   

   Cela créera un cliché dans votre dossier utilisateur.

   N'hésitez pas à répéter cette opération 1 à 2 fois afin que vous disposiez de davantage de vidages et que vous puissiez être certains que la cause est rejetée et non un autre événement plus normal.

3. Analysez votre ou vos fichiers en ligne et partagez-les éventuellement sur SpeedyShare .

   Alternative : WinDBG peut être utilisé avec la commande !analyze -v, assurez-vous de définir des symboles .

4. La trace de pile qui s'affiche doit inclure la procédure à l'origine de cela.

Peut-être google quelques-unes des meilleures procédures de la pile pour avoir une meilleure idée de ce qu’elles font.
Si cela ne vous aide pas, vous aurez peut-être besoin d'une analyse plus poussée. Voir ma prochaine section:

1. Téléchargez la configuration à partir de Windows Performance Analysis Tools pour votre version de Windows.
2. Installez le logiciel sur votre système.

3. Ouvrez une invite de commande en tant qu'administrateur et copiez-collez la commande suivante:

   xperf -start perf!GeneralProfiles.InBuffer -stackwalk profile && timeout -1 && xperf -stop perf!GeneralProfiles.InBuffer %HOMEPATH%\myTrace.etl
   

4. Appuyez ENTER une fois sur cette touche pour lancer la commande. Vous devez maintenant attendre que le pic soit apparu.

5. Juste après votre pointe, vous allez à la console et appuyez sur ENTER.
6. Après avoir attendu quelque temps, un fichier journal myTrace.etl sera créé dans votre dossier utilisateur.

7. Exécutez la commande suivante pour afficher le fichier et l’analyser ( WinDBG / Symbols required):

   xperf %HOMEPATH%\myTrace.etl
   

Si vous voulez que je l'examine:

8. Compressez myTrace.etl à partir de votre dossier d’utilisateur dans un fichier zip.
9. Partagez le fichier zip compressé sur SpeedyShare .
10. Partagez le lien ici, je vais essayer de trouver et de vous montrer la cause de votre problème.

Comme WmiPrvSE.EXE est un hôte pour l'exécution de requêtes WMI sur le magasin CAPI, vous ne pourrez peut-être pas trouver la cause, même avec XPerf en raison d' IPC . Une autre solution que je viens de trouver serait d'activer la journalisation WMI et de vérifier les journaux. Comme décrit ici , ClientProcessId serait le PID du processus qui a créé la requête WMI. Ce PID peut être suivi dans le processus en ajoutant une colonne PID à Task Manager ou Process Explorer , ou avec tasklist /FI "PID eq X"X où est le PID que vous avez trouvé ...

Analyse du vidage 1 : Les lignes 94 à 115 indiquent un appel de procédure à distance .
Analyse du vidage 2 : Les lignes 84-105 indiquent un appel de procédure distante .

Dans le noyau, un nouveau thread est démarré pour gérer un talon d'appel de procédure distante , qui est essentiellement une demande de requête à laquelle le fournisseur WMI doit s'exécuter et y répondre. Cela entraîne une activité élevée du processeur en raison de la lecture des informations du Registre et / ou des performances.

Comme une sauvegarde est une capture d'un instant, vous ne pourrez pas voir quel processus a exécuté le RPC.
Donc, vous avez besoin d'un programme qui trace comme XPerf pour voir le thread précédent qui ferait le RPC.

Ou, si vous activez les informations d'état RPC , vous pouvez utiliser rpcdbg pour voir qui a initié l'appel.

Exemple:

0:000> bp rpcrt4!RpcServerUseProtseqEpA
0:000> g
Breakpoint 0 hit
eax=00452000 ebx=7ffd5000 ecx=00452008 edx=00000014 esi=00d5f55c edi=7c911970
eip=77e97a0b esp=0012ff3c ebp=0012ff6c iopl=0 nv up ei pl nz na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000206
RPCRT4!RpcServerUseProtseqEpA:
77e97a0b 8bff mov edi,edi
0:000> kb
ChildEBP RetAddr Args to Child
0012ff38 00401046 00452000 00000014 00452008 RPCRT4!RpcServerUseProtseqEpA
0012ff6c 00401e37 00000001 003330a0 00333120 hellos!main+0x46 [e:\projects\hello\hellos.c @ 21]

L'exemple ci-dessus définit un point d'arrêt sur le RPC afin que vous puissiez voir qui l'exécute dans la deuxième ligne de la pile. Mais bon, il est peu probable que définir un point d'arrêt lors du premier appel (notez qu'il s'agit d'un débogage en direct) vous aidera à voir qui appelle le fournisseur WMI à chaque fois ...

Cet article contient beaucoup plus d'informations sur les informations d'état RPC , mais ce n'est pas pour les âmes sensibles comme nous de passer par tout cela lorsque nous pourrions simplement utiliser XPerf. :-)

Comme nous connaissons maintenant le fonctionnement interne du RPC, nous pourrions également utiliser API Monitor :

1. Téléchargez, installez et démarrez API Monitor. _{( deux fois si vous avez 64 bits: une fois x86, une fois x64)}
2. Allez dans Fichier -> Exécuter en tant qu'administrateur

3. Définissez le filtre de capture de l' API sur le Rpcrt4.dllmodule.

   

4. Semblable au point d'arrêt, nous voulons savoir qui appelle les RpcServerUseProtSeqfonctions:

   

5. Accrochez chaque processus en cours sauf ceux dont le PID est faible (pour éviter les pannes).
   Idéal, vous ne voulez pas brancher dwm.exe/ winlogon.exeou moins.
   Vous pouvez également essayer des processus uniques et les décrocher plus tard à partir de la fenêtre Processus accrochés ...

   Bien que ... je l'ai essayé et je pouvais m'occuper de n'importe quel processus.

6. Si tout se passe bien, le processus accroché qui effectue l'appel RPC contiendra des threads.
   Et en cliquant sur ces discussions, vous devriez voir un tas d'appels.
   Si vous le faites, vous avez trouvé le processus à l'origine du problème!

Solution

Garder votre ordinateur à jour est important, installer HPWA 4.0.10.0 résout ce problème! ;-)

Le blog de Microsoft Est-ce que WMIprvse est un vrai méchant? montre comment trouver le processus responsable du processeur utilisé par WmiPrvSE.exe.

La méthode utilise l'option "Afficher les journaux d'analyse et de débogage" de l'observateur d'événements pour tracer toute l'activité WMI, obtenant ainsi l'identificateur de processus du processus coupable.

En ajoutant simplement ceci à quiconque dans le même bateau, cette page est partout sur Google. J'ai eu le même problème avec WmiProvderHost spiking CPU jusqu'à 50% et batterie épuisée sur mon Lenovo Yoga2 Pro sur Windows 8.1.

Suite à quelques-uns des excellents conseils d'enquête ci-dessus, j'ai découvert que le problème pour moi était en fait GoPro Studio (logiciel de montage vidéo gratuit fourni avec les caméras GoPro). Il installe un service de surveillance qui attend que vous connectiez votre appareil photo et pour moi, c'était le coupable.

Pour le déboguer, utilisez xperf à partir du toolkit Windows Performance et exécutez le fichier cmd suivant:

xperf -on PROC_THREAD+LOADER+PROFILE+INTERRUPT+DPC+DISPATCHER -stackwalk profile -BufferSize 1024 -MaxFile 256 -FileMode Circular -f Kernel.etl
xperf -start WMILogger -on Microsoft-Windows-WMI-Activity::0xff -BufferSize 1024 -f WMI.etl

echo Please capture about 30s of the WMI activity.

pause

xperf -stop
xperf -stop WMILogger
xperf -merge WMI.etl kernel.etl WMItracing.etl

del WMI.etl
del kernel.etl

Ouvrez le fichier WMItracing.etl généré dans WPA.exe et déplacez le graphique "Événements génériques" du côté gauche vers le volet d'analyse.

Maintenant , filtrez à Microsoft Windows WMI-activité que les événements, et rechercher des opérations WMI et le ClientProcessID.

Dans mon exemple, ce CLientProcessId appartient à un outil appelé Veeam ONE Monitor Server . L'arrêter, corrige le problème d'utilisation du processeur .

Et le deuxième exemple est montré ici:

Vous voyez ici des appels récurrents d’un processus avec un PID de 1924 appartenant au service de surveillance Intel ProSet.

Ici, l'utilisation du processeur est également indiquée dans les piles d'appels d'échantillonnage du processeur:

Ainsi, l'outil Intel effectue trop souvent des requêtes de notification WMI, ce qui entraîne des problèmes. L'arrêter, corrigé le problème.

Avez-vous essayé de voir si c'est un virus? Certains virus aiment vraiment se présenter comme des services Windows. Assurez-vous que le WmiPrvSE.exeprocessus est situé dans le c:\windows\system32\wbemrépertoire. Sinon, vous voudrez peut-être exécuter des programmes de détection de logiciels espions généraux. S'il ne s'agit pas d'un logiciel espion, il est possible qu'un autre service l'appelle. Je sais que j'ai quelques gadgets fonctionnant rapidement sur mon ordinateur et, paradoxalement, le gadget Moniteur de performances augmente parfois légèrement la vitesse de mon processeur. En outre, ce pourrait être un autre service qui presse ce gaz de temps en temps. Par exemple, bloatware de HP, Dell, etc.

En dehors de cela, l’autre réponse de TomWij semble assez agréable pour le dépanner!