Dépannage

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

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

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

   Cela créera un dump dans votre dossier utilisateur.

   N'hésitez pas à répéter cette opération 1 à 2 fois de plus afin d'avoir plus de vidanges et d'être certain que la cause est la vidange et non un autre événement plus normal.

3. Analysez votre/vos décharge(s) en ligne et, éventuellement, le partager sur SpeedyShare .

   Alternative : WinDBG pourrait être utilisé avec la commande !analyze -v assurez-vous de symboles fixes .

4. La trace de la pile qui s'affiche doit inclure la procédure qui provoque ce problème.

Googlez peut-être quelques-unes des procédures les plus élevées 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 :

1. Téléchargez l'installation à partir de Outils d'analyse des performances de Windows pour votre version de Windows.

2. Installez le logiciel sur votre système.

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

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

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

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

6. Après un certain temps, un fichier journal myTrace.etl sera produit dans votre dossier utilisateur.

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

   xperf %HOMEPATH%\myTrace.etl

Si vous voulez que j'y regarde de plus près :

8. Compressez monTrace.etl de votre dossier utilisateur dans un fichier zip.
9. Partagez le fichier zip compressé sur SpeedyShare .
10. Partagez le lien ici, je ferai une tentative pour trouver et vous montrer la cause de votre problème.

Comme WmiPrvSE.EXE est un hôte permettant d'exécuter des requêtes WMI contre le magasin CAPI, il se peut que vous ne puissiez pas trouver la cause, même avec XPerf, pour les raisons suivantes IPC Une autre solution que je viens de trouver serait d'activer l'enregistrement WMI et de vérifier les enregistrements comme décrit ci-dessous aquí le ClientProcessId serait le PID du processus qui a effectué la requête WMI. Ce PID peut être retracé jusqu'au processus en ajoutant une colonne PID au Gestionnaire des tâches ou à l'application Explorateur de processus ou avec tasklist /FI "PID eq X" où X est le PID que vous avez trouvé...

Analyse de Décharge 1 : Les lignes 94 à 115 indiquent un Appel de procédure à distance .
Analyse de Décharge 2 : Les lignes 84 à 105 indiquent un Appel de procédure à distance .

Dans le noyau, un nouveau fil est lancé. pour gérer un stub d'appel de procédure à distance Il s'agit essentiellement d'une demande de requête que le fournisseur WMI exécutera et à laquelle il répondra. Il en résulte une forte activité du CPU en raison de la lecture du registre et/ou des informations sur les performances.

Comme un dump est une capture d'un seul instant, vous ne pourrez pas voir quel processus a exécuté le RPC.
Vous avez donc besoin d'un programme qui trace, comme XPerf, pour voir le fil d'exécution précédent qui effectue le RPC.

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

例

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 breakpoint sur le RPC, de sorte que vous obtenez de voir qui l'exécute dans la deuxième ligne de la pile. Mais bon, il est peu probable que le fait de définir un breakpoint sur le premier appel (veuillez noter qu'il s'agit de débogage en direct) vous aidera à voir qui appelle le fournisseur WMI à chaque fois...

Il y a beaucoup plus d'informations dans cet article sur Informations sur l'état du CPR cela pourrait aider, mais ce n'est pas pour les timorés comme nous de passer par tout cela quand nous pourrions simplement utiliser XPerf à la place :-)

Comme nous connaissons maintenant le fonctionnement interne du RPC, nous pourrions tout aussi bien utiliser la méthode suivante Moniteur API :

1. Téléchargez, installez et démarrez API Monitor. _{( <strong>deux fois </strong>si vous avez 64 bits : une fois x86, une fois x64)}

2. Aller à Fichier --> Exécuter en tant qu'administrateur

3. Définissez le Filtre de capture de l'API à la Rpcrt4.dll module.

4. De la même manière que pour le breakpoint, nous voulons savoir qui appelle la RpcServerUseProtSeq fonctions :

5. Crochet chacun Processus d'exécution à l'exception de ceux dont le PID est faible (pour éviter les collisions).
   Idéal, vous ne voulez pas accrocher dwm.exe / winlogon.exe ou moins.
   Vous pouvez également essayer des processus uniques et les décrocher plus tard de l'application Processus d'accrochage fenêtre...

   Bien que... J'ai essayé et je pourrais accrocher n'importe quel processus.

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

Solution

Il est important de maintenir votre ordinateur à jour, en installant HPWA 4.0.10.0 résout ce problème ! ;-)

L'article du blog de Microsoft WMIprvse est-il un vrai méchant ? montre comment trouver le processus responsable de l'utilisation du CPU par WmiPrvSE.exe.

Cette méthode utilise l'option "Show Analytic and Debug Logs" de l'Observateur d'événements pour suivre toute l'activité WMI et obtenir ainsi l'identifiant du processus coupable.

J'ajoute juste ceci pour tous ceux qui sont dans le même bateau, cette page est partout sur Google. J'ai eu le même problème avec WmiProvderHost qui a fait grimper le CPU jusqu'à 50% et a vidé la batterie sur mon Lenovo Yoga2 Pro sous Windows 8.1.

Après avoir suivi certains des excellents conseils d'investigation ci-dessus, j'ai découvert que le problème pour moi était en fait le suivant Studio GoPro (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'était le coupable.

Pour le déboguer, utilisez xperf à partir de l'onglet Kit d'outils de performance Windows 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 fichier WMItracing.etl généré dans WPA.exe et faites glisser le graphique "Generic Events" du côté gauche vers le volet d'analyse.

Maintenant, filtrez pour Microsoft-Windows-WMI-Activity uniquement, et recherchez les opérations WMI et le ClientProcessId.

Dans mon exemple, ce CLientProcessId appartient à un outil appelé Serveur Veeam ONE Monitor . En l'arrêtant, le problème d'utilisation du CPU a été résolu. .

Un deuxième exemple est présenté ici :

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

Ici, l'utilisation du CPU est également indiquée dans les callstacks d'échantillonnage du CPU :

Ainsi, l'outil Intel effectue trop souvent des requêtes de notification WMI, ce qui cause les problèmes. En l'arrêtant, on a résolu le problème.