SAVOIR QUEL FICHIER EST UTILISÉ PAR TELLE APPLICATION : LA LISTE DES FICHIERS OU
cs_Willi
Messages postés
2375
Date d'inscription
jeudi 12 juillet 2001
Statut
Modérateur
Dernière intervention
15 décembre 2018
-
27 févr. 2006 à 00:58
Elikart KM - 28 mars 2017 à 10:20
Elikart KM - 28 mars 2017 à 10:20
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/36281-savoir-quel-fichier-est-utilise-par-telle-application-la-liste-des-fichiers-ouverts-sur-le-systeme-pour-2k-xp-2k3
https://codes-sources.commentcamarche.net/source/36281-savoir-quel-fichier-est-utilise-par-telle-application-la-liste-des-fichiers-ouverts-sur-le-systeme-pour-2k-xp-2k3
28 mars 2017 à 10:20
7 nov. 2013 à 19:19
Ton code est vraiment très bon.
par contre connait tu un moyen de connaître le hwnd de la fenêtre qui affiche le fichier, je m'explique,
j'ouvre deux fichier pdf
quand j'exécute ton programme il m'affiche bien mes deux fichier pdf mais le pid du programme est le même.
a ton avis c'est possible de retrouver le hwnd de la fenêtre qui affiche le fichier
28 sept. 2011 à 20:07
Ce code gère maintenant à la fois x86 et x64 (en mode test signing, car le driver n'est pas signé avec un certificat officiel)
ShareVB
20 janv. 2010 à 09:21
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
9 août 2006 à 21:23
en retestant j'ai constaté que le deboggueur de VBExpress 2005 est lent comme un escargot...donc le mieux c'est de lancer l'exe dans le dossier bin\ (ou Ctrl-F5 dans vb)
je rappelle aussi que si vous utilisez le bouton STOP de VB alors le driver ne pourra pas être déchargé avant le prochain démarrage (car son handle ne sera jamais fermer) et donc source d'erreur...
ShareVB
18 avril 2006 à 14:18
he je ne pense pas que ce soit une beta mais c'est la version d'evaluation VBExpress 2005...
Et en effet c'est surement une des causes de mes problemes, car si VB est fermer, je n'ai plus aucune erreur... bizarre...
Sinon pour Vb6(Version US) j'avais soit le probleme de l'appli bugee et inKillable, soit un crach complet sans avertissement.
Ceci dit, je viens de voir que tu avais fais une mise a jour en fevrier, donc non je n'ai pas la derniere version, mais c'est apparement une mise a jour pour Win2000...
++
18 avril 2006 à 09:08
les violations d'accès en .Net c'est un peu bizarre...es-tu sûr de ne pas avoir une version beta de VB...
euh oui, c'est normale, c'est une version spécialisée d'un autre code qui lui liste tous les handles...je vais ajouter la fonctionnalité de fermeture de handle bientôt...
pour le code VB6, c'est bizarre parce que celui-ci c'est une stricte traduction du code VB6...es-tu sûr d'avoir la dernière version...et à l'occassion ca fait quoi...
ShareVB
18 avril 2006 à 01:32
En effet c'est beacoup plus stable, encore quelques ptites erreurs notement des violation access en quittant l'appli..
Sinon je ne recupere aucune cles ouverte mais seulements des fichiers et des dossiers, est-ce normal docteur ? pcq je vois la fonction pour "convertir" le noms de cle...
Encore merci
++
17 avril 2006 à 14:12
Merci je vais tester ca :)
Pour vb6, je voulais dire que tu avais deja poste une source simillaire, et EbArtsoft aussi, mais chez moi les 2 codes crachaient completement :(
++
17 avril 2006 à 13:52
voilà une version qui ne semble pas planter aavec VS2003 et VB2005...
le problème je pense était l'utilisation de VarPtr qui en fait ne peut pas exister en VB.Net...
pour ce que tu dis du code vb6...j'ai pas compris de quoi tu parles...
ShareVB
15 avril 2006 à 13:41
Arf snif ca plante apres 2 ou 3 raffraichissement :)
J'ai pas encore reussi a isoler l'erreur car ca plante sans prevenir et sans message d'erreur, et dans l'ide je n'ai aucun soucis ca marche impec... ~|
J'utilise VBExpress 2005, sous XP SP2, si quelqu'un a une piste ?
Sinon n'y a t'il pas un moyen un peu plus .net d'enumerer les handles ?
Car ca plantait avec la version vb6 aussi... (meme le code de EbArtSoft)
Bonne prog a tous
++
5 avril 2006 à 17:21
La source est bien ! 10/10.
Bonne continuation !
Redman
28 févr. 2006 à 19:47
willi>
-> Windows NT/2000 Native API Reference : c'est une liste de fonction un peu comme MSDN...très bien fait, très pratique et très technique...un must...
-> Undocumented Windows 2000 Secrets : vu le sommaire, il doit être technique et assez complet...
-> Win32 System Programming (3rd Ed) : vu le sommaire, c'est un MSDN en livre avec plus d'exemples mais surement peu de choses non documentées
-> Windows Internal : je trouve qu'il manque (dans l'édition que j'ai lue) de concret...les concepts et fonctionnements internes de Windows sont très détaillés sans vraiment beaucoup de code et très peu de prototypes...un must pour comprendre, mais à mon avis pas pour coder...
troxsa>
ceci ne donne la liste que des modules qui compose une application et pas la liste de ces fichiers ouverts (issus de la liste des handles ouverts (clés de registre, fichiers, fichiers mappés, mutex, events...)). Bien que les modules est un handle (qui leur adresse de mappage dans le processus), ces handles ne sont du même type que ceux des fichier ouverts...
ShareVB
27 févr. 2006 à 22:23
Il est évident que l'ont ne retrouve pas de vb dans ces livres :D
27 févr. 2006 à 22:14
27 févr. 2006 à 21:57
Donc je pense avoir trouver une petite piste quand meme, mais j'ai fait ça tres vite fait sa fonctionne plus ou moins bien
___________________________
Dim ps As Diagnostics.Process
Dim value As ProcessModuleCollection
For Each ps In Diagnostics.Process.GetProcesses(".")
Console.WriteLine(ps)
value = ps.Modules()
For i As Integer = 0 To value.Count - 1
Console.WriteLine(value.Item(i))
Next
Next ps
_________________
Je sais pas trop si c'est bien sa qui corespond, mais en tout cas ça donne des idées, puis je vais aller voir du coté wmi voir si y a plus simple
A bientot
www.troxsa.info
27 févr. 2006 à 21:56
Merci
- Windows NT/2000 Native API Reference, par Gary Nebbett (2000)
- Undocumented Windows 2000 Secrets, par Sven Schreiber (2001)
- Win32 System Programming (3rd Ed), par Jonhson Hart (2004)
- Windows Internal (4th Ed), par David Solomon et Mark Russinovich (2005)
27 févr. 2006 à 20:15
non, les modules (exe et dll) chargés ne font pas forcement partis des fichiers et handles ouverts (par CreateFile ou autre)...avoir la liste des modules exe et dll mappés dans l'espace d'adressage d'un processus, c'est documenté largement par Microsoft...
par contre, là, il s'agit bien d'avoir la liste des fichiers (image JPEG, document Word, fichier texte...) ouvert par une application...cette méthode n'est pas documentées par Microsoft. :))
Et je pense que des Experts en Windows comme Mark Russinovich et Bryce Cogswell (sysinternals.com), dont un doit avoir accès au code source de Windows, qui ont exposé cette méthode dans leur outils Handle, n'auraient pas oublié WMI dans leur recherches... :))
Enfin, je dis ça parce que moi-aussi, je n'ai rien trouvé dans WMI qui donne cette liste (qui n'est pas celle des modules)...
ShareVB
27 févr. 2006 à 12:40
Par contre j'avais écrit un code permettant de retrouver les modules utilisés par une application. Mais je n'ai pas vérifié si cela correspondait avec ce que l'on retrouve en utilisant le code de ShareVB.
TroXsA voici surement une autre méthode (c#) :)
public static string[] GetModules(int id)
{
Process p = Process.GetProcessById(id);
ProcessModuleCollection pmc = p.Modules;
string[] arrS = new string[pmc.Count];
int ic = 0;
foreach (ProcessModule pm in pmc)
{
arrS[ic] = pm.ModuleName;
ic++;
}
return arrS;
}
27 févr. 2006 à 11:51
A bientot
@+
www.troxsa.info
27 févr. 2006 à 11:48
27 févr. 2006 à 10:23
(même si elle n'est pas fignolée le niveau mérite une note excellente)
27 févr. 2006 à 01:11
Je trouve que c'est tres bien fait ! mais WMI le fait ! avec un System.Management puis suffit de trouver la bonne class WMI qui doit etre Win32_Process
Cordialement
27 févr. 2006 à 00:58
Code excellent, vraiment très bien expliqué !
J'ai hate de voir le code du driver :)
10/10