Connaitre le chemin de l'application qui lance un processus.

Question

Bonjour,

J'ai encore besoin de vos lumières 

Quelqu'un connaitrait-il par le plus grand des hasards le moyen de récupérer le chemin complet d'une application qui lance mon application. Sachant que l'application "lanceuse" n'est pas conçu par mes soins et qu'elle ne transmet aucun argument. et que j'ignore la méthode qu'elle utilise pour lancer mon application (shellexecute ou non).

Je sais pas si c'est très clair donc je vais tenter un exemple : le chemin de mon appli est "c:	est.exe" je lance une invite de commande et je tape "test.exe" à l'invite "c:\>" mon appli se lance et j'aimerais qu'elle me dise, c'est "c:\windows\system32\cmd.exe" qui m'a lancé 

Je voudrais savoir s'il il existe une méthode en VB.Net ou un API permettant de faire ça ? Ça me parait pourtant basique mais je trouve rien et je ne sais pas trop comment formuler cette recherche sur le net, que ce soit en français ou en anglais...

Voila, merci bien, et si vous êtes en vacance alors bonne vacance et allez à la plage et sortez au lieu de trainer devant votre PC, allé, Zou ! 


Si le déboguage est l'art d'enlever les bogues, la programmation doit être l'art de les créer.

ucfoutu · Answer

Bonjour, Mayzz

Moi, je suis toujours en vacances (je partage d'ailleurs en ce moment mon temps entre PC et pêche)


J'ai lu et relu et je suis à court d'idées vraiment intéressantes pour répondre valablement à ce cas de figure.
La seule que je "vois" est lourde et scabreuse et consiste à utiliser un timer pour :
dresser dans un dictionnaire ou dans une collection la liste des processus et faire des comparaisons
Lourd !



____________________
Utiliser le bouton "REPONSE ACCEPTEE" sur une réponse exacte facilite les recherches ultérieures d'autres forumeurs. PENSEZ-Y SVP

ucfoutu · Answer

Essaye toutefois, de ton côté, d'utiliser la fonction GetWindowThreadProcessId de la librairie user32 de l'API de windows, dont je vois qu'elle retourne ceci :
The GetWindowThreadProcessId function retrieves the identifier of the thread that created the specified window and, optionally, the identifier of the process that created the window.


Ce que tu devrais alors tenter :
1) - un timer pour, enumérant les processus, découvrir si celui que tu cherches est en cours
2) - en déterminer alors le handle de sa fenêtre
3) - déterminer l'ID du processus qui l'a ouverte (c'est là, que la fonction GetWindowThreadProcessId devrait peut-être être utilisée)
4) A partir de cet ID, trouver le hwnd correspondant, etc...

Tu tentes seul ou je tente aussi ?


____________________
Utiliser le bouton "REPONSE ACCEPTEE" sur une réponse exacte facilite les recherches ultérieures d'autres forumeurs. PENSEZ-Y SVP

Mayzz · Answer

Salut ucfoutu et merci pour tes réponses. Désolé pour l'absence temporaire j'étais invité à un repas chez les beaux parent alors... 

Pour la petit histoire le problème est que je ne connais pas le nom du processus qui lancera l'application. Pour être plus clair mon programme en visual basic sera empaqueté via un cab exécutable IExpress (je sais qu'il existe d'autres solutions de déploiement mais c'est un cas de figure spécial ou seul IExpress convient et puis ce n'est pas vraiment le sujet épiloguer la dessus sera trop long). Donc IExpress crée une archive autoextractible exécutable (.exe) celle-ci se lance, extrait mon application ainsi que les assemblies dépendantes dans un dossier temporaire et lance l'exécution de mon programme. Ce que j'aurais donc besoin de connaitre c'est le chemin de l'application IExpress, mais l'utilisateur peut très bien renommer celle-ci à sa guise d&#8217;où le problème.

Si le déboguage est l'art d'enlever les bogues, la programmation doit être l'art de les créer.

ucfoutu · Answer

Re,

C'est bien ce que j'avais compris.
Tu sais qu'une application "application.exe" a été lancée et tu voudrais tenter de savoir par quoi elle l'a été.
Mon second message a été rédigé en partant précisément de cette hypothèse.
Ses points 1) et 2) sont simples.
Etape suivante, donc : tenter maintenant de mettre en oeuvre le point 3. C'est là que la difficulté commence.

____________________
Utiliser le bouton "REPONSE ACCEPTEE" sur une réponse exacte facilite les recherches ultérieures d'autres forumeurs. PENSEZ-Y SVP

BruNews · Answer

Salut,
GetWindowThreadProcessId n'est d'aucune utilité dans le cas présent.

Utiliser ZwQueryInformationProcess()
en retour si tout va bien:
Lire le processID dans UniqueProcessId de la structure PROCESS_BASIC_INFORMATION.

ciao...
BruNews, MVP VC++

ucfoutu · Answer

Il semble par contre facile de déterminer le chemin complet du dossier où est- placé le Launcher.
Le Curdir reste celui de l'exe premier.
Une petite expérience :
Un répertoire nommé "quiappelle" avec deux sous-répertoires, "appelé" et "appelant".
Dans le dossier "appelé" :
Private Sub Form_Load()
  MsgBox CurDir
End Sub

=================== >>> en faire  un exe nommé appelé.exe 

Dans le dossier "appelant"
Private Sub Form_Activate()
  Shell "D:\quiappelle\appelé\appelé.exe"
  End
End Sub
 =====================>>> en faire un exe nommé launcher.exe

Et on voit la différence, serlon qu'est lancé Launcher.exe ou qu'est lancé appelé.exe directement


____________________
Utiliser le bouton "REPONSE ACCEPTEE" sur une réponse exacte facilite les recherches ultérieures d'autres forumeurs. PENSEZ-Y SVP

Mayzz · Answer

En fait j'ai pas bien saisi 

Pour l'étape 1 lors ce que tu parles du process que je recherche, c'est le process de mon archive IExpress ou celui de mon application ? Car si c'est celui de mon appli pas besoin de timer .Net donne les informations sur le process en cours. Par contre si tu parles du process de l'archive exécutable la c'est plus dur car je ne connaitrais pas le nom de fichier donc je ne connaitrais pas le nom du processus.

Etape 2 retrouver le handle de la fenêtre idem ici je suppose que tu ne parles pas du handle de ma fenêtre car un simple me.hwnd suffirait sinon. Donc la c'est encore un problème car l'archive autoextractible n'a pas de fenêtre mais en revanche son processus reste ouvert pour attendre la fin du processus de mon application. Mon application terminé elle supprime les fichiers extraits.

Donc pour résumé si je comprends bien l'idée il faudrait que je trouve un moyen de trouver quel processus est parent du mien, puis depuis ce processus retrouver les informations menant au chemin du fichier ?

Merci =)

Si le déboguage est l'art d'enlever les bogues, la programmation doit être l'art de les créer.

ucfoutu · Answer

L'idée de départ était bien de partir de l'appli appelée et non de l'appelante.
Le timer n'est nécessaire, dans un tel cas, que si tyu fais ton enquête depuis ailleurs que ton appli appelée. Il ne l'est pas si cette enquête est incluse dans ton appli appelée.

L'idée est ensuite (mais tout cela parait bien complexe) de "remonter" au processus appelant.

Lis mon dernier message : il est par contre facile, en l'incluant dans l'appli appelée, de déterminer le chemin du dossier où se trouve l'appelant.

____________________
Utiliser le bouton "REPONSE ACCEPTEE" sur une réponse exacte facilite les recherches ultérieures d'autres forumeurs. PENSEZ-Y SVP

Mayzz · Answer

Ah oui, sinon j'ai bien essayé une autre méthode mais en vain, ou alors je m'y suis mal pris. En fait lors de la création de l'archive on peut spécifier l'application qui sera exécuté. Je me suis arrangé pour trouver une solution afin de pouvoir passer un paramètre en ligne de commande.

J'ai donc pu définir une variable de teste et mon application reçois bien ce paramètre en ligne de commande. Seulement voila les %L et autres %1 n'ont pas l'air de fonctionner et je ne trouve pas de variable d'environnement capable d'envoyer le chemin de l'autoextractible. Dommage donc piste à abandonner je pense...

Si le déboguage est l'art d'enlever les bogues, la programmation doit être l'art de les créer.

Mayzz · Answer

En effet je n'avais pas lu ton dernier message, ce serait pile poile ce qu'il me faut, retrouver juste le répertoire me suffirait. Mais le souci c'est que je viens de tester en empaquetant un exécutable bidon via iexpress et lors ce que j'exécute le fichier depuis mon bureau CurDir renvoi le chemin du fichier temporaire...

c:\User\Mayzz\AppData\Local\Temp\IXP001.TMP

C'est en tous cas une très bonne solution mais qui ne s'applique malheureusement pas à mon cas. Surement à cause de la méthode de lancement.

Si le déboguage est l'art d'enlever les bogues, la programmation doit être l'art de les créer.

ucfoutu · Answer

Et une solution assez tortueuse existe alors (à partir du chemin du dossier dans lequel est l'appelant):
Lister les exécutables présents dans ce dossier
Pour chacun : voir s'il est dans le résultat d'une énumération des processus

S'il y est, toutefois, c'est peut-être (mais pas assurément lui). Tout serait "par-terre si, par malheur et à la fois : ce dossier comporterait plusieurs exécutables et que l'un (autre que celui cherché) d'entre eux serait également en cours 


____________________
Utiliser le bouton "REPONSE ACCEPTEE" sur une réponse exacte facilite les recherches ultérieures d'autres forumeurs. PENSEZ-Y SVP

Mayzz · Answer

bureau CurDir renvoi le chemin du fichier temporaire... 


Je voulais dire du dossier pardon, mais tu m'auras compris je pense  

Si le déboguage est l'art d'enlever les bogues, la programmation doit être l'art de les créer.

ucfoutu · Answer

Ouais...
1) ce sont bien les exécutables, que tu lances ?
2) de toutes manières, tu es "feinté" 
- si, pour une raison, délibérée ou autre, le code de l'appelant change le curdir par un chdir avant l'appel du Shell ou de quoi que ce soit d'auutre appelant appelé.exe
- si l'appel de appelé.exe se fait depuis un .bat (donc depuis DOS), préalablement généré par code.
- si une conjugaison des points 1) et 2) est faite (pire encore)

Là, j'abandonne car ton affaire me parait bien compromise !

____________________
Utiliser le bouton "REPONSE ACCEPTEE" sur une réponse exacte facilite les recherches ultérieures d'autres forumeurs. PENSEZ-Y SVP

banana32 · Answer

Salut,

Essaye de scruter les événements de création d'instance par wmi ?
Voici un exemple avec calc.exe (calculatrice) qu'il faut lancer pour observer le résultat.
Notes :
1 - la requête peut être changée à loisir avec LIKE par exemple si tu ne connais pas exactement le nom de l'exécutable. Voir requêtes SQL.
2 - Référencer System.Management
    Dim watcher As ManagementEventWatcher

    Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
        Dim query As WqlEventQuery = New WqlEventQuery("SELECT * FROM __InstanceCreationEvent " & _
            "WITHIN 1 " & _
            "WHERE TargetInstance " & _
            "ISA 'Win32_Process' AND TargetInstance.Name = 'calc.exe'")
        watcher = New ManagementEventWatcher(query)
        AddHandler watcher.EventArrived, AddressOf HandleEvent
        watcher.Start()
    End Sub

    Public Sub HandleEvent(ByVal sender As Object, ByVal e As EventArrivedEventArgs)
        Dim ev As ManagementBaseObject = e.NewEvent
        Debug.Print(ev.GetText(TextFormat.Mof))
    End Sub
Bonne après-midi.

Mayzz · Answer

ucfoutu> En effet je crois bien que c'est cuit, il doit bien exister des solutions mais je ne veux pas m'attarder la dessus plus que ça. Merci grandement à toi pour ton aide et le temps que tu m'a accordé 

banana32> Cela fonctionne bien qui plus est WMI donne une pile d'infos  mais je cherches à surveiller un lanceur. Hors ici, l'application que je dois surveillé est déjà lancée. Ce code ne peut donc pas convenir non plus. Mais je te remercie également.

Je vais rester comme je suis actuellement tempi. Des fois à vouloir faire trop bien on ne fait plus rien du tout et on perd son temps mais bon c'est comme ça qu'on apprend. Merci a vous et bonne vacances (pour ceux qui y sont).

A bientôt les vbfrançiens (et vbfrançiennes) 

Si le déboguage est l'art d'enlever les bogues, la programmation doit être l'art de les créer.

banana32 · Answer

Re,
Hors ici, l'application que je dois surveillé est déjà lancée.
Dans ce cas il te suffit de remplacer __InstanceCreationEvent par __InstanceOperationEvent sans rien changer au reste du code.
Ainsi, au moindre "mouvement du process" tu saura récupérer les infos utiles.
N'oublie pas ensuite de faire un removehandler.
Bonne soirée.

Mayzz · Answer

Bien vu =)

Mais la encore ça pose problème. Comme je l'ai dit le launcher peut avoir été renommé je ne peux donc compter sur le nom de celui-ci, il faudrait trouver un autre moyen d'identification pour la clause where. Mais de toute façon c'est inutile car le launcher ne bouge pas d'un poil après avoir exécuté mon application. Il attend patiemment la fin du processus pour pouvoir supprimer les fichiers temporaires. J'ai testé avec un nom fixe.

Voila, merci quand même 


Si le déboguage est l'art d'enlever les bogues, la programmation doit être l'art de les créer.

Connaitre le chemin de l'application qui lance un processus.

17 réponses

Votre réponse