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 du processeur à 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 de @ nhinkle dans le passé , il semble que HP Wireless Manager pourrait être le coupable, y a-t-il un moyen de le confirmer?)}
Cette question était uneQuestion de la semaine concernant le super utilisateur.
Lisez l’entrée du 28 février 2011du blogpour plus de détails ousoumettez votre propreQuestion de la semaine.
Comme Sathya l’a mentionné dans sa question, j’ai déjà rencontré ce problème sur mon ordinateur portable HP similaire et j’ai maintenant confirmé, à l’aide de la méthode scientifique, que les pics de processeur des ordinateurs portables HP étaient causés par l’assistant sans fil HP. Ou encore, HP CPU Assassin, comme je pourrais commencer à l'appeler.
Question : Qu'est-ce qui provoque le pic du processeur sur les ordinateurs portables HP, en particulier le WmiPrvSE.exe
processus?
Hypothèse : L’assistant sans fil HP (HPWA) est à l’origine du problème
Méthode :
WmiPrvSE.exe
cesse d'utiliser> 20% du processeur lorsque le processus HPWA est suspendu.Résultats : HPWA provoque une utilisation extrême du processeur
Conclusion : Vous devez désinstaller HPWA car cela ne sert à rien
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 Windows Management Instrumentation (WMI). 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'autres informations. Le processus de l'hôte WMI exécute des requêtes WMI pour tout autre processus qui les crée. WmiPrvSE.exe
n'était donc pas le coupable, mais un simple 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 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 aucun moyen de savoir quel processus faisait 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 gestionnaire de 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.
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.exe
et HPWA_Main.exe
sont 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
Un peu de temps après avoir activé HPWA
En suspendant de 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 gober le processeur. Vous ne pouvez rien faire avec ce logiciel 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. presse +x pour ouvrir le centre de mobilité Windows, puis cliquez sur le bouton Turn Wireless Off
.
Selon ne discussion sur les forums d'assistance HP, le problème a été résolu dans les versions plus récentes de HP Wireless Assistant. 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.
Téléchargez ProcDump à partir de Microsoft Sysinternals.
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.
Analysez vos dump (s) en ligne et partagez-le éventuellement sur SpeedyShare .
Alternative : WinDBG peut être utilisé avec la commande !analyze -v
, assurez-vous de définir des symboles .
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.
S'ils ne vous aident pas, vous aurez peut-être besoin d'une analyse plus poussée. Voir ma prochaine section:
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
Presse ENTER une fois pour lancer la commande, vous devez maintenant attendre que le pic soit apparu.
Exécutez la commande suivante pour afficher le fichier et l'analyser ( WinDBG / Symboles requis):
xperf %HOMEPATH%\myTrace.etl
Si vous voulez que je me penche sur la question:
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, car IPC , une autre solution que je viens de trouver serait être pour activer la journalisation WMI et 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 suivi dans le processus en ajoutant une colonne PID au gestionnaire de tâches ou Process Explorer , ou avec tasklist /FI "PID eq X"
où X est le PID que vous avez trouvé ...
Analyse de vidage 1 : Les lignes 94-115 indiquent un appel de procédure distante .
Analyse de vidage 2 : Les lignes 84-105 indiquent un appel de procédure à distance =.
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 un vidage est une capture d'un seul 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 (veuillez noter 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 informations d'état RPC , mais ce n'est pas pour les âmes sensibles, comme nous, de passer en revue tout cela lorsque nous pourrions simplement utiliser XPerf à la place. :-)
Comme nous connaissons maintenant le fonctionnement interne du fonctionnement du RPC, nous pourrions également utiliser API Monitor :
Définissez le filtre de capture de l'API sur le module Rpcrt4.dll
.
Semblable au point d'arrêt, nous voulons savoir qui appelle les fonctions RpcServerUseProtSeq
:
Accrochez chaque processus en cours , sauf pour ceux dont le PID est faible (pour éviter les pannes).
Idéal, vous ne voulez pas utiliser dwm.exe
/winlogon.exe
ou moins.
Vous pouvez également essayer des processus uniques et les décrocher ultérieurement de la fenêtre Processus raccrochés ...
Bien que ... je l'ai essayé et je pouvais m'occuper de n'importe quel processus.
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!
Il est important de garder votre ordinateur à jour, il est important d'installer HPWA 4.0.10. , cela résout ce problème! ;-)
Le blog de MicrosoftEst-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 toutes les activités 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 était pour moi: 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 Windows Performance Toolkit 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 dans le volet d'analyse.
Filtrez maintenant vers Microsoft-Windows-WMI-Activity events uniquement, puis recherchez les opérations WMI et le ClientProcessId.
Dans mon exemple, ce CLientProcessId appartient à un outil appelé Veeam ONE Monitor Server . L'arrêter, corrigé le problème d'utilisation du processeur .
Et le deuxième exemple est montré ici:
Alors que vous voyez 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 processus WmiPrvSE.exe
se trouve dans le répertoire c:\windows\system32\wbem
. 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 accélère parfois la montée en puissance 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!