LISTER LES HANDLES (FICHIERS, CLÉ DE REGISTRES,...) OUVERTS PAR UN PROGRAMME (NT
cs_eldim
Messages postés956Date d'inscriptionlundi 30 mai 2005StatutMembreDernière intervention21 août 2014
-
30 août 2006 à 15:31
violent_ken
Messages postés1812Date d'inscriptionmardi 31 mai 2005StatutMembreDernière intervention26 octobre 2010
-
20 janv. 2010 à 13:38
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
Sinon CreateFile c'est bien, mais çà ne permet pas de savoir quel process a ouvert le fichier. Pour connaitre le process, pas le choix, faut énumérer les handles ouverts sur le système et déterminer, en fonction du nom du fichier, quel est le handle concerné pour avoir son ProcessId associé.
@+
BruNews
Messages postés21040Date d'inscriptionjeudi 23 janvier 2003StatutModérateurDernière intervention21 août 2019 20 janv. 2010 à 11:02
cs_bidouille007
Messages postés257Date d'inscriptionjeudi 11 septembre 2008StatutMembreDernière intervention22 décembre 20121 20 janv. 2010 à 09:46
BRUNEWS
Je m'étonne car quand je fais la commande que tu dis, je n'ai pas le choix dans les options de la commande :
File.Create(entree, 0, FileOptions.None)
Sinon filecreate n'existe pas, à moins de faire un imports mais lequel ?
D'avance merci
BruNews
Messages postés21040Date d'inscriptionjeudi 23 janvier 2003StatutModérateurDernière intervention21 août 2019 20 janv. 2010 à 09:18
Pas besoin de choses compliquées:
Fais un CreateFile sur le nom de fichier avec 0 en SHARE_MODE et OPEN_EXISING.
Si handle = -1 alors est indisponible.
Sinon CloseHandle et est dispo.
L'API ne déclenche jamais d'erreurs.
violent_ken
Messages postés1812Date d'inscriptionmardi 31 mai 2005StatutMembreDernière intervention26 octobre 20102 20 janv. 2010 à 09:10
bidouille007 => Salut, si c'est bien çà, mais il faut regarder les handles ouverts de type "fichier" (file).
Par contre pour éviter l'erreur "fichier occupé par un autre processus", il faudrait fermer le handle ouvert par le process, mais çà risque d'impacter sur son comportement.
@+
cs_bidouille007
Messages postés257Date d'inscriptionjeudi 11 septembre 2008StatutMembreDernière intervention22 décembre 20121 20 janv. 2010 à 09:00
Bonjour
Je ne noterai pas ce code fort intéressant mais hélas ne semble pas correspondre à ma recherche qui est :
Déterminé quel processus occupe un fichier afin d'éviter l'erreur fichier occupé par un autre processus (peut être un processus système pour une image affiché dans l'explorateur en mode miniature ou pellicule)
Ai je mal utilisé le code ?
Bidouille
violent_ken
Messages postés1812Date d'inscriptionmardi 31 mai 2005StatutMembreDernière intervention26 octobre 20102 30 août 2009 à 02:29
Salut,
j'ai ENFIN réussi à convertir entièrement ce code pour qu'il soit utilisable indifférement sur un OS 32-bits ou 64-bits. Enfin, côté .Net, parce que le driver en 64-bits je l'ai pas, je connais pas assez le C pour m'y attaquer pour le moment.
Bref, j'arrive à faire fonctionner ce code pour qu'il fonctionne parfaitement aussi bien sur 32 que sur 64 bits, mais la récupération du Name des objets de type File ne fonctionne que sur 32-bits (car pas de driver 64-bits).
Comme toutes les structures changent en 64-bits (pointeurs sur 8 octets), le code diffère pas mal (allocations mémoire différentes, utilisation de IntPtr qui implique de ne plus utiliser des offsets en dur...etc).
Pour info, ce code est vraiment très très utile, puisqu'il permet d'obtenir des tonnes d'infos sur le système (possibilité d'énumérer les processus via les handles de csrss, possibilité d'énumérer les jobs en cours après récupération du ObjectTypeNumber de "Job"...).
Bref si quelqu'un veut la version qui fonctionne sur x64, contactez moi (je poste pas là parce que tout le code est refait)
@+
violent_ken
Messages postés1812Date d'inscriptionmardi 31 mai 2005StatutMembreDernière intervention26 octobre 20102 29 mai 2009 à 19:05
Salut,
quelqu'un a des infos pour l'utilisation de GetObjectTypeNumber dans ce code avec un OS 64bits ?
@+
violent_ken
Messages postés1812Date d'inscriptionmardi 31 mai 2005StatutMembreDernière intervention26 octobre 20102 20 févr. 2009 à 14:09
Juste pour rajouter :
- GetThreadId sur Vista uniquement
- GetProcessIdOfThread sur Vista uniquement
- GetProcessId XP SP1 et Vista
@+
violent_ken
Messages postés1812Date d'inscriptionmardi 31 mai 2005StatutMembreDernière intervention26 octobre 20102 20 févr. 2009 à 12:26
Salut,
Je passe juste pour dire qu'il est possible d'utiliser ces fonctions de Kernel32 :
- GetThreadId
- GetProcessIdOfThread
- GetProcessId
pour récupérer les ID et noms des processus/threads ouverts (à mettre dans RetrieveObject avec hHandle en paramètre).
@+ et merci pour l'excellente source.
cs_Willi
Messages postés2375Date d'inscriptionjeudi 12 juillet 2001StatutModérateurDernière intervention15 décembre 201823 27 sept. 2006 à 09:15
Pour le driver j'avoue que je n'ai pas encore le niveau pour me permettre d'en développer un.
Mais oui il m'a été demandé dans un cahier des charges de surveiller quels fichiers sont ouverts par les utilisateurs à partir d'un programme bien précis.
BruNews
Messages postés21040Date d'inscriptionjeudi 23 janvier 2003StatutModérateurDernière intervention21 août 2019 26 sept. 2006 à 18:42
Tu pourrais entrer dans chaque prog par SetWindowHookEx et intercepter ZwCreateFile MAIS...
Ben oui il y a toujours un "mais":
SetWindowHookEx ne fait que du hook user mode, on n'entre pas dans les services systèmes ainsi.
Pour résumer, la seule méthode valable est le hook en driver. A toi de savoir si tu as vraiment besoin de récupérer les actions des composants système.
cs_Willi
Messages postés2375Date d'inscriptionjeudi 12 juillet 2001StatutModérateurDernière intervention15 décembre 201823 26 sept. 2006 à 11:05
Oui j'y ai pensé mais si je pouvais me passer de faire un driver et faire juste un hook sur ZwCreateFile.
ShareVB
Messages postés2676Date d'inscriptionvendredi 28 juin 2002StatutMembreDernière intervention13 janvier 201626 26 sept. 2006 à 09:33
salut,
pour obtenir la liste des ouvertures de fichiers, on peut aussi se mettre directement dans un driver comme Filesystem filter et on récupère tout les évènements fichiers...comme filemon...
ShareVB
cs_Willi
Messages postés2375Date d'inscriptionjeudi 12 juillet 2001StatutModérateurDernière intervention15 décembre 201823 26 sept. 2006 à 09:30
Question bete mais peut-on faire un hook sur une api avec SetWindowsHookEx ?
draluorg
Messages postés625Date d'inscriptionvendredi 23 avril 2004StatutMembreDernière intervention25 novembre 2010 25 sept. 2006 à 19:27
Eh bin disons que si CurrDir + WindowName n'est pas valide dans ce cas le fichier se trouve bien dans CommandLine...
Mais bon tu as raison sur les présupposés, sauf que j'ai juste donne une solution supplementaire pour determiner les fichiers ouverts et j'ai precise dans le cas de notepad par exemple. Apres tous les softs ne sont pas fait pour etre distribues et etre utilises par tous, on code des fois (souvent) des ptits trucs pour soi-meme et donc ce n'est plus faire un soft sur des présupposés, mais se faire un petit outil perso pour un usage precis.
++
BruNews
Messages postés21040Date d'inscriptionjeudi 23 janvier 2003StatutModérateurDernière intervention21 août 2019 25 sept. 2006 à 19:07
OUPS et ultra OUPS, c'est faux aussi pour notepad.
Notepad ne modife pas sa currDir de lui même, c'est qu'il ne met pas le flag OFN_NOCHANGEDIR sur fichier->ouvrir donc sa currDir change, MAIS si on lance notepad avec un fichier sur la ligne de commande alors currDir n'est pas sur le fichier lu.
Comme quoi les présupposés...
BruNews
Messages postés21040Date d'inscriptionjeudi 23 janvier 2003StatutModérateurDernière intervention21 août 2019 25 sept. 2006 à 19:02
Exact pour notepad, je viens de vérifier.
De là à présumer pour les autres... On ne peut pas batir un prog sur des présupposés.
draluorg
Messages postés625Date d'inscriptionvendredi 23 avril 2004StatutMembreDernière intervention25 novembre 2010 25 sept. 2006 à 18:46
Eh vi biensure qu'on peut ouvrir un fichier sans affecter son CurrDir, mais notepad modifie automatiquement son CurrDir en fonction du fichier ouvert, et c'est surement pas le seul...
++
BruNews
Messages postés21040Date d'inscriptionjeudi 23 janvier 2003StatutModérateurDernière intervention21 août 2019 25 sept. 2006 à 18:23
Le "CurrentDirectory" ???
Un prog accède à un fichier nimporte où sans pour cela qu'il soit dans la currDir du prog.
draluorg
Messages postés625Date d'inscriptionvendredi 23 avril 2004StatutMembreDernière intervention25 novembre 2010 25 sept. 2006 à 18:16
lol toute de suite les grands mots!
Bon on va dire: recuperer le CurrentDirectory plus le WindowName et ca te donne le nom du fichier "ouvert"
Ca permet par exemple, a un administrateur de voir d'un coup d'oeil ce qui est en cours sur le systeme.
++
BruNews
Messages postés21040Date d'inscriptionjeudi 23 janvier 2003StatutModérateurDernière intervention21 août 2019 25 sept. 2006 à 18:03
Liste des handles, ok je comprends mais progs comme notepad qui n'ont pas de fichiers ouverts ???
Si vraiment on veut savoir les fichiers accédés, faut hooker ZwCreateFile (possible en vb ?).
draluorg
Messages postés625Date d'inscriptionvendredi 23 avril 2004StatutMembreDernière intervention25 novembre 2010 25 sept. 2006 à 17:52
Eh bin ca sert a le savoir deja :P
++
BruNews
Messages postés21040Date d'inscriptionjeudi 23 janvier 2003StatutModérateurDernière intervention21 août 2019 25 sept. 2006 à 17:41
A quoi servirait de savoir ce qui a été lu dans notepad (ou autre) ???
draluorg
Messages postés625Date d'inscriptionvendredi 23 avril 2004StatutMembreDernière intervention25 novembre 2010 25 sept. 2006 à 17:11
Eh oui, sauf que si on prend l'exemple de Notepad, tu n'aura que le nom du fichier (sans son chemin)
++
cs_Willi
Messages postés2375Date d'inscriptionjeudi 12 juillet 2001StatutModérateurDernière intervention15 décembre 201823 25 sept. 2006 à 17:08
Notepad était un exemple, mais les programmes dont je veux savoir quels fichiers l'utilisateur à ouvert avec fonctionnent comme notepad.
Mais bon comme avec notepad ils fournissent dans le titre de leurs fenêtres le nom du fichier ouvert. GetWindowText fera l'affaire finalement.
draluorg
Messages postés625Date d'inscriptionvendredi 23 avril 2004StatutMembreDernière intervention25 novembre 2010 25 sept. 2006 à 16:59
Salut,
Tu peux toujours recuperer le nom du fichier ouvert par notepad en recuperant son CommandLine ;)
++
cs_Willi
Messages postés2375Date d'inscriptionjeudi 12 juillet 2001StatutModérateurDernière intervention15 décembre 201823 25 sept. 2006 à 14:04
Arf alors sa me fait de meme avec les 3/4 des programmes. Pas de chance.
Merci de l'info.
BruNews
Messages postés21040Date d'inscriptionjeudi 23 janvier 2003StatutModérateurDernière intervention21 août 2019 25 sept. 2006 à 13:59
notepas ne tient pas de handle sur un fichier. Il ouvre, remplit un buffer et referme.
Simple à tester, affiche un fichier dans notepad et va dans dans l'explorateur supprimer ce fichier, tu verras que aucun message d'impossibilité.
cs_Willi
Messages postés2375Date d'inscriptionjeudi 12 juillet 2001StatutModérateurDernière intervention15 décembre 201823 25 sept. 2006 à 12:33
Salut,
Est-ce normal que si j'ouvre dans le bloc-note un fichier .txt je ne retrouve pas dans la liste le nom de ce fichier ?
draluorg
Messages postés625Date d'inscriptionvendredi 23 avril 2004StatutMembreDernière intervention25 novembre 2010 7 sept. 2006 à 12:37
Heyhey ^^
Merci :)
Je regarde ca des que j'ai une minute
++
ShareVB
Messages postés2676Date d'inscriptionvendredi 28 juin 2002StatutMembreDernière intervention13 janvier 201626 7 sept. 2006 à 11:24
draluorg
Messages postés625Date d'inscriptionvendredi 23 avril 2004StatutMembreDernière intervention25 novembre 2010 30 août 2006 à 16:56
Salut ShareVB, salut a tous
Eh y a un petit truc qui m'echape, quelle est la difference entre les fichiers ouvert lister par ce code, et ceux dans la source ou tu ne liste que les fichiers ouverts ?
Sinon c'est cool d'avoir mis le code du driver ^^
Au passage, tu ne connaitrais pas un moyen de lister les drivers en cours sur le systeme ?
Bonne continuation
++
cs_eldim
Messages postés956Date d'inscriptionlundi 30 mai 2005StatutMembreDernière intervention21 août 20141 30 août 2006 à 15:31
Bonjour,
c'est pas mal... (lorsqu'on click sur devenv on se rend tout de suite compte pourkoi le .net est d'une lenteur incroyable)
20 janv. 2010 à 13:38
Pour inclure çà dans du VB.Net faut utiliser le namespace
System.Runtime.InteropServices
et déclarer la fonction comme décrit ici : http://www.pinvoke.net/default.aspx/kernel32/CreateFile.html
Sinon CreateFile c'est bien, mais çà ne permet pas de savoir quel process a ouvert le fichier. Pour connaitre le process, pas le choix, faut énumérer les handles ouverts sur le système et déterminer, en fonction du nom du fichier, quel est le handle concerné pour avoir son ProcessId associé.
@+
20 janv. 2010 à 11:02
http://msdn.microsoft.com/en-us/library/aa363858(VS.85).aspx
20 janv. 2010 à 09:46
Je m'étonne car quand je fais la commande que tu dis, je n'ai pas le choix dans les options de la commande :
File.Create(entree, 0, FileOptions.None)
Sinon filecreate n'existe pas, à moins de faire un imports mais lequel ?
D'avance merci
20 janv. 2010 à 09:18
Fais un CreateFile sur le nom de fichier avec 0 en SHARE_MODE et OPEN_EXISING.
Si handle = -1 alors est indisponible.
Sinon CloseHandle et est dispo.
L'API ne déclenche jamais d'erreurs.
20 janv. 2010 à 09:10
Par contre pour éviter l'erreur "fichier occupé par un autre processus", il faudrait fermer le handle ouvert par le process, mais çà risque d'impacter sur son comportement.
@+
20 janv. 2010 à 09:00
Je ne noterai pas ce code fort intéressant mais hélas ne semble pas correspondre à ma recherche qui est :
Déterminé quel processus occupe un fichier afin d'éviter l'erreur fichier occupé par un autre processus (peut être un processus système pour une image affiché dans l'explorateur en mode miniature ou pellicule)
Ai je mal utilisé le code ?
Bidouille
30 août 2009 à 02:29
j'ai ENFIN réussi à convertir entièrement ce code pour qu'il soit utilisable indifférement sur un OS 32-bits ou 64-bits. Enfin, côté .Net, parce que le driver en 64-bits je l'ai pas, je connais pas assez le C pour m'y attaquer pour le moment.
Bref, j'arrive à faire fonctionner ce code pour qu'il fonctionne parfaitement aussi bien sur 32 que sur 64 bits, mais la récupération du Name des objets de type File ne fonctionne que sur 32-bits (car pas de driver 64-bits).
Comme toutes les structures changent en 64-bits (pointeurs sur 8 octets), le code diffère pas mal (allocations mémoire différentes, utilisation de IntPtr qui implique de ne plus utiliser des offsets en dur...etc).
Pour info, ce code est vraiment très très utile, puisqu'il permet d'obtenir des tonnes d'infos sur le système (possibilité d'énumérer les processus via les handles de csrss, possibilité d'énumérer les jobs en cours après récupération du ObjectTypeNumber de "Job"...).
Bref si quelqu'un veut la version qui fonctionne sur x64, contactez moi (je poste pas là parce que tout le code est refait)
@+
29 mai 2009 à 19:05
quelqu'un a des infos pour l'utilisation de GetObjectTypeNumber dans ce code avec un OS 64bits ?
@+
20 févr. 2009 à 14:09
- GetThreadId sur Vista uniquement
- GetProcessIdOfThread sur Vista uniquement
- GetProcessId XP SP1 et Vista
@+
20 févr. 2009 à 12:26
Je passe juste pour dire qu'il est possible d'utiliser ces fonctions de Kernel32 :
- GetThreadId
- GetProcessIdOfThread
- GetProcessId
pour récupérer les ID et noms des processus/threads ouverts (à mettre dans RetrieveObject avec hHandle en paramètre).
@+ et merci pour l'excellente source.
27 sept. 2006 à 09:15
Mais oui il m'a été demandé dans un cahier des charges de surveiller quels fichiers sont ouverts par les utilisateurs à partir d'un programme bien précis.
26 sept. 2006 à 18:42
Ben oui il y a toujours un "mais":
SetWindowHookEx ne fait que du hook user mode, on n'entre pas dans les services systèmes ainsi.
Pour résumer, la seule méthode valable est le hook en driver. A toi de savoir si tu as vraiment besoin de récupérer les actions des composants système.
26 sept. 2006 à 11:05
26 sept. 2006 à 09:33
pour obtenir la liste des ouvertures de fichiers, on peut aussi se mettre directement dans un driver comme Filesystem filter et on récupère tout les évènements fichiers...comme filemon...
ShareVB
26 sept. 2006 à 09:30
25 sept. 2006 à 19:27
Mais bon tu as raison sur les présupposés, sauf que j'ai juste donne une solution supplementaire pour determiner les fichiers ouverts et j'ai precise dans le cas de notepad par exemple. Apres tous les softs ne sont pas fait pour etre distribues et etre utilises par tous, on code des fois (souvent) des ptits trucs pour soi-meme et donc ce n'est plus faire un soft sur des présupposés, mais se faire un petit outil perso pour un usage precis.
++
25 sept. 2006 à 19:07
Notepad ne modife pas sa currDir de lui même, c'est qu'il ne met pas le flag OFN_NOCHANGEDIR sur fichier->ouvrir donc sa currDir change, MAIS si on lance notepad avec un fichier sur la ligne de commande alors currDir n'est pas sur le fichier lu.
Comme quoi les présupposés...
25 sept. 2006 à 19:02
De là à présumer pour les autres... On ne peut pas batir un prog sur des présupposés.
25 sept. 2006 à 18:46
++
25 sept. 2006 à 18:23
Un prog accède à un fichier nimporte où sans pour cela qu'il soit dans la currDir du prog.
25 sept. 2006 à 18:16
Bon on va dire: recuperer le CurrentDirectory plus le WindowName et ca te donne le nom du fichier "ouvert"
Ca permet par exemple, a un administrateur de voir d'un coup d'oeil ce qui est en cours sur le systeme.
++
25 sept. 2006 à 18:03
Si vraiment on veut savoir les fichiers accédés, faut hooker ZwCreateFile (possible en vb ?).
25 sept. 2006 à 17:52
++
25 sept. 2006 à 17:41
25 sept. 2006 à 17:11
++
25 sept. 2006 à 17:08
Mais bon comme avec notepad ils fournissent dans le titre de leurs fenêtres le nom du fichier ouvert. GetWindowText fera l'affaire finalement.
25 sept. 2006 à 16:59
Tu peux toujours recuperer le nom du fichier ouvert par notepad en recuperant son CommandLine ;)
++
25 sept. 2006 à 14:04
Merci de l'info.
25 sept. 2006 à 13:59
Simple à tester, affiche un fichier dans notepad et va dans dans l'explorateur supprimer ce fichier, tu verras que aucun message d'impossibilité.
25 sept. 2006 à 12:33
Est-ce normal que si j'ouvre dans le bloc-note un fichier .txt je ne retrouve pas dans la liste le nom de ce fichier ?
7 sept. 2006 à 12:37
Merci :)
Je regarde ca des que j'ai une minute
++
7 sept. 2006 à 11:24
voilà une source pour lister les drivers : http://www.vbfrance.com/code.aspx?ID=39470
ShareVB
1 sept. 2006 à 14:41
++
30 août 2006 à 21:11
euh, la différence : c'est juste que ca affiche (et lit) la liste de tous les handles...et effectivement, il y a peu de différences dans les classes
pour la liste des drivers, si tu aimes le C : http://www.internals.com/utilities/winnt/ntdriverlist/NtDriverList.zip
ShareVB
30 août 2006 à 16:56
Eh y a un petit truc qui m'echape, quelle est la difference entre les fichiers ouvert lister par ce code, et ceux dans la source ou tu ne liste que les fichiers ouverts ?
Sinon c'est cool d'avoir mis le code du driver ^^
Au passage, tu ne connaitrais pas un moyen de lister les drivers en cours sur le systeme ?
Bonne continuation
++
30 août 2006 à 15:31
c'est pas mal... (lorsqu'on click sur devenv on se rend tout de suite compte pourkoi le .net est d'une lenteur incroyable)