Comme Sathya l'a mentionné dans sa question, j'ai déjà eu l'occasion de rencontrer ce problème sur mon ordinateur portable HP similaire, et j'ai maintenant confirmé, en utilisant la méthode scientifique, que les pics de CPU sur les ordinateurs portables HP sont causés par le HP Wireless Assistant. Ou, HP CPU Assassin, comme je pourrais commencer à l'appeler.

Aperçu de l'expérience

• Question : Qu'est-ce qui fait que le CPU des ordinateurs portables de HP monte en flèche à 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 :

• Résultats : La HPWA est à l'origine d'une utilisation extrême du CPU

• Conclusion : Vous devriez désinstaller HPWA car il ne fait rien d'utile_

Informations de base

Lorsque j'ai reçu mon ordinateur portable HP Pavillion dm4t, j'ai remarqué que le CPU atteignait fréquemment une utilisation de 50%, presque toutes les deux secondes. Cela épuisait l'autonomie de la batterie et faisait chauffer l'ordinateur portable ; des symptômes similaires à ceux de Sathya. Rien qu'en regardant le moniteur de ressources de Windows 7, j'ai pu constater que le processus WmiPrvSE.exe était en faute.

Une rapide recherche sur Google a confirmé mon hypothèse selon laquelle il s'agissait du processus hôte Windows Management Instrumentation (WMI). En bref, WMI peut être utilisé pour demander des informations sur le système, comme l'utilisation du processeur, les processus en cours, qui est connecté, et toutes sortes d'autres informations. Le processus hôte WMI exécute des requêtes WMI pour tout autre processus qui les réalise, donc WmiPrvSE.exe n'était pas lui-même le coupable, il était simplement un intermédiaire.

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

Malheureusement, je ne voyais pas comment trouver quel processus effectuait toutes les requêtes, mais comme j'avais isolé ce processus comme étant la source des pics de CPU, et que je savais qu'il s'agissait d'un service, je suis allé voir le responsable des services pour voir quels services dépendaient de WMI, pensant que cela pourrait me conduire à un autre indice.

Je me suis dit que ce ne serait pas un service intégré de Windows qui causerait le problème, donc en les éliminant, j'ai décidé de descendre dans la liste et d'essayer de désactiver chaque service, et de voir si le problème persistait. Tout en haut de la liste se trouvait le service HP Wireless Assistant. Je suis retourné au menu des services, et j'ai désactivé ce service. En regardant dans le gestionnaire de tâches, j'ai vu que l'utilisation de l'unité centrale était tombée à presque rien. J'ai réactivé le service HPWA. L'utilisation du CPU a repris. J'avais maintenant suffisamment de données pour élaborer ma théorie. J'ai désinstallé le service HPWA, et je n'ai plus jamais eu ce 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é le HP Wireless Assistant, que je n'avais pas fait installer depuis des mois. Tout de suite, l'utilisation du processeur a augmenté. J'ai ensuite procédé à 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.exe et HPWA_Main.exe sont les deux. Voici à quoi ressemblait l'utilisation du processeur lorsque ces deux processus fonctionnaient :

Ensuite, j'ai suspendu les deux processus. L'utilisation du CPU a immédiatement diminué ; voici à quoi ressemblait l'utilisation précédente du CPU quelques instants plus tard sur le graphique pour l'effacer :

J'ai réactivé les processus pour voir si l'utilisation remonterait. C'est ce qui s'est passé :

La suspension des processus a de nouveau entraîné une baisse de l'utilisation du CPU :

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é que c'était une preuve suffisante pour montrer que l'assistant sans fil HP était à l'origine du problème, et j'ai par la suite désactivé le service, et je vais maintenant le désinstaller.

Tout ce que l'assistant sans fil HP semble faire est d'informer l'utilisateur quand son sans fil est allumé ou éteint, et d'engloutir le CPU. Il n'y a rien que vous ne puissiez faire avec les outils de gestion sans fil intégrés, donc je vous conseille de supprimer ce logiciel si vous l'avez installé.

Note: Au moins une personne a signalé que la désinstallation du HPWA a provoqué l'arrêt de son interrupteur sans fil sur le clavier. Sur mon ordinateur portable, il a continué à bien fonctionner après la désinstallation de HPWA, mais au cas où le vôtre cesserait de fonctionner, vous pouvez toujours désactiver la carte sans fil depuis Windows. Appuyez sur

Selon une discussion sur les forums de support HP, le problème a été corrigé dans des versions plus récentes de l'assistant sans fil HP. Si votre ordinateur portable a besoin du HPWA pour utiliser le wifi on/off vous pouvez télécharger la dernière version sur le site des pilotes de HP, et vous n'aurez probablement plus ce problème. Néanmoins, si vous n'en avez pas besoin pour le bouton marche/arrêt du wifi, il semble que l'installation de ce logiciel n'apporte toujours aucune valeur ajoutée.

Dépannage

1. Télécharger ProcDump de Microsoft Sysinternals.

2. Laissez le vider une fois que le WmiPrvSE.EXE atteint 25% pendant 1 seconde :

3. Analysez votre (vos) dump(s) en ligne et partagez-le éventuellement sur SpeedyShare .

4. La trace de la pile qui s'affiche devrait inclure la procédure qui en est la cause.

Peut-être que vous pouvez rechercher sur Google quelques-unes des procédures du haut de la pile pour avoir une meilleure idée de ce qu'elles font. Si elles ne vous aident pas, vous pourriez avoir besoin d'une analyse plus avancée. Voir ma prochaine section :

1. Téléchargez le setup 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 :

4. Appuyez sur ENTER une fois pour lancer la commande, maintenant vous devez attendre que le pic se produise.

5. Juste après votre pique, vous allez à la console et appuyez sur ENTER.

6. Après un certain temps d'attente, un fichier de log myTrace.etl sera produit dans votre dossier utilisateur.

7. Exécutez la commande suivante pour afficher le fichier et l'analyser WinDBG Symboles requis) :

Si vous voulez que je l'examine :

1. Compressez myTrace.etl depuis votre dossier utilisateur vers un fichier zip.
2. Partagez le fichier zip compressé sur SpeedyShare .
3. 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 exécuter des requêtes WMI sur le magasin CAPI, vous pourriez ne pas être en mesure de trouver la cause même avec XPerf en raison de 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 , le ClientProcessId serait le PID du processus qui a fait la requête WMI. Ce PID peut être retracé jusqu'au processus en ajoutant une colonne PID dans le gestionnaire des tâches ou dans l’ explorateur de processus , ou avec tasklist /FI "PID eq X" où X est le PID que vous avez trouvé…

Analyse de Dump 1 : Les lignes 94-115 indiquent un appel de procédure à distance . Dans le noyau, un nouveau thread est lancé pour traiter un talon d'appel de procédure à distance .aspx), qui est essentiellement une demande de requête que le fournisseur WMI exécutera et à laquelle il répondra. Il en résulte une activité CPU élevée en raison de la lecture du registre et/ou des informations de performance.

Comme un dump est une capture d'un seul instant, vous ne pourrez pas voir quel processus a exécuté la RPC. Il vous faut donc un programme qui trace comme XPerf pour voir le thread précédent qui exécuterait la RPC. 002 Ou, si vous activez les informations sur l'état de la RPC , vous pouvez utiliser [ rpcdbg ] (http://technet.microsoft.com/en-us/library/cc738291(WS.10) pour voir qui a lancé l'appel. 002 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 de rupture sur la RPC, de sorte que vous pouvez voir qui l'exécute dans la deuxième ligne de la pile. Mais il est peu probable que le fait de fixer un point d'arrêt sur le premier appel (veuillez noter qu'il s'agit d'un débogage en direct) vous aidera à voir qui appelle le fournisseur WMI à chaque fois… 002 Il y a beaucoup plus d'informations dans cet article sur RPC State Information qui pourraient vous aider, mais ce n'est pas pour les faibles comme nous de passer par tout cela alors que nous pourrions simplement utiliser XPerf à la place. :-)

Comme nous savons maintenant comment fonctionne le RPC, nous pourrions aussi bien utiliser API Monitor :

1. Téléchargez, installez et démarrez API Monitor. ( twice if you have 64 bit : once x86, once x64)
2. Allez dans Fichier –> Exécuter en tant qu'administrateur

3. Réglez le Filtre de capture de l'API sur le module Rpcrt4.dll.

4. Comme pour le point d'arrêt, nous voulons savoir qui appelle les fonctions de RpcServerUseProtSeq :

5. Accrochez chaque Processus en cours sauf ceux avec un PID faible (pour éviter les plantages). Idéal, vous ne voulez pas accrocher dwm.exe/winlogon.exe ou inférieur. Vous pouvez aussi essayer des processus uniques et les décrocher plus tard de la fenêtre Processus accrochés…

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

Solution

Il est important de garder votre ordinateur à jour, l'installation de HPWA 4.0.10.0 résout ce problème! ;-)

L'entrée du blog Microsoft Is WMIprvse a real villain ? _ montre comment trouver quel processus est responsable de l'unité centrale que WmiPrvSE.exe utilise.

La méthode utilise l'option Event viewer de “Show Analytic and Debug Logs” pour tracer toute l'activité WMI, obtenant ainsi l'identifiant du processus coupable.

Cette page, qui s'adresse à tous ceux qui se trouvent dans le même bateau, est diffusée sur Google. J'ai eu le même problème avec WmiProvderHost, qui augmentait la puissance du processeur jusqu'à 50 % et vidait la batterie de mon Lenovo Yoga2 Pro sous Windows 8.1.

. Suite à certains des excellents conseils d'investigation 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 caméra et pour moi, c'est le coupable.

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

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 WMItracing.etl généré dans WPA.exe et grag & déposez le graphique “Generic Events” du côté gauche dans le volet d'analyse.

Filtrez maintenant sur les événements Microsoft-Windows-WMI-Activity uniquement, et recherchez les opérations WMI et le ClientProcessId.

Dans mon exemple, ce CLientProcessId appartient à un outil appelé Veeam ONE Monitor Server. Et le deuxième exemple est présenté ici :

Vous voyez des appels récurrents d'un processus avec un PID de 1924 qui appartient au service Intel ProSet Monitoring.

Ici, l'utilisation du CPU est également présentée dans les piles d'appels d'échantillonnage du CPU :

Ainsi, l'outil Intel effectue trop souvent des requêtes de notification WMI, ce qui provoque des problèmes. Arrêt de l'outil, correction du problème.

Avez-vous essayé de voir si c'est un virus ? Certains virus aiment vraiment parader sous forme de services Windows comme ça. Assurez-vous que le processus WmiPrvSE.exe se trouve dans le répertoire c:\windows\system32\wbem. Si ce n'est pas le cas, vous pouvez lancer des programmes de détection de logiciels espions. Si ce n'est pas un logiciel espion, il se peut qu'un autre service l'appelle. Je sais que j'ai quelques gadgets qui tournent rapidement sur mon ordinateur, et ironiquement, le gadget de contrôle des performances fait parfois monter un peu mon processeur en flèche. Il se peut aussi que ce soit un autre service qui appuie sur ce gaz de temps en temps. Par exemple, les bloatwares de HP, Dell, etc.

A part cela, l'autre réponse de TomWij semble assez sympathique pour le dépanner !