Par quel processus un fichier est il utilisé ?
emmanuelgo
Messages postés
58
Date d'inscription
vendredi 24 décembre 2004
Statut
Membre
Dernière intervention
13 avril 2005
-
5 févr. 2005 à 07:53
ShareVB Messages postés 2676 Date d'inscription vendredi 28 juin 2002 Statut Membre Dernière intervention 13 janvier 2016 - 20 févr. 2005 à 19:45
ShareVB Messages postés 2676 Date d'inscription vendredi 28 juin 2002 Statut Membre Dernière intervention 13 janvier 2016 - 20 févr. 2005 à 19:45
A voir également:
- Par quel processus un fichier est il utilisé ?
- Fichier .ini - Conseils pratiques -Visual Basic / VB.NET
- Fichier json - Conseils pratiques -Javascript
- Voir les processus en cours linux - Forum C / C++ / C++.NET
- Comment savoir si un fichier est une image - Forum C# / .NET
- Vba écrire dans un fichier texte - Conseils pratiques -Visual Basic / VB.NET
4 réponses
ShareVB
Messages postés
2676
Date d'inscription
vendredi 28 juin 2002
Statut
Membre
Dernière intervention
13 janvier 2016
26
8 févr. 2005 à 20:08
8 févr. 2005 à 20:08
salut,
j'ai bien ca en stock mais en VB : http://www.vbfrance.com/code.aspx?id=28627
c'est une utilisation de fonctions non documentées...le prb c'est que si tu as le token Debug, ton processus peut accéder au processus système et au pipe nommés systèmes ce qui a pour effet de faire un deadlock...je suis en train de trouver et de coder la solution mais elle nécessite un driver en mode kernel (en C)...et je n'ai pas beaucoup de temps...peut être dans 2 à 3 semaine avec une version Delphi...
ShareVB
j'ai bien ca en stock mais en VB : http://www.vbfrance.com/code.aspx?id=28627
c'est une utilisation de fonctions non documentées...le prb c'est que si tu as le token Debug, ton processus peut accéder au processus système et au pipe nommés systèmes ce qui a pour effet de faire un deadlock...je suis en train de trouver et de coder la solution mais elle nécessite un driver en mode kernel (en C)...et je n'ai pas beaucoup de temps...peut être dans 2 à 3 semaine avec une version Delphi...
ShareVB
cs_grandvizir
Messages postés
1106
Date d'inscription
samedi 8 novembre 2003
Statut
Membre
Dernière intervention
3 septembre 2006
22
12 févr. 2005 à 18:56
12 févr. 2005 à 18:56
Ton explication est écrasante. Sérieusement: «token debug», «pipe», «deadlock»... Please explain !!
===========
ViewVite : HTML
===========
ViewVite : HTML
ShareVB
Messages postés
2676
Date d'inscription
vendredi 28 juin 2002
Statut
Membre
Dernière intervention
13 janvier 2016
26
13 févr. 2005 à 10:36
13 févr. 2005 à 10:36
salut,
sous NT:2K/XP... la sécurité est renforcée (lol) : il y a des "tokens privilege". Cela permet de dire à un processus : tu as le droit de faire ça mais pas ça. Par exemple, ouvrir un processus système comme csrss.exe (le sous système Win32) est inderdit à tous les processus qui ne possèdent pas le privilège SeDebugPrivilege...s'il l'a OpenProcess renvoit un handle de processus, sinon -1.
Sous NT/2K/XP, on peut obtenir la liste des handles ouverts par une fonction non documentées : NtQuerySystemInformation.
Pour obtenir le nom d'un handle de la liste précédente, il faut ouvrir un handle de processus, dupliquer le handle dont on veut le nom et utiliser NtQueryObject pour obtenir le nom...ensuite refermer tous les handles que l'on a ouvert...
Le problème, c'est que parmi les handles, il y a bien les fichiers, les clés de registres, les mutex,... mais aussi les tubes (pipe) (un truc qui sert à envoyer des données entre processus)...et le problème des tubes c'est qu'ils peuvent être utilisés par un autre thread (en attente ou autre)...et le fait de demander le nom de ce tube entraine une attente infinie puisque le thread qui possède le tube ne le rendra jamais libre (puisqu'il ne sais pas que notre thread attend après) : c'est un deadlock...et le résultat c'est que le processus qui a le tube et le notre sont bloqués définitivement (figés)...d'où risque de plantage...
(définition Microsoft pour deadlock : A run-time error condition that occurs when two threads of execution are blocked, each waiting to acquire a resource that the other holds, and both unable to continue running.)
Pour résoudre le problème, il faut lire la mémoire kernel à l'emplacement de l'objet (handle) pour savoir si l'objet est occupés et si oui, lire le nom par ses propres moyens (dans la mémoire kernel). Le prb de la mémoire kernel c'est qu'elle n'est pas accessible par un application en mode user comme la notre : il faut utiliser un driver en mode kernel...et des appels depuis l'application avec DeviceIoControl....
enfin, comme tout ce qui n'est pas documenté, c'est bien compliqué...la méthode décrite ici doit surement être à peu près celle de l'utilitaire handle.exe de sysinternals.com....
voilà
ShareVB
sous NT:2K/XP... la sécurité est renforcée (lol) : il y a des "tokens privilege". Cela permet de dire à un processus : tu as le droit de faire ça mais pas ça. Par exemple, ouvrir un processus système comme csrss.exe (le sous système Win32) est inderdit à tous les processus qui ne possèdent pas le privilège SeDebugPrivilege...s'il l'a OpenProcess renvoit un handle de processus, sinon -1.
Sous NT/2K/XP, on peut obtenir la liste des handles ouverts par une fonction non documentées : NtQuerySystemInformation.
Pour obtenir le nom d'un handle de la liste précédente, il faut ouvrir un handle de processus, dupliquer le handle dont on veut le nom et utiliser NtQueryObject pour obtenir le nom...ensuite refermer tous les handles que l'on a ouvert...
Le problème, c'est que parmi les handles, il y a bien les fichiers, les clés de registres, les mutex,... mais aussi les tubes (pipe) (un truc qui sert à envoyer des données entre processus)...et le problème des tubes c'est qu'ils peuvent être utilisés par un autre thread (en attente ou autre)...et le fait de demander le nom de ce tube entraine une attente infinie puisque le thread qui possède le tube ne le rendra jamais libre (puisqu'il ne sais pas que notre thread attend après) : c'est un deadlock...et le résultat c'est que le processus qui a le tube et le notre sont bloqués définitivement (figés)...d'où risque de plantage...
(définition Microsoft pour deadlock : A run-time error condition that occurs when two threads of execution are blocked, each waiting to acquire a resource that the other holds, and both unable to continue running.)
Pour résoudre le problème, il faut lire la mémoire kernel à l'emplacement de l'objet (handle) pour savoir si l'objet est occupés et si oui, lire le nom par ses propres moyens (dans la mémoire kernel). Le prb de la mémoire kernel c'est qu'elle n'est pas accessible par un application en mode user comme la notre : il faut utiliser un driver en mode kernel...et des appels depuis l'application avec DeviceIoControl....
enfin, comme tout ce qui n'est pas documenté, c'est bien compliqué...la méthode décrite ici doit surement être à peu près celle de l'utilitaire handle.exe de sysinternals.com....
voilà
ShareVB
ShareVB
Messages postés
2676
Date d'inscription
vendredi 28 juin 2002
Statut
Membre
Dernière intervention
13 janvier 2016
26
20 févr. 2005 à 19:45
20 févr. 2005 à 19:45
salut,
pour ceux que ca interesse, voilà la source en delphi 6 pour savoir la liste des fichiers ouverts dans le système : http://www.vbfrance.com/code.aspx?ID=28627
ShareVB
pour ceux que ca interesse, voilà la source en delphi 6 pour savoir la liste des fichiers ouverts dans le système : http://www.vbfrance.com/code.aspx?ID=28627
ShareVB