Comment savoir quel programme est installé ou utilise un fichier DLL spécifique?


9

J'ai un fichier DLL dans le répertoire SYSTEM32 d'un serveur, dont je ne suis pas sûr d'avoir réellement besoin.

Google m'a dit à quoi il sert normalement, mais le logiciel n'a jamais été installé sur ce système. Néanmoins, je considère qu'il est possible que l'un des autres produits installés sur le serveur ait inclus (et, par conséquent, présumera, nécessitera) le fichier.

J'ai fait une recherche dans le registre pour le nom du fichier, ainsi que pour certaines chaînes que j'ai trouvées dans les métadonnées du fichier, et je n'ai rien trouvé d'information. (Bien que la touche ACMru ait attiré mon attention, jusqu'à ce que je sache à quoi elle sert .)

Y a-t-il autre chose que je puisse faire pour que le système lui-même me dise quel programme a installé la DLL et / ou quel (s) programme (s) installé (s) (le cas échéant) l’utiliserait?

REMARQUE: les suggestions d'outils sont agréables, mais je n'installerai ni n'exécuterai aucun logiciel supplémentaire sur ce système. Je dois travailler avec tout ce qui est disponible sur une installation par défaut de Server 2003.

Réponses:


5

Je vérifierais la date à laquelle il a été placé sur le système et le comparerais avec d'autres fichiers du système pour obtenir des indices. La recherche devrait vous permettre de rechercher l'ensemble du système par date.

De plus, la publication du nom du fichier ici permettrait à certains ici qui le connaissent peut-être de l'identifier pour vous.


Merci. Je pourrais poster le nom du fichier dans une autre question. Je voulais que celui-ci soit générique afin qu'il obtienne des réponses qui pourraient être utilisées pour n'importe quel fichier DLL.
Iszi

4

Vous pouvez potentiellement examiner chaque fichier .MSI dans le dossier% SystemRoot% \ Installer. Tous les programmes (?) Installés via le programme d'installation de Windows ajouteront leur MSI ici afin qu'ils puissent être désinstallés ultérieurement. Le dossier contient généralement une tonne de choses. Si / Une fois que vous avez trouvé la DLL parmi cette myriade de packages MSI, vous devrez mapper le package sur un nom bien défini.

Pour décompiler les fichiers msi à l'aide d'un script, vous pouvez essayer d'utiliser cet outil VBS http://www.hanselman.com/blog/HowToListAllTheFilesInAnMSIInstallerUsingVBSciript.aspx ou vous pouvez essayer un programme appelé MSIDiff (que je n'ai jamais utilisé) http: //dennisbareis.com/msidiff.htm . Bien sûr, compte tenu des contraintes de ne pas avoir à installer d'outils, ces derniers ne seront pas obligés de travailler à cet égard. Le premier le ferait si cscript était installé.

Ce dernier outil peut effectuer le mappage de nom de package pour vous sans recourir à la recherche manuelle dans le registre du nom de fichier GUID ou MSI approprié. L'ancien outil peut être modifié pour vider le nom du package si vous saviez à quelle table / colonne faire référence (je ne sais pas).

Le script VBS examine simplement le fichier MSI du point de vue de la base de données. Le travail clé se fait avec: database.OpenView ("SELECT FileName FROM File").


N'est-ce pas très coûteux à faire, comme égal à tous les installer? Sur mon Windows 8, ce sont 412 éléments, sur mon Windows 7, ce sont 559 et je pense qu'il avait un montant égal. De plus, le fichier pourrait ne pas provenir d'une msiinstallation ...
Tamara Wijsman

Oui, cela coûte cher, mais pour les situations où vous voulez connaître la propriété sans avoir la prévoyance de prendre un instantané du système avant et après, cela peut donner un aperçu. Vous pouvez également automatiser la décompilation et la fonction de comparaison (ce n'est qu'un script vbs après tout). Je suis d'accord que ce n'est pas une solution parfaite car tous les packages ne sont pas installés via MSI, mais vous pourriez avoir de la chance. Comme vous l'avez dit, il y en a beaucoup, donc il y a de fortes chances que le fichier soit passé par là.
logicscope

Je me demande s'il existe des outils qui pourraient simplement regarder à l'intérieur des fichiers MSI plutôt que de les décompiler / décompresser. De toute façon, dans une autre nouvelle question que l'OP a faite, nous parlons d'un fichier qui est déjà sur nos systèmes depuis le moment de l'installation ...
Tamara Wijsman

Tom, je suis presque sûr que ce vbs examine simplement le MSI à partir de la vue de la base de données. Le MSI est simplement un db. Cet outil utilise SQL pour extraire les noms de fichiers de la table appropriée. Il ne le "décompile pas" en soi et j'aurais dû le préciser dans mon message. Je vais réviser.
scope logique

1

Process Monitor peut le faire pour vous. Il suffit de filtrer par le nom de la DLL et lorsqu'un programme essaie de la charger, il y aura une entrée qui mentionne quel processus recherche et / ou accède à la DLL que vous avez mentionnée.

Vous devez également essayer de créer un journal de démarrage (activez la journalisation de démarrage dans le menu, puis redémarrez et ouvrez à nouveau le moniteur de processus) qui est nécessaire pour intercepter les programmes et services qui le chargent au démarrage.


Qu'en est-il des programmes inactifs? Il semble que je devrais ouvrir tous les programmes suspects sur l'ordinateur et le surveiller dans Process Monitor.
Iszi

@Iszi: Comme mentionné sur le chat, leur énumération ou celle de leurs installateurs prendra beaucoup de temps. Soit surveiller passivement comme mentionné, activement avec Process Explorer. Ou recherchez comme music2myear mentionné, ce qui peut facilement être fait avec Search Everything.
Tamara Wijsman
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.