Dans la quasi-totalité des cas, le processus WmiPrvSE.exe ne fait que travailler pour quelqu’un d’autre : un logiciel de supervision, un agent d’inventaire ou un script interroge Windows en boucle, et l’hôte de fournisseur WMI paie la facture en temps processeur. Microsoft le dit noir sur blanc dans sa procédure de diagnostic : le processeur est consommé par WmiPrvSE.exe, mais la cause se trouve dans le fournisseur chargé et dans le processus client qui l’appelle.
Points clés
- WmiPrvSE.exe est l’hôte des fournisseurs WMI, isolés dans un processus séparé pour qu’un fournisseur défaillant n’emporte pas tout l’hôte de services.
- Plusieurs instances simultanées sont normales : chacune peut tourner sous un compte système différent.
- Le diagnostic Microsoft se fait en trois temps : noter le PID fautif, identifier la DLL du fournisseur chargée dans ce PID, puis remonter au processus client qui envoie les requêtes.
- L’événement 5857 du journal WMI-Activity/Operational donne le nom du fournisseur et le chemin de sa DLL. L’événement 5612 signale un quota de ressources dépassé.
- Supprimer le référentiel WMI n’est jamais une première étape : Microsoft prévient que l’opération peut endommager le système ou les applications installées.
À quoi sert WmiPrvSE.exe
Windows Management Instrumentation est l’interface par laquelle les applications, les scripts et les consoles d’administration lisent l’état d’une machine : matériel, services, journaux, disques, correctifs installés. Le service WMI lui-même s’appelle Winmgmt et vit dans un processus svchost.exe partagé avec d’autres services.
Les fournisseurs, eux, sont des DLL spécialisées, chacune accompagnée d’un fichier MOF qui décrit ses classes. Pour éviter qu’un fournisseur qui plante n’arrête tous les services voisins, Windows les charge dans un processus hôte distinct nommé Wmiprvse.exe. La documentation Win32 précise que plusieurs processus portant ce nom peuvent tourner en même temps, chacun sous un compte de sécurité différent. Voir trois ou quatre lignes WmiPrvSE.exe dans le Gestionnaire des tâches n’est donc pas un symptôme.
Pourquoi le processeur grimpe
Le processus reste inactif la plupart du temps et se réveille à la demande. La charge apparaît quand les requêtes arrivent trop vite, portent sur des classes coûteuses, ou reviennent en boucle. Les profils les plus fréquents :
- un agent de supervision, d’inventaire ou d’antivirus qui interroge des classes WMI à intervalle très court ;
- une requête mal écrite, par exemple une énumération complète là où un filtre suffirait ;
- un fournisseur tiers installé par un pilote ou un utilitaire constructeur ;
- un fournisseur qui ne libère pas ses ressources et finit par dépasser son quota.
La procédure Microsoft insiste sur un point avant toute manipulation : caractériser la charge. Est-elle constante, sporadique, en pics réguliers ? Apparaît-elle à l’ouverture de session, pendant les heures de production, ou à heure fixe ? Un pic de quelques secondes après le lancement d’un outil d’administration est un comportement attendu, pas un incident.
Étape 1 : isoler la bonne instance
- Ouvrez le Gestionnaire des tâches, onglet Détails. Si la colonne PID est absente, ajoutez-la par un clic droit sur l’en-tête des colonnes.
- Triez par nom, repérez l’instance de WmiPrvSE.exe qui consomme le processeur et notez son PID.
- Regardez aussi la mémoire, les handles, les threads et le nom d’utilisateur de ce PID : ces colonnes servent à la suite du diagnostic.
- Si la ligne qui charge n’est pas WmiPrvSE.exe mais un svchost.exe, vérifiez qu’il héberge bien le service WMI avec la commande
tasklist /svc /fi "Services eq Winmgmt"dans une invite de commandes.
Pour suivre l’instance dans le temps, l’Analyseur de performances (commande perfmon) permet d’ajouter le compteur Processus, ID de processus pour les instances WmiPrvse#, de repérer celle qui correspond au PID noté, puis d’y ajouter le compteur Pourcentage de temps processeur. Le lien entre numéro d’instance et PID n’est pas stable d’un redémarrage à l’autre.
Étape 2 : identifier le fournisseur chargé
Deux méthodes officielles donnent le même résultat. La première passe par les journaux. Dans l’Observateur d’événements, ouvrez Journaux des applications et des services, puis Microsoft, Windows, WMI-Activity, Operational. Les événements d’ID 5857 signalent le démarrage d’un fournisseur et contiennent le nom du fournisseur, le champ HostProcess, le ProcessID et le chemin de la DLL, par exemple %systemroot%\system32\wbem\ntevt.dll pour le fournisseur du journal d’événements.
La seconde passe par Process Explorer, l’outil Sysinternals publié par Microsoft. Lancé en administrateur, il expose pour chaque processus WmiPrvSE.exe un onglet Fournisseurs WMI qui liste les fournisseurs chargés, leur espace de noms et le chemin de leur DLL. C’est la confirmation visuelle de ce que disent les journaux.
Quand l’incident est intermittent, le processus fautif est souvent détruit avant l’examen. Le fournisseur reste le même et réapparaît dans une nouvelle instance : l’événement 5857 donne le PID actif du moment.
Étape 3 : remonter au processus client
Un fournisseur ne s’active pas tout seul. Les tâches qu’il traite viennent de requêtes soumises par un processus client au service WMI, qui les répartit ensuite vers le fournisseur concerné. L’analyse des requêtes entrantes et du suivi d’activité WMI, décrite dans la procédure Microsoft, sert à répondre à trois questions : quel processus client interroge, quelle requête pose problème, à quelle fréquence elle revient.
Une fois le client identifié, la correction se fait de son côté et pas dans WMI : réduire la fréquence de collecte, corriger la requête, mettre à jour ou désinstaller l’utilitaire en cause. C’est la seule action durable.
Solutions, de la plus sûre à la plus lourde
- Redémarrer le service WMI. Un arrêt puis un démarrage de Winmgmt dans la console Services libère les processus hôtes en cours. Le gain est souvent temporaire, mais il confirme que la charge est liée à une session de requêtes et pas à une corruption.
- Isoler le service pour mesurer proprement. Quand le svchost.exe hébergeant WMI est partagé avec d’autres services,
sc config Winmgmt type= ownplace WMI dans son propre processus. Le retour à l’état partagé se fait avecsc config Winmgmt type= share, suivi d’un redémarrage du service. - Traiter le client fautif. Mise à jour, changement d’intervalle de collecte ou désinstallation de l’agent, du pilote ou de l’outil d’inventaire identifié à l’étape 3.
- Vérifier l’intégrité des fichiers système.
sfc /scannowpuisDISM /Online /Cleanup-Image /RestoreHealthdepuis une invite de commandes administrateur, utiles si les journaux WMI signalent des erreurs de chargement de fournisseurs. - Toucher au référentiel WMI en dernier recours seulement. La documentation Microsoft est explicite : en aucun cas la suppression du référentiel ne doit être la première étape, car elle peut endommager le système ou les applications installées. Sur un poste de production, cette opération se fait après sauvegarde et, idéalement, avec le support.
À noter pour les procédures anciennes qui circulent encore : l’utilitaire WMI Diagnosis Utility, WMIDiag.exe, n’est plus pris en charge depuis Windows 8 et Windows Server 2012. Les journaux WMI classiques ont disparu au profit du suivi d’événements pour Windows.
Pilotes et utilitaires constructeurs
Une part des fournisseurs WMI installés sur un poste ne vient pas de Windows mais des programmes livrés avec le matériel : utilitaires de surveillance de température, outils de gestion de batterie, agents de mise à jour de pilotes. Ces fournisseurs s’enregistrent comme les autres et se retrouvent hébergés dans un processus WmiPrvSE.exe.
La conséquence pratique pour le dépannage : si l’étape 2 désigne une DLL qui ne se trouve pas dans le dossier wbem de Windows, cliquez sur son chemin et remontez au programme propriétaire. Trois vérifications dans cet ordre donnent le plus souvent le résultat. Ouvrez la liste des applications installées et repérez l’utilitaire concerné. Contrôlez ensuite s’il existe une mise à jour du pilote ou de l’outil chez le fabricant. Désinstallez enfin le module de surveillance s’il n’est pas nécessaire, un pilote de périphérique fonctionnant très bien sans sa couche de supervision.
Le même raisonnement vaut pour les agents d’inventaire en entreprise : réduire la fréquence d’interrogation dans la console de l’outil règle la consommation sans priver l’administrateur de visibilité.
Le cas particulier du quota dépassé
Si le journal des applications enregistre l’événement 5612, le problème n’est plus un simple pic de charge : un processus WmiPrvSE.exe a dépassé un seuil de ressources et le service WMI l’a arrêté volontairement. Ces seuils sont définis par hôte et pour l’ensemble des hôtes à travers des propriétés comme HandlesPerHost, MemoryPerHost, MemoryAllHosts, ProcessLimitAllHosts et ThreadsPerHost, stockées dans la classe WMI __ProviderHostQuotaConfiguration.
L’événement 5612 est le message le plus utile du lot, car il nomme la ressource concernée, le quota fixé et la valeur atteinte, et il liste les fournisseurs hébergés dans le processus arrêté. Le réflexe consiste à croiser cette liste sur plusieurs occurrences pour trouver le fournisseur commun, puis à reprendre l’analyse des requêtes entrantes. Relever le quota sans avoir identifié le coupable ne fait que décaler le moment du plantage.
Quand cela ne vient pas de WMI
Une charge processeur permanente attribuée à un autre exécutable mérite un autre article : l’hôte de fournisseur WMI n’est responsable que des requêtes de gestion. Si la ligne qui monte est svchost.exe, Runtime Broker ou WUDFHost.exe, la chaîne de diagnostic n’est pas la même. Un nom de processus légèrement différent doit aussi alerter : le fichier légitime se trouve dans C:\Windows\System32\wbem, et une copie ailleurs sur le disque n’est pas WmiPrvSE.exe.
Questions fréquentes
Peut-on désactiver le service WMI ?
Techniquement oui, en pratique non. Console de gestion, stratégies de groupe, outils de déploiement et utilitaires constructeurs passent par WMI. Désactiver Winmgmt casse ces fonctions sans traiter la requête responsable.
Pourquoi plusieurs WmiPrvSE.exe apparaissent en même temps ?
Parce que les fournisseurs sont regroupés par niveau de privilège. Chaque hôte partagé tourne sous un compte système, et un fournisseur configuré en hôte séparé obtient son propre processus. La documentation Win32 décrit explicitement ce fonctionnement.
Faut-il tuer le processus dans le Gestionnaire des tâches ?
Arrêter l’instance fautive libère le processeur et le service recrée un hôte à la requête suivante. C’est un dépannage d’urgence, pas une correction : la charge revient si le client renvoie les mêmes requêtes.
Est-ce que WmiPrvSE.exe peut être un logiciel malveillant ?
Le fichier signé livré avec Windows réside dans le dossier wbem de System32. Un exécutable de même nom situé dans un autre dossier, ou non signé, doit être analysé. À l’inverse, WMI est aussi utilisé légitimement par des scripts d’administration, donc l’activité seule ne prouve rien.
Combien de temps une charge élevée est-elle acceptable ?
Microsoft ne publie pas de seuil chiffré. Le critère de sa procédure est le motif dans le temps : un pic corrélé à une action connue est normal, une charge continue justifie le diagnostic complet.
Sources
Photo d’en-tête : capture de Microsoft Windows par PantheraLeo1359531, domaine public, via Wikimedia Commons. Capture d’un Gestionnaire des tâches Windows en allemand, illustrative.
Microsoft Learn, Résoudre les problèmes d’utilisation élevée du processeur WMI ·
Microsoft Learn, Résoudre les problèmes de dépassement de quota WmiPrvse.exe ·
Microsoft Learn, Provider Hosting and Security ·
Microsoft Learn, Dépannage WMI ·
Microsoft Learn, Suivi de l’activité WMI ·
Microsoft Sysinternals, Process Explorer
Michel, dirigeant d’une PME informatique et formateur, expert en logiciels professionnels tels que CRM et ERP. Sa connaissance approfondie des outils de gestion d’entreprise lui permettant de conseiller et former efficacement d’autres sociétés à leur utilisation.
