Vérifier le fonctionnement de WMI

Version imprimable

Bonjour,

Je me retrouve aujourd'hui confronté à un problème avec WMI :
Sur un ordinateur XP SP2, une requête WMI (dans un script vbs en local) s'est bloquée (script toujours en fonctionnement, mais ne faisant plus rien) alors qu'aucune erreur n'est apparue lors de la création de l'objet WMI, ni lors de la création de la la collection d'objet WMI, ni même lors de l'exécution du programme.

Y aurait-il une possibilité de vérifier que WMI fonctionne bien, en général ou dans l'espace de nom sélectionné, avant de créer les objets et de faire des requêtes?

Les objets que je récupérais dans l'espace de nom "\root\cimv2" sont : Win32_OperatingSystem, Win32_Printer et Win32_PrinterDriver.

Code :
Code:

1 2 3 4 5 strComputer = "." Set objWMIService = GetObject("winmgmts:{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2") Set colOperatingSystems = objWMIService.ExecQuery ("Select * from Win32_OperatingSystem") Set colInstalledPrinters = objWMIService.ExecQuery("Select * from Win32_Printer") Set colPrinterDrivers = objWMIService.ExecQuery ("Select * from Win32_PrinterDriver")
Ps : Le code fonctionne parfaitement sur une centaine d'autres machines en XP SP2 et SP1.

Merci de votre aide.

Après avoir fait quelques tests, je suis toujours aussi perdu :
Pour voir où le script bloquait exactement, j'ai lancé ce script sur l'ordinateur en question :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 strComputer = "." Set objWMIService = GetObject("winmgmts:{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2") If Err.Number <> 0 Then WScript.Echo strComputer & " : ERROR" Else WScript.Echo strComputer & " : SUCCESS" Set objWMISettings = objWMIService.Get("Win32_WMISetting=@") WScript.Echo objWMISettings.BuildVersion WScript.Echo "S" Set colOperatingSystems = objWMIService.ExecQuery ("Select * from Win32_OperatingSystem") WScript.Echo "ST" WScript.Echo colOperatingSystems.Count For Each objOperatingSystem in colOperatingSystems WScript.Echo "STO" strOSVersion = objOperatingSystem.Version WScript.Echo "STOP" WScript.Echo strOSVersion WScript.Echo "STOPP" Next End If
Le premier message est bien ". : SUCCESS", donc, le script se connecte bien à WMI.
Le 2ème message est "2600.0000", ce qui correspond bien à la version de WMI de ce poste.
3e message : "S", 4e : "ST", bon ça normal...

Mais après ça plus rien. Le script reste bloqué sur la ligne du Count.
Si je supprime cette ligne, le même blocage se fait sur cette ligne :

Citation:

strOSVersion = objOperatingSystem.Version

Je ne sais pas quoi faire pour intercepter cela, car il n'y a pas d'erreur, et que je ne vois pas quoi tester au préalable pour empêcher de rentrer dans ce blocage... :cry:

Si quelqu'un a une idée, ou a déjà rencontré ce problème, merci de votre aide.

02/12/2008, 10h36
ced600

va sur le site msdn de microsoft et essayes de récupérer les runtimes, les interpréteurs, tout ce qui est nécessaire à la gestion du vbs, pour réinstaller le tout sur ta machine qui bug.
02/12/2008, 11h16
pitchalov

Merci de ton aide ced600, mais en fait mon problème va un peu plus loin que ça.
Mon script de récupération d'informations avec WMI est actuellement en test sur un parc d'une centaine de postes, et ce problème apparaît sur un poste.
Mais, par la suite, il va être déployé sur plusieurs milliers de postes et ce problème, s'il est apparu ici, peut être récurrent et se retrouver sur d'autres.

Je me dit bien que ces problèmes peuvent être réparés en réinstallant des versions, mais je ne peux pas savoir à l'avance quels postes peuvent être concernés.

Le but serait donc, si c'est possible, de vérifier le fonctionnement avant de lancer les requêtes qui pourraient se bloquer, et de ne pas les lancer si le problème est présent, car il ne faudrait pas qu'il y ait de script bloqué quelque part...

Quelqu'un aurait une idée?
Merci.
02/12/2008, 13h45
ced600

Ok je vois.

Mais si les composants sont défectueux suites à une mauvaise installation, ou je ne sais pas, une polution par des backdoors, virus, trojan, il semble difficile de pouvoir se fier à des objets com de diagnostique qui utilise ces composants.

Ce serait comme se fier à un outil, qui ne tourne que sous windows, et qui diagnostique le windows défectueux :?

Bref il est nécessaire à mon avis de passer par des solutions autres que les objets com, que les objets WMI, et même que des scripts.

Et puis pourras tu tout détecter ? Si un employé de la société s'amuse à éteindre brutalement son PC chaque soir, à un moment il arrivera à détériorer le SE tel que tes scripts planteront et que tes outils de diagnostique de détecteront pas.

Et puis je ne connais pas beaucoup d'outil capable de détecter leur propre malfonctionnement. Je ne suis pas sur qu'il y ait de tel possibilité avec le WMI.

De toute manière si des composants Windows détectent des anomalies, ils les écrivent dans le journal des événements windows. Peut être devrais tu le vérifier sur ta machine buggé, pour voir si WMI y écrit des alertes, que tu pourrais ensuite rechercher par le script avant de lancer les commandes.

Ou tu peux faire 2 scripts, un second qui surveille le premier et essaye de détecter son plantage et le kill en cas de plantage. Mais bon utiliser du WMI pour le faire serait risqué si tu met en cause le WMI, dans un autre langage alors ? en .Net ? Mais alors il faudrait vérifier que .Net n'est pas des problèmes équivalent sur le poste.

Bref, c'est pas simple, et pas forcément efficace.

A mon avis, en général, tout problème qui pourrait survenir à cause d'une détérioration de Windows par d'autres entités que celle qui vient de planter (dans ton cas ton script) ne doit pas être anticiper en soit par l'entité en elle-même. Tout ce que tu peux réellement faire c'est, en cas de plantage, ton application endommage le moins possible le SE, les ressources utilisées et si possible elle-même.

Ou alors tu redeveloppes ton API qui se bases sur les mêmes couches basse du SE pour faire ce que tu souhaites.
02/12/2008, 14h36
pitchalov

Merci de ta réponse, bien plus complète que ce que j'avais espéré!

Bon ben comme je me doutais, je vois qu'il y a pas trop moyen de gérer mon problème en interne du script, à moins de checker au préalable les bons fichiers de log, ou les bons eventlog, mais ça me parait pas bien fiable...

Effectivement, si WMI est défectueux, pas moyen de vérifier l'état de mon processus et de l'arrêter...

A la limite, vu que c'est un script qui dure 3 sec lancé au login, et que je voulais une vision globale, ça ne m'embêtait pas trop de louper entre 10 et 100 postes pouvant statistiquement se bloquer, et y avait pas trop de chance pour que l'utilisateur éteigne l'ordi en cours d'exécution du script.

C'est donc résolu, avec une réponse à non : il faut utiliser une autre technologie.
02/12/2008, 19h14
ced600

Citation:

C'est donc résolu, avec une réponse à non : il faut utiliser une autre technologie.

Et encore !
J'ai fait un peu de supervision, et j'ai aidé à la mise en place d'un outil de supervision qui fonctionne sur linux, pour des serveurs unix et linux, et et windows.
L'idée est simple, le gros serveur de supervision, sur un serveur linux, et des petits modules remontant au serveur des infos sur les serveurs à superviser.
Le module pour serveur windows utilise le WMI.

Juste pour dire que pour echapper au WMI ou autre API windows pour faire du diagnostique c quasiment infaisable.
D'ailleurs microsoft empêche un max cela.

Citation:

Merci de ta réponse, bien plus complète que ce que j'avais espéré!

C'est que je réfléchi en même temps que j'écrit la réponse, alors ce n'est pas toujours très synthétique ;)