9

I've got a DLL file in the SYSTEM32 directory of one server, which I'm not sure I actually need.

Google has told me what it is normally used for, but the software has never been installed on this system. Still, I do consider it possible that one of the other installed products on the server may have included (and therefore, presumaby, will require) the file.

I did a search through the Registry for the name of the file, and also for some strings I found in the file's metadata, and I could not turn up anything informative. (Although the ACMru key did catch my eye, until I found out what it's for.)

Is there anything else I can do, to get the system itself to tell me what program installed the DLL, and/or what installed program(s) (if any) would use it?

NOTE: Tool suggestions are nice, but I won't be installing or running any additional software on this system. I need to work with whatever's available on a default install of Server 2003.

Iszi
  • 13,585
  • 44
  • 113
  • 181

3 Answers3

5

I'd check the date it was placed on the system and compare that with other files in the system to get clues. Search should allow you to search the entire system by date.

Also, posting the name of the file here would allow some here who may be familiar with it to ID it for you.

music2myear
  • 40,472
  • 44
  • 86
  • 127
  • Thanks. I might post the file name in another question. I wanted this one to be generic so that it would get answers which could be used for any DLL file. – Iszi Dec 22 '11 at 21:51
4

You could potentially examine each .MSI file in the %SystemRoot%\Installer folder. All (?) programs that are installed through the Windows installer will add their MSI here so that they can be UNinstalled at a later time. The folder generally has a ton of stuff. If/Once you find the dll amongst those myriad of MSI packages, you will have to map the package back to a well-defined name.

To decompile the msi files using a script, you can try to use this VBS tool http://www.hanselman.com/blog/HowToListAllTheFilesInAnMSIInstallerUsingVBSciript.aspx or you can try a program called MSIDiff (which I've never used) http://dennisbareis.com/msidiff.htm. Of course, considering the constraints of not having to install tools, the latter won't necessary work in that regard. The former would if cscript is installed.

The latter tool might do the package name mapping for you without resorting to manually searching the registry for the appropriate GUID or MSI filename. The former tool can be modified to dump the package name if you knew which table/column to reference (I do not).

The VBS script simply examines the MSI file from a database perspective. The key work is done with: database.OpenView("SELECT FileName FROM File").

logicalscope
  • 141
  • 5
  • Isn't this very costly to do, like equal to installing all of them? On my Windows 8 those are 412 items, on my Windows 7 those are 559 and I would think he had an equal amount. Also, the file might have not came from a `msi` installation... – Tamara Wijsman Dec 22 '11 at 22:33
  • Yes, it is costly, but for situations where you want to know ownership without having the foresight to snapshot the system before and after, this can give some insight. You can also automate the actual decompilation and comparison function (it's just a vbs script after all). I agree it's not a perfect sol'n since not all packages are installed through MSI, but you might get lucky. As you said, there's a lot of them, so odds are that the file might have come through that way. – logicalscope Dec 22 '11 at 22:37
  • I wonder if there are tools that could just look inside the MSI files rather than decompiling/decrompressing them. Any way, in another new question the OP made we are talking about a file that is already on our systems from installation time... – Tamara Wijsman Dec 22 '11 at 22:40
  • Tom, I'm pretty sure this vbs simply examines the MSI from the database view. The MSI is simply a db. This tool uses SQL to extract the filenames from the appropriate table. It doesn't "decompile it" per se and I should have specified this in my post. I'll revise. – logicalscope Dec 22 '11 at 22:42
1

Process Monitor can do this for you. Just filter by the DLL's name and when a program tries to load it there will come an entry which mentions which process is looking for and/or accessing the DLL you mentioned.

You should also try to do a boot log (enable boot logging in the menu, then reboot and open process monitor again) which is necessary to catch programs and services that load it upon boot.

Tamara Wijsman
  • 57,083
  • 27
  • 185
  • 256
  • What about any inactive programs? It seems I'd have to open every suspect program on the computer and watch out for it in Process Monitor. – Iszi Dec 22 '11 at 21:59
  • @Iszi: As mentioned on chat, enumerating them or their installers will take a long time. Either monitor passively as mentioned, actively with Process Explorer. Or search like music2myear mentioned, which can easily be done with Search Everything. – Tamara Wijsman Dec 22 '11 at 22:36