Paul said:
You could try Autoruns, and see if you could see it in there.
Thankfully AutoRuns also has a search feature so you can look for an
item by some portion of its name. Considering how many places AutoRuns
inspects, the total list could be daunting for the user to interrogate.
The storage path to the executable, as mentioned in Autoruns, might
hint as to where it came from (where it should have been stored).
http://technet.microsoft.com/en-us/sysinternals/bb963902
It's also possible that a .dll file will NOT be listed by AutoRuns. It
could very well be called by a parent program. DLLs are, after all,
libraries of methods (functions) that are typically called by some
parent .exe program (few DLLs actually use their main method to run some
code when they get loaded).
So using ProcMon (also by Microsoft after acquiring SysInternals and
merging FileMon and RegMon together) could help determine what process
is trying to access that file. You would define a filter so only that
file would be shown, configure ProcMon to log on boot, and reboot the
host, then load ProcMon which sees the boot log and asks if you want to
load it. However, I only know how to use ProcMon to detect who accesses
a file. I'm not sure if it is usable to determine when a process tries
to access a file when it doesn't exist. That is, I don't know if
ProcMon is usable to see when a process tries to *find* a file versus
when a process touches an existing file. Rather than specify the full
path to the file (and because it doesn't exist then you can't do that),
I'd define it's filter to look for just "msifcs32" to see if it records
an open or query function by a process trying to locate the file.
I had a .cbm file that kept showing up in C:\. I couldn't figure out
who was creating it. Loading ProcMon didn't show up anything but then
the file was getting created during Windows startup so me loading
ProcMon to monitor my system had it monitoring too late. So I defined a
Path rule that looked for ".cbm" at the end of the path (to the file) to
watch any process that would create this file. I then configured
ProcMon to log during the boot, rebooted, loaded ProcMon, had it load
its boot-time log, the filter was still active. I saw Dropbox first
doing an Open/Query operation on the file following by several attempts
by Windows Explorer to access/use this file. I contacted Dropbox asking
why they keep recreating this file in my root folder (but they haven't
bothered to respond yet).
I was looking for something that was creating a file during Windows
startup. I suspect that ProcMon can be used to filter on any path (for
a file, even without a path but just part of the filename) to see any
process attempting a file I/O operation on that string whether the file
exists or not.
Process Monitor (ProcMon)
http://technet.microsoft.com/en-us/sysinternals/bb896645
