Discussion :

[omen999]

Bonjour,

S'il est très simple de récupérer le ProcessID d'un programme lancé depuis le script
avec la méthode Exec puisque c'est une propriété de l'objet WshScriptExec renvoyé
il est en revanche beaucoup plus pénible de récupérer le propre PID du script actif.

J'ai sélectionné sur le net ce qui me parait être la technique la plus fiable et la plus concise
pour y parvenir :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
Function GetPID()
  Set oChildPr=GetObject("winmgmts:Win32_process.Handle='" & CreateObject("WScript.Shell").Exec("rundll32 kernel32,Sleep").ProcessId & "'")
  GetPID = oChildPr.ParentProcessId
  oChildPr.Terminate	
End Function

Toute observation est la bienvenue avant de placer ce code dans la FAQ

[Patrick22]

Bonjour,

Ce topic date un peu. Il n'est peut-être plus actif.
Bon... Au cas où...

Pour un script en développement, j'ai recherché sur le net comment récupérer le PID du script en exécution et j'ai aussi trouvé cette solution parmi d'autres comme toi.
Il y a celle-ci entre autre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
mstrCmd = "Powershell -command exit (gwmi Win32_Process -Filter \""processid='$PID'\"").parentprocessid"
ProcessId = WshShell.Run(mstrCmd, 0, True)

Je comprends ce que fait cette dernière solution. Malheureusement, elle est plus longue à s'exécuter que la précédente.
Comme la 1ère solution, elle me semble "propre".

Je préfèrerais la 1ère solution si je pouvais comprendre ceci : Que fait "rundll32 kernel32,Sleep" ?
Est-ce une action à risque ? Un autre pgm peut-il le faire en même temps (dans l'absolu bien sûr) et créer une confusion ?

[omen999]

bonjour,

Il n'est peut-être plus actif

actif c'est beaucoup dire...mais c'est un item de la FAQ donc c'est normal

l'astuce de ce code consiste à récupérer l'objet WMI Win32_process du processus enfant créé par le script
au moyen de la méthode Exec de l'objet WshShell, lequel processus est identifié par sa propriété ProcessId
ce processus enfant doit donc être créé très rapidement et détruit aussi vite, le tout très simplement
c'est ici le rôle de "rundll32 kernel32,Sleep"

rundll32 est un très ancien utilitaire présent dans toutes les versions de Windows qui permet d'appeler une fonction "quelconque"
d'une bibliothèque dynamique, en l'occurence la fonction Sleep de la bibliothèque kernel32.dll
en réalité la fonction appelée doit respecter une syntaxe précise pour être appelée correctement par rundll32 mais il est quelquefois
possible de tricher quand l'état final de la pile du processus n'a pas d'importance comme dans ce cas puisqu'il va être immédiatement détruit.
pour creuser le sujet, un article de l'inénarrable Raymond

Est-ce une action à risque ? Un autre pgm peut-il le faire en même temps (dans l'absolu bien sûr) et créer une confusion ?

sur un système windows NT et supérieur aucun risque

[Patrick22]

Bonjour,

Merci pour ta réponse éclairante.
(Désolé d'avoir tardé un peu à consulter mes messages, un certain désintérêt s'est installé suite au peu de retour ou au ton de certains retours sur mes quelques interventions)

J'adopte la solution que tu as retenue pour connaître le PID du script actif.

L'article de l'inénarrable Raymond, lui aussi clair et concis, est bien intéressant.
Dommage que Microsoft n'est pas conservé active la page citée, ou bien créé une redirection sur son nouvel emplacement car elle doit bien encore existée :
The function signature required for functions called by rundll32.exe is documented in this Knowledge Base article.
J'ai fait une recherche dans leur base de connaissance sur "rundll32exe", pour voir, mais bien sûr les liens obtenus ne concernent que des informations secondaires.
Le sujet n'est pas asez d'actualité pour que je fouille le net, c'était juste pour "encadrer" la lecture de l'article de Raymond.