Discussion :

[hiko-seijuro]

Bonjour

est ce qu'il est possible de récupérer le nom de l'executable d'un processus (du chemin si possible même) et si oui comment ?

merci de votre aide

[Médinoc]

GetModuleFileName(NULL) pour le processus actif, sinon il faut utiliser des fonctions plus compliquées, comme CreateToolHelp32Snapshot() et Process32First()...

Ah, et tu as aussi droit à GetWindowModuleFileName(), il me semble...

[hiko-seijuro]

en fiat je connais le nom du processus via le gestionnaire de taches (en fait je souhaite ciblé une appli qui block le processeur c pour ca)
c'est toujours le même truc a utiliser ?

[Crisanar]

Tu voudrais en fait connaître une application bloquée dans une boucle infinie, c'est ça?!

[hiko-seijuro]

je voudrais connaitre son chemin pour trouver l'exécutable qui est en cause et pouvoir ainsi le supprimer s'il est inutile
(j' ai deja tester l'antivirus mais il ne repere rien )

[Crisanar]

Et l'utilisation de GetModuleHandle pour récupérer le handle de ton processus + GetModuleFileName pour récupérer son chemin ne fonctionne pas?
Ceci dit, je ne suis pas bien sur de comprendre ta logique : si tu veux supprimer le fichier executable alors qu'il est lancé ça m'étonnerait que tu y arrives, et quand bien même tu arriverais à supprimer le fichier, ça n'arreterait pas le programme!

[hiko-seijuro]

en fait j'ai un programme qui prend le processeur
j'arrive a tuer le processus mais il se relance apres !!
si j'arrive a detruire le fichier executable source de ce processus je l'empecherai de se relancer
enfin je pense

[Crisanar]

Ok oui dans ce cas d'accord. Mais s'il se relance directement c'est qu'un autre programme le lance et il faudra aussi tuer ce programme (du moins le temps de supprimer ton 'virus')
D'un autre coté, pourquoi veux-tu faire ça par programmation?
Avec des outils comme ProcessXP et/ou en mode sans echec, il y a moyen de faire ça 'facilement' à la main.

[hiko-seijuro]

euh bah je me suis dit plutot que de me laisser emmerder par une saloperie de ce style autant m'en servir pour apprendre quelquechose

[David.Schris]

Tu peux énumérer les processus puis, pour chacun d'eux, énumérer leurs modules.
Le premier module énuméré pour chaque processus correspondra à l'exécutable, les autres aux DLLs qu'il utilise.

Pour obtenir les infos de certains processus il faudra activer le privilège "SeDebugPrivilege" avant les énumérations.

[Crisanar]

Le premier module énuméré pour chaque processus correspondra à l'exécutable, les autres aux DLLs qu'il utilise.

Tu es certain de celà? Pour la majorité des cas je pense que c'est vrai, mais j'ai en tête d'avoir déja rencontré certaines particularités où le premier module énuméré n'était pas l'executable.

[David.Schris]

Tu es certain de celà?

Non, pas du tout (mais je nai jamais rencontré le cas contraire).

Pour la majorité des cas je pense que c'est vrai, mais j'ai en tête d'avoir déja rencontré certaines particularités où le premier module énuméré n'était pas l'executable.

Si tu pouvais donner plus de précisions sur ces particularités...
Et, dans ce cas, comment ferais-tu pour ne pas avoir de problème ?

[Edit 1] : au passage, signales à Paul DiLascia qu'il a tort en écrivant "The first entry is always the main module" dans http://msdn.microsoft.com/msdnmag/issues/02/07/CQA/
[Edit 2] : il faudrait aussi le signaler aux auteurs de http://support.microsoft.com/kb/q175030/ qui écrivent "the first module in the process is going to be the executable of the process"

[Crisanar]

Toutes mes excuses, je pense que c'est moi qui ai mal compris
J'avais développé un petit programme qui analysait la mémoire d'un processus, ainsi que différentes informations dont les modules chargés.
Et il arrivait que certaines dll soient mappées à une adresse inférieure à celle du module correspondant à l'executable. Mais il est vrai que les modules retournés par Module32First et Module32Next n'apparaissent pas dans l'ordre où ils sont mappés en mémoire et qu'il est donc fort possible (voire certain mais je préfere toujours prendre des pincettes ) que le premier module retourné soit toujours celui correspondant à l'executable.
Si maintenant tu me dis (ou que les personnes que tu as citées) que le module qui est mappé à l'adresse la plus basse est toujours celui correspondant à l'executable, il est temps que je revoie l'algo de tri de mon programme car avec 2-3 processus que je viens de tester ce n'est pas le cas!

[David.Schris]

Si maintenant tu me dis [...] que le module qui est mappé à l'adresse la plus basse est toujours celui correspondant à l'executable

Stop !
Une règle à respecter : ne jamais déformer mes propos (ni ceux des autres d'ailleurs).
Je n'ai jamais parlé d'adresse(s). J'ai seulement parlé du premier résultat renvoyé par EnumProcessModules() et, sauf erreur de lecture de ma part, la partie qui lui est consacrée dans le SDK ne précise pas dans quel ordre les modules sont énumérés.

avec 2-3 processus que je viens de tester ce n'est pas le cas!

Une démonstration (pour ne pas parler de preuve) serait bienvenue.
C'est d'ailleurs ce que je te demandais dans mon précédent message ("Si tu pouvais donner plus de précisions [...]").
Que tu sois en face d'un cas où ce que l'on peut lire dans MSDN (et ailleurs) ne soit pas toujours exact est possible.
Dans ce genre de cas, il peut être profitable à tous que tu décrives ces cas avec précision (Quels processus ? Dans quelles circonstances ? Comment reproduire le comportement que tu décris ? etc).
Attention : je ne suis pas en train de dire que tu racontes n'importe quoi. Je suis simplement en train d'essayer d'en apprendre plus d'une personne qui, semble-t-il, en sait plus que moi sur un sujet (ce qui n'est pas difficile).
C'est donc avec impatience que j'attends tes instructions pour reproduire un cas où le premier module énuméré par EnumProcessModules() ne correspond pas à l'exécutable.
Si, en plus, tu pouvais nous dire ce que donnent les autres méthodes d'énumération de processus dans le cas particulier que tu cites, ce serait le bonheur.

[Crisanar]

Salut David.Schris
Je dois t'avouer une chose, ce sujet m'intéresse fortement mais je suis pris par le temps et suis donc contraint de lire en vitesse parfois au détriment de la bonne comprehension de ce qui a été dit. Je te presente donc mes excuses si j'ai déformé tes propos
Tu parlais bien du résultat renvoyé par Module32First et je pensais que tu parlais en terme d'adresse.
Cependant, ce qui me fait tiquer est

the first module in the process is going to be the executable of the process

mais je dois avouer que je n'ai pas pris la peine de lire la phrase dans son contexte et donc de savoir si les auteurs parlent en terme d'adresse.

Sinon si le fait que des modules soient chargés avant le module de l'executable en terme d'adresse t'intéresse, voici mon programme (non terminé mais suffisant pour les tests).
Et voici un screenshot de l'analyse de l'explorer d'XP.

EDIT : effectivement j'avais encore mal lu (et m'étais sans doute mal exprimé aussi). Tu parles toujours de premier module retourné et je parle encore d'adresse. J'ai laissé mon message ci-dessus au cas où mon programme pourrait servir à quelqu'un.
Je me doutais bien que ce n'était pas normal que tu avances quelque chose de discutable, je n'ai encore jamais vu ça

[Aurelien.Regat-Barrel]

en fait j'ai un programme qui prend le processeur
j'arrive a tuer le processus mais il se relance apres !!
si j'arrive a detruire le fichier executable source de ce processus je l'empecherai de se relancer
enfin je pense

c'est quoi comme process ? Il est situé où ? (utilise process explorer)
http://www.sysinternals.com/Utilities/ProcessExplorer.html

[hiko-seijuro]

bah en fair le nom du process c readme mix slow.exe et finalement je viens de reformater la machine ya plus rien (en revanche j'ai reussi a faire ce que j'avais a faire :d

donc merci a tous