Process exceution slow because of unnecessary dll lookups

Question

I am having performance problems with a small program that is sometimes started very frequently on a machine. It is a 32bit program being run on a 64bit machine. It is called im_comp.exe and is normally placed and run from:

C:\Program Files (x86)\TESLA\bin

Now, if I run this program 150 times from this place, it takes 15 seconds, but if I copy the bin-folder to the desktop and run it from there, it takes only 10 seconds (it is ~30% faster every time, without exceptions). I figured this might have something to do with where the process loads its dlls from, so cleared the path of anything related to TESLA and that does not matter. Then I ran process monitor on a single execution and found a clear difference. In the log from when the program was run from C:\Program Files (x86)\TESLA\bin, there are a lot of entries following this pattern:

CreateFile  C:\Program Files (x86)\TESLA\bin\im_comp.exe.Local\wow64.dll PATH NOT FOUND Desired Access: ...
CreateFile  C:\Program Files (x86)\TESLA\bin\wow64.dll NAME NOT FOUND Desired Access: ...
CreateFile  C:\Windows\System32\wow64.dll SUCCESS Desired Access: ...

These entries are missing completely in the log when I run from the Desktop.

Now, there are .Local files both in the desktop bin folder and the other one. Even if I remove all the .Local files from the folders, I still get the same log patterns.

Why does the process try to access dll files in the local directory even though there are no .Local files? Is this a problem based on the program itself or the environment? Is there any way to turn it off, preferably without moving it since it is part of a larger application.

Answer 1

This is by design, I believe.

Microsoft allows developers to redistribute components/.dll's that come with Visual Studio, such as Visual Basic related runtimes, etc. So it has not been atypical for many Windows programs to have specific versions of .dll's they depend on in their own application directories, and have a need to use that version over a later version that may be installed on the system.

I have a hunch that during installation Windows can map program file names to known .dll locations (this might even be part of the "Superfetch" service) and therefore not search for them or even preload them. I will bet something like that is going on. Not sure how to turn it off, though.