Résoudre les problèmes d’utilisation élevée du processeur WMI

Cet article explique comment diagnostiquer les problèmes d’utilisation élevée du processeur Windows Management Instrumentation (WMI) sur n’importe quel système d’exploitation Windows.

Identifier le problème

Dans la plupart des scénarios, l’UC est consommée par le processus de WmiPrvse.exe , et il existe quelques instances où svchost.exe l’hébergement du service WMI (Winmgmt) consomme une utilisation élevée du processeur.

Passez en revue le volet Processus du Gestionnaire de tâches ou le volet Détails pour identifier le processus exact

Identifiez si le processus est WmiPrvse.exe ou svchost.exe (hébergeant le service WMI Winmgmt) et identifiez l’ID de processus.

Note

Vous devrez peut-être ajouter manuellement la colonne PID pour afficher l’ID de processus de tous les processus dans le Gestionnaire des tâches.

Voici un exemple. Accédez aux détails du Gestionnaire>des tâches, puis triez par nom et recherchez le processus WmiPrvse.exe qui consomme une utilisation élevée du processeur. Notez l’ID de processus (PID).

Cette capture d’écran montre plusieurs instances de l’hôte du fournisseur WMI (le processus WmiPrvse.exe) comme étant actives et son utilisation du processeur.

Cette capture d’écran montre l’hôte de services : Windows Management Instrumentation (svchost.exe hébergeant le service Winmgmt) et son utilisation du processeur.

Accédez aux services du Gestionnaire>de tâches, triez par nom et recherchez le service Winmgmt. Notez le PID. Cliquez avec le bouton droit sur le service, puis sélectionnez Accéder aux détails pour localiser le processus de svchost.exe comme suit :

Dans l’exemple, sur trois instances WmiPrvse.exe , PID 3648 se trouve, qui consomme environ 25 % de l’utilisation du processeur. Winmgmt est hébergé sous le processus de svchost.exe avec PID 2752.

Comprendre la consommation du processeur

Cela implique principalement d’observer la consommation globale du processeur et le PID identifié. Il est important de noter quand, comment et fréquence de la consommation du processeur.

Évaluez la situation en comprenant si la consommation du processeur est élevée pendant un certain temps. Vérifiez s’il existe une activité, telle que l’exécution de tâches ou de services spécifiques actifs, l’exécution d’applications de surveillance ou l’exécution de scripts menant à WmiPrvse.exe ou à l’uc élevée winmgmt.

Comprendre s’il existe un modèle, ce qui signifie que l’utilisation du processeur est cohérente, incohérente, aléatoire, sporadique ou a des pics réguliers.

Identifiez la fréquence de la consommation du processeur. Vérifiez s’il se produit uniquement pendant les heures de production, les heures creuses ou une heure aléatoire de la journée. Il peut également se produire pendant une activité spécifique, comme la connexion ou la déconnexion de l’utilisateur.

Vous pouvez utiliser le Gestionnaire des tâches et noter visuellement la façon dont le modèle d’utilisation du processeur est.

Voici un exemple qui montre comment utiliser l’outil Analyseur de performances (Perfmon) pour identifier les instances exactes de WmiPrvse.exe avec le PID que vous avez identifié. Vous pouvez également obtenir une vue graphique de la consommation du processeur de n’importe quel processus (WmiPrvse.exe ou svchost.exe hébergement du service WMI).

1. Ouvrez une invite de commandes avec élévation de privilèges, puis entrez Perfmon.

2. Sélectionnez Analyseur de performances dans le volet gauche, puis sélectionnez le signe plus (+) dans le volet droit pour ouvrir la fenêtre Ajouter des compteurs.

3. Développez Processus et sélectionnez Processus d’ID. Sélectionnez toutes les instances WmiPrvse#, puis sélectionnez Ajouter>OK.

   

   

4. Dans la fenêtre Ajouter des compteurs , développez Processus et sélectionnez %Temps processeur. Sélectionnez le WmiPrvse# correspondant au PID consommant une utilisation élevée du processeur, puis sélectionnez Ajouter>OK.

   

   

5. Pour le compteur « Processus d’ID », le dernier, la moyenne, le minimum et le maximum représentent tous les PID du processus de WmiPrvse.exe respectif. Une fois que vous avez identifié l’instance exacte qui consomme une utilisation élevée du processeur, vous pouvez supprimer les instances restantes de WmiPrvse# de la liste en appuyant sur Supprimer.

Dans l’exemple, il est noté que WmiPrvse.exe PID 556 consommait une utilisation élevée du processeur et qu’il s’agissait de WmiPrvse#1 qui correspond à PID 556 dans Analyseur de performances.

Ensuite, le compteur %Temps processeur de WmiPrvse#1 est ajouté pour afficher une vue graphique dynamique de l’utilisation du processeur de ce processus. Dans l’exemple, la couleur de temps processeur de WmiPrvse#1 passe du jaune au rouge.

Les étapes sont les mêmes pour localiser le svchost# approprié dans Analyseur de performances en cas d’utilisation élevée du processeur par svchost.exe hébergeant le service Wmimgmt.

Si vous constatez qu’un processus svchost.exe hébergeant le service WMI provoque une utilisation élevée du processeur et soupçonnez que WMI contribue au problème, vous pouvez confirmer si le PID du processus svchost.exe héberge le service WMI en exécutant la commande suivante :

tasklist /svc /fi "Services eq Winmgmt"

Si le processus svchost.exe contient plusieurs services, vous pouvez séparer le service WMI en son propre processus de svchost.exe en procédant comme suit :

1. Ouvrez une invite de commandes avec élévation de privilèges.

2. Exécutez la commande suivante :

   sc config Winmgmt type= own
   

3. Redémarrez le service WMI.

Après avoir redémarré le service, vous pouvez exécuter la Tasklist /svc commande pour vérifier si le service Winmgmt s’exécute sous son propre processus de svchost.exe .

Après avoir résolu le problème ou n’a plus besoin que le service se trouve dans son propre processus de svchost.exe, vous pouvez le placer dans le processus de svchost.exe partagé. Vous pouvez effectuer l’action en exécutant la commande suivante à partir d’une invite de commandes, puis en redémarrant le service WMI :

sc config Winmgmt type= share

Diagnostiquer WmiPrvse.exe

Jusqu’à présent, vous n’avez que le PID exact de WmiPrvse.exe qui consomme une utilisation élevée du processeur. Ensuite, rassemblez autant d’informations que possible sur ce PID. Cela vous aide à évaluer la situation ou à identifier quelque chose qui pourrait entraîner le problème. Rassemblez des informations sur l’utilisation d’autres ressources ou identifiez le fournisseur WMI (DLL) exact hébergé par le WmiPrvse.exe PID identifié.

Autres utilisations de ressources telles que la mémoire, les handles, les threads et le nom d’utilisateur

Rassemblez des informations sur l’utilisation d’autres ressources, telles que la mémoire, les handles, les threads et le nom d’utilisateur, au moment de l’utilisation élevée du processeur. Vous pouvez utiliser l’onglet Détails dans le Gestionnaire des tâches, sélectionner le PID exact et le consulter.

Note

Ajoutez des colonnes supplémentaires si nécessaire.

Identifier le fournisseur WMI (DLL) exact hébergé par le piD WmiPrvse.exe identifié

Il existe plusieurs méthodes pour identifier le ou les fournisseurs chargés dans le processus de WmiPrvSE.exe .

1. Utiliser des scripts : répertoriez tous les fournisseurs WMI en cours d’exécution pour générer tous les fournisseurs Windows Management Instrumentation (WMI).

2. L’Explorateur de processus peut vous aider à identifier les fournisseurs exacts hébergés dans le PID identifié. Effectuez les étapes suivantes :

   1. Exécutez l’Explorateur de processus en tant qu’administrateur. Recherchez le piD identifié WmiPrvse.exe , accédez à ses propriétés, puis sélectionnez l’onglet Fournisseurs WMI.

   2. Dans l’exemple suivant, WmiPrvse.exe PID 556 se trouve et se trouve à l’hébergement :

      • Fournisseur WMI : MS_NT_EVENTLOG_PROVIDER
      • Espace de noms : root\CIMV2
      • Chemin d’accès à la DLL : %systemroot%\system32\wbem\ntevt.dll

      

3. Dans la plupart des cas, plusieurs fournisseurs peuvent être chargés. Il peut s’agir de l’un des fournisseurs qui passent du temps dans le processeur, provoquant des problèmes élevés de processeur.

Parfois, si le problème est intermittent ou peu fréquent, la WmiPrvse.exe à l’origine du problème peut être arrêtée au fil du temps. Lorsque le problème se produit à nouveau, il peut s’agir du même fournisseur dans une nouvelle instance de WmiPrvse.exe . Dans ce cas, une fois que vous avez noté le ou les fournisseurs, exécutez l’applet de commande suivante pour afficher le PID actuel du processus de WmiPrvse.exe contenant ce fournisseur :

tasklist /m <Provider DLL>

Voici un exemple :

tasklist /m ntevt.dll 

Par conséquent, il est important de comprendre quels fournisseurs sont chargés dans le processus de WmiPrvse.exe et de noter le PID du processus de WmiPrvse.exe à chaque fois.

Une fois que vous avez le ou les fournisseurs chargés dans le WmiPrvse.exe provoquant une utilisation élevée du processeur, vous pouvez comprendre s’il gère des tâches.

Les tâches peuvent être les requêtes WMI entrantes soumises par le processus client au service WMI, qui est ensuite affecté au processus de fournisseur WMI approprié. Dans l’exemple, la tâche est envoyée au MS_NT_EVENTLOG_PROVIDER fournisseur. L’étape suivante consiste donc à étudier les requêtes et tâches entrantes au MS_NT_EVENTLOG_PROVIDER fournisseur.

Analyser les requêtes entrantes

L’examen des requêtes entrantes implique :

• Identification des requêtes WMI gérées par les fournisseurs WMI provoquant une utilisation élevée du processeur.
• Requêtes WMI class(es).
• Utilisateur associé.
• Processus client qui lance la requête.

Les informations ci-dessus peuvent être collectées à l’aide de l’outil disponible publiquement WMIMon ou des journaux opérationnels WMI-Activity et du suivi WMI disponibles sous Observateur d’événements.

Journaux opérationnels : Microsoft-Windows-WMI-Activity/Operational

Les requêtes entrantes sont enregistrées en tant qu’événements opérationnels dans le journal Microsoft-Windows-WMI-Activity/Operational, disponible sous :

Journaux>des applications et services de l’Observateur>d’événements Microsoft>Windows>WMI-Activity

Il existe plusieurs types d’événements enregistrés.

Si le processus WmiPrvse.exe consommant un processeur élevé est arrêté de temps à autre et que vous savez déjà quel(s) fournisseur(s) sont chargés, l’événement suivant peut aider à déterminer le processus de WmiPrvse.exe actuellement actif hébergeant le fournisseur en question.

Log Name:      Microsoft-Windows-WMI-Activity/Operational
Source:        Microsoft-Windows-WMI-Activity
Event ID:      5857
Task Category: None
User:          NETWORK SERVICE
Description:
MS_NT_EVENTLOG_PROVIDER provider started with result code 0x0. HostProcess = wmiprvse.exe; ProcessID = 556; ProviderPath = %systemroot%\system32\wbem\ntevt.dll

Activer les « journaux d’analyse et de débogage » pour activer le suivi WMI

Dans l’Observateur d’événements, sélectionnez Afficher les>journaux d’analyse et de débogage pour activer le débogage et la trace pour WMI-Activity.

Le débogage et la trace sont désactivés par défaut, et chacun d’eux peut être activé manuellement en cliquant avec le bouton droit sur Trace ou Débogage, puis en sélectionnant Activer le journal.

Note

L’activation des journaux d’activité Show Analytics et Debug permet de déboguer et de tracer presque toutes les sources d’événements et crée une journalisation supplémentaire. Par conséquent, cette opération doit être désactivée une fois l’enquête terminée et ne sera plus utilisée.

Ce suivi peut être activé pendant que vous observez une consommation élevée du processeur par le processus WmiPrvse.exe ou suffisamment long pour capturer le comportement d’une utilisation élevée du processeur pour conserver les journaux propres et modérément dimensionnés pour faciliter l’analyse des traces.

1. Exportez les traces en cliquant avec le bouton droit sur Trace et en sélectionnant Enregistrer tous les événements sous....

2. Sélectionnez .xml ou .csv dans Enregistrer en tant que type.

   Note

   Vous pouvez choisir d’autres formats familiers tels que .EVTX les besoins.

3. Choisissez la langue souhaitée du fichier de suivi.

4. Vous pouvez également choisir d’enregistrer les événements opérationnels WMI-Activity séparément, dans le format souhaité pour vous permettre d’examiner et d’analyser.

Passer en revue les fichiers de trace WMI

Dans le suivi WMI, il existe plusieurs opérations importantes incluses, qui font toutes partie des requêtes WMI entrantes. Les opérations sont documentées dans l’interface IWbemServices (wbemcli.h).

Voici quelques-unes des opérations importantes :

• IWbemServices::ExecQuery méthode (wbemcli.h)
• IWbemServices::ExecMethod méthode (wbemcli.h)
• IWbemServices::ExecQueryAsync méthode (wbemcli.h)

Voici l’une des entrées de journal du fichier CSV WMI-Tracing enregistré :

Niveau	Date et heure	Source	ID de l’événement	Catégorie de la tâche	Description
Information	05-05-23 14:48	Activité Microsoft-Windows-WMI	11	Aucun(e)	CorrelationId = {345E5566-0000-0000-0000-68343241D901} ; GroupOperationId = 30693 ; OperationId = 30694 ; Opération = Démarrer IWbemServices ::ExecQuery - root\cimv2 : select * from Win32_Product ; ClientMachine = 21H2W10M ; Utilisateur = CONTOSO\<UserName> ; ClientProcessId = 5484 ; NamespaceName = 133277000000783520

Un événement similaire au format XML ressemble à ceci :

 <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"> 
<System> 
<Provider Name="Microsoft-Windows-WMI-Activity" Guid="{1418ef04-b0b4-4623-bf7e-d74ab47bbdaa}"/> 
<EventID>11</EventID> 
<Version>0</Version> 
<Level>4</Level> 
<Task>0</Task> 
<Opcode>0</Opcode> 
<Keywords>0x8000000000000000</Keywords> 
<TimeCreated SystemTime="2023-05-05T13:09:18.7442455Z"/> 
<EventRecordID>112</EventRecordID> 
<Correlation ActivityID="{eddc1bfb-0000-0000-0000-18b6cabf5949}"/> 
<Execution ProcessID="2752" ThreadID="4132"/> 
<Channel>Microsoft-Windows-WMI-Activity/Trace</Channel> 
<Computer>21H2W10M.contoso.com</Computer> 
<Security UserID="S-1-5-18"/> 
</System> 
<UserData> 
<Operation_New xmlns="http://manifests.microsoft.com/win/2006/windows/WMI"> 
<CorrelationId>{345E5566-0000-0000-0000-67343241D901}</CorrelationId> 
<GroupOperationId>28089</GroupOperationId> 
<OperationId>28090</OperationId> 
<Operation>Start IWbemServices::ExecQuery - root\cimv2 : select * from Win32_Product</Operation> 
<ClientMachine>21H2W10M</ClientMachine> 
<ClientMachineFQDN>21H2W10M.contoso.com</ClientMachineFQDN> 
<User>CONTOSO\<UserName></User> 
<ClientProcessId>5484</ClientProcessId> 
<ClientProcessCreationTime>133277000000783520</ClientProcessCreationTime> 
<NamespaceName>\\.\root\cimv2</NamespaceName> 
<IsLocal>true</IsLocal> 
</Operation_New> 
</UserData> 
<RenderingInfo Culture="en-US"> 
<Message>CorrelationId = {345E5566-0000-0000-0000-67343241D901}; GroupOperationId = 28089; OperationId = 28090; Operation = Start IWbemServices::ExecQuery - root\cimv2 : select * from Win32_Product; ClientMachine = 21H2W10M; User = CONTOSO\<UserName>; ClientProcessId = 5484; NamespaceName = 133277000000783520</Message> 
<Level>Information</Level> 
<Task/> 
<Opcode>Info</Opcode> 
<Channel/> 
<Provider>Microsoft-Windows-WMI-Activity</Provider> 
<Keywords/> 
</RenderingInfo> 
</Event> 

À partir de l’exemple de sortie d’opération ci-dessus, vous pouvez obtenir et comprendre les informations suivantes :

• Une requête a été lancée le : 2023-05-05 à 13:09:18
• Sur l’ordinateur : 21H2W10M,
• À partir d’un PID client : 5484
• ID d’opération : 28089
• Requête : select * from Win32_Product
• Espace de noms : \\.\root\cimv2
• Opération: IWbemServices::ExecQuery

Voici un autre journal :

Niveau	Date et heure	Source	ID de l’événement	Catégorie de la tâche	Description
Information	05-05-23 14:47	Activité Microsoft-Windows-WMI	12	Aucun(e)	ProviderInfo pour GroupOperationId = 30641 ; Opération = Provider ::CreateInstanceEnum - MS_NT_EVENTLOG_PROVIDER : Win32_NTLogEvent ; HostID = 556 ; ProviderName = MS_NT_EVENTLOG_PROVIDER ; ProviderGuid = {FD4F53E0-65DC-11d1-AB64-00C04FD9159E} ; Chemin = %systemroot%\system32\wbem\ntevt.dll

Le même événement au format XML :

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"> 
<System> 
<Provider Name="Microsoft-Windows-WMI-Activity" Guid="{1418ef04-b0b4-4623-bf7e-d74ab47bbdaa}"/> 
<EventID>12</EventID> 
<Version>0</Version> 
<Level>4</Level> 
<Task>0</Task> 
<Opcode>0</Opcode> 
<Keywords>0x8000000000000000</Keywords> 
<TimeCreated SystemTime="2023-05-05T13:09:18.8438242Z"/> 
<EventRecordID>120</EventRecordID> 
<Correlation ActivityID="{2a353ead-0000-0000-0000-256f9de5fabd}"/> 
<Execution ProcessID="2752" ThreadID="4348"/> 
<Channel>Microsoft-Windows-WMI-Activity/Trace</Channel> 
<Computer>21H2W10M.contoso.com</Computer> 
<Security UserID="S-1-5-21-0000000000-0000000000-00000000-1103"/> 
</System> 
<UserData> 
<Operation_Provider_Info_New xmlns="http://manifests.microsoft.com/win/2006/windows/WMI"> 
<GroupOperationId>28096</GroupOperationId> 
<Operation>Provider::CreateInstanceEnum - MS_NT_EVENTLOG_PROVIDER : Win32_NTLogEvent</Operation> 
<HostId>556</HostId> 
<ProviderName>MS_NT_EVENTLOG_PROVIDER</ProviderName> 
<ProviderGuid>{FD4F53E0-65DC-11d1-AB64-00C04FD9159E}</ProviderGuid> 
<Path>%systemroot%\system32\wbem\ntevt.dll</Path> 
</Operation_Provider_Info_New> 
</UserData> 
<RenderingInfo Culture="en-US"> 
<Message>ProviderInfo for GroupOperationId = 28096; Operation = Provider::CreateInstanceEnum - MS_NT_EVENTLOG_PROVIDER : Win32_NTLogEvent; HostID = 556; ProviderName = MS_NT_EVENTLOG_PROVIDER; ProviderGuid = {FD4F53E0-65DC-11d1-AB64-00C04FD9159E}; Path = %systemroot%\system32\wbem\ntevt.dll</Message> 
<Level>Information</Level> 
<Task/> 
<Opcode>Info</Opcode> 
<Channel/> 
<Provider>Microsoft-Windows-WMI-Activity</Provider> 
<Keywords/> 
</RenderingInfo> 
</Event> 

À partir de la sortie de l’opération du deuxième exemple, vous pouvez obtenir et comprendre les informations suivantes :

• L’opération CreateInstanceEnum est lancée pour le compte de l’utilisateur avec SID : UserID="S-1-5-21-0000000000000000000000000000000000000000-1103 »
• Le 2023-05-05 à 13:09
• Opération exacte : Provider::CreateInstanceEnum - MS_NT_EVENTLOG_PROVIDER : Win32_NTLogEvent
• ID d’hôte : 556
• Nom du fournisseur : MS_NT_EVENTLOG_PROVIDER
• Chemin du fournisseur : %systemroot%\system32\wbem\ntevt.dll

Rechercher les PID client qui provoquent une utilisation élevée du processeur

L’idée de passer en revue ce fichier journal consiste à répertorier les opérations associées aux WmiPrvse.exe PID identifiées qui consomment une utilisation élevée du processeur, à comprendre les requêtes entrantes et à les lancer (le processus client).

Dans l’exemple abordé ci-dessus, il s’agit du PID 552 qui provoque une utilisation élevée du processeur.

À partir du deuxième exemple de la sortie du journal, l’opération CreateInstanceEnum est lancée pour une classe Win32_NTLogEventWMI spécifique.

Pour plus d’informations, consultez Win32_NTLogEvent, qui inclut les détails du fournisseur WMI associés à la classe WMI.

Vous connaissez maintenant le fournisseur WMI exact hébergé (MS_NT_EVENTLOG_PROVIDER) dans le WmiPrvse.exe qui provoque une utilisation élevée du processeur, l’ID hôte (552) et la classe WMI (Win32_NTLogEvent) interrogées par un processus client.

Selon l’outil que vous utilisez pour passer en revue les fichiers de trace, vous pouvez appliquer les filtres nécessaires pour passer en revue uniquement les opérations liées ou Win32_NTLogEvent WmiPrvse.exe PID 552 ou l’ID d’hôte 552 ou ntevt.dll.

Avec le filtre affichant uniquement les lignes ou les opérations qui incluent « Win32_NTLogEvent », les résultats sont les suivants :

Niveau	Source	ID de l’événement	Description
Information	Activité Microsoft-Windows-WMI	11	CorrelationId = {345E5566-0000-0000-0000-68343241D901} ; GroupOperationId = 30641 ; OperationId = 30642 ; Opération = Démarrer IWbemServices ::CreateInstanceEnum - root\cimv2 : Win32_NTLogEvent ; ClientMachine = 21H2W10M ; Utilisateur = CONTOSO\<UserName> ; ClientProcessId = 5484 ; NamespaceName = 133277000000783520
Information	Activité Microsoft-Windows-WMI	12	ProviderInfo pour GroupOperationId = 30641 ; Opération = Provider ::CreateInstanceEnum - MS_NT_EVENTLOG_PROVIDER : Win32_NTLogEvent ; HostID = 556 ; ProviderName = MS_NT_EVENTLOG_PROVIDER ; ProviderGuid = {FD4F53E0-65DC-11d1-AB64-00C04FD9159E} ; Chemin = %systemroot%\system32\wbem\ntevt.dll
Information	Activité Microsoft-Windows-WMI	11	CorrelationId = {345E5566-0000-0000-0000-68343241D901} ; GroupOperationId = 30697 ; OperationId = 30698 ; Opération = Démarrer IWbemServices ::CreateInstanceEnum - root\cimv2 : Win32_NTLogEvent ; ClientMachine = 21H2W10M ; Utilisateur = CONTOSO\<UserName> ; ClientProcessId = 5484 ; NamespaceName = 133277000000783520
Information	Activité Microsoft-Windows-WMI	12	ProviderInfo pour GroupOperationId = 30697 ; Opération = Provider ::CreateInstanceEnum - MS_NT_EVENTLOG_PROVIDER : Win32_NTLogEvent ; HostID = 556 ; ProviderName = MS_NT_EVENTLOG_PROVIDER ; ProviderGuid = {FD4F53E0-65DC-11d1-AB64-00C04FD9159E} ; Chemin = %systemroot%\system32\wbem\ntevt.dll

À partir des opérations ci-dessus, vous pouvez obtenir les informations supplémentaires suivantes :

• Timestamp
• ID d’opération : 30642 ;
• L’opération exacte = Start IWbemServices::CreateInstanceEnum - root\cimv2 : Win32_NTLogEvent;
• Ordinateur client = 21H2W10M
• Utilisateur = CONTOSO\<UserName>
• PID du client qui a lancé la requête : 5484

Enfin, vous avez le PID d’un processus client 5484, qui lance une requête à Win32_NTLogEvent. Cela est géré par le fournisseur MS_NT_EVENTLOG_PROVIDER et hébergé sous WmiPrvse.exe PID 552, ce qui entraîne une utilisation élevée du processeur.

Une fois que vous avez réduit les ID client, utilisez l’un des outils suivants pour trouver le nom du processus.

• Gestionnaire de tâches
• Process Explorer
• Process Monitor
• WMIMon

Plus d’informations sur WmiMon

WMImon.exe est un outil de supervision puissant qui permet le suivi et la surveillance des événements système et l’utilisation des ressources du service WMI.

Il sert la fonction importante d’identification des appels et requêtes WMI effectués par d’autres processus, ainsi que de fournir des informations sur la fréquence des requêtes, le compte d’utilisateur utilisé pour les requêtes et les informations demandées.

Ces données peuvent être utiles pour les administrateurs système qui doivent résoudre les problèmes de performances.

Pour collecter et analyser ces données, vous pouvez suivre les instructions pas à pas :

1. Identifiez le PID de l’WmiPrvSE.exe qui consomme l’utilisation du processeur à l’aide des méthodes décrites ci-dessus.
2. Téléchargez l’outil WMIMon.exe à partir de GitHub - luctalpe/WMIMon. L’outil consiste à surveiller l’activité WMI sur Windows.
3. Extrayez le contenu du fichier WMIMon_Binaries.zip dans un dossier sur votre ordinateur.
4. Ouvrez une invite de commandes en tant qu’administrateur et accédez au dossier où vous avez extrait les fichiers WMIMon.
5. Exécutez le fichier WMIMon.exe en entrant WMIMon.exe dans l’invite de commandes et en appuyant sur Entrée.
6. WMIMon va maintenant commencer à surveiller les appels WMI effectués par les processus sur le système, y compris celui identifié à l’étape 1.
7. WMIMon affiche des informations telles que l’ID de processus client, l’espace de noms WMI appelé par l’opération, le nom de classe WMI et le compte d’utilisateur utilisé pour effectuer la requête.
8. Analysez la sortie de WMIMon pour identifier le ou les processus qui effectuent des appels WMI fréquents et peuvent entraîner une utilisation élevée du processeur.

En suivant ces étapes, vous pouvez utiliser efficacement WMIMon.exe pour surveiller l’activité WMI sur votre système et identifier les problèmes de performances ou de sécurité causés par une utilisation excessive de WMI.

Voici un exemple :

Note

Vous pouvez exporter les données capturées par WMIMon vers un fichier texte en exécutant la WMIMon.exe > Data.txt commande dans l’invite de commandes. Pour arrêter la capture de données, appuyez sur Ctrl + C.

Il peut y avoir des situations difficiles où la réduction d’un PID, d’une application ou d’UN EXE client spécifique est impossible. Dans ce cas, l’examen d’une entité commune telle qu’un nom d’utilisateur ou un ordinateur associé peut être utile.

Autrement dit, comprenez si l’utilisateur qui lance la requête est un compte de service ou associé à une application spécifique.

Autres solutions

Une fois que vous avez finalisé le suspect, vous pouvez envisager de désactiver temporairement son service ou de désinstaller l’application associée et de vérifier si le problème d’utilisation élevée du processeur est résolu.

Voici quelques scénarios où la désactivation peut valider vos observations.

• Surveillance des applications et services
• System Center Configuration Manager (SCCM) (policyhost.exe ou Monitoringhost.exe)
• Powershell.exe des scripts en cours d’exécution contenant des requêtes WMI
• Toute application tierce

Collecte de données

Si vous avez besoin de l’aide du support Microsoft, nous vous recommandons de collecter les informations en suivant les étapes mentionnées dans Collecter des informations à l’aide de TSS pour les problèmes liés à l’expérience utilisateur.

1. Téléchargez TSS.zip et extrayez le contenu.

2. Démarrez le suivi en exécutant l’applet de commande suivante à partir d’une invite de commandes PowerShell avec élévation de privilèges. Maintenez le suivi en cours d’exécution lorsque l’ordinateur rencontre un problème élevé de processeur ou reproductible le problème.

   .\TSS.ps1 -UEX_WMIBase -WIN_Kernel -ETWflags 1 -WPR CPU -Perfmon UEX_WMIPrvSE -PerfIntervalSec 1 -noBasicLog
   

   Note

   Conservez le suivi en cours d’exécution pendant plus de deux minutes. Vérifiez que le problème est reproduit pendant cette fenêtre.

3. Arrêtez le suivi en suivant les instructions de l’invite de commandes PowerShell en fonction de l’ensemble d’outils TSS.

Le script crée un fichier zip contenant les résultats de toutes les traces et les informations de diagnostic. Une fois qu’un cas de support est créé, ce fichier peut être chargé dans l’espace de travail sécurisé à des fins d’analyse.