0

I have a VCL application built in C++Builder 10.0 Seattle. It uses Axis Media Control on the Form to display video, therefore it loads the AxisMediaControl.dll file when it runs.

In the past, I have had this deployed on a 32bit target machine, where the application lived in the C:\Program Files\AppName directory, and the AxisMediaControl.dll was installed to this same location. Everything worked as expected.

This application is a 32 bit application, so when deploying to a 64 bit target machine, it is installed in the C:\Program File (x86)\AppName directory. Once again, the AxisMediaControl.dll file is deployed in the application directory.

The app fails to launch with the error "The specified module could not be found". Using Process Monitor, I found the program is looking for the Axis DLL in the older Program Files directory instead of the x86 dir. What would cause the application to look for the DLL in that location?

Running the same binary on my dev machine, the application loads the DLL from my SysWOW64 directory. If the DLL is placed there on the target machine, it still fails to look in that location. It is ONLY looking in the older Program Files application path, which I cannot understand.

I'm hoping someone can shed some light.

Remy Lebeau
  • 555,201
  • 31
  • 458
  • 770
martinarcher
  • 137
  • 2
  • 9
  • The only way it could be looking in the old `Program Files` folder on a 64bit system is if you are telling it to look there, such as if you are manually calling `LoadLibrary()` with the old path. If the DLL is statically linked into the app, or the app is dynamically loading it with a relative path, then it should be looking for the DLL on the [OS's Search Path](https://msdn.microsoft.com/en-us/library/windows/desktop/ms682586.aspx), which always looks in the app's installation folder first. – Remy Lebeau Oct 18 '16 at 23:35
  • That's what I thought as well Remy. No where in my project do I call LoadLibrary() or any other method to load a dll at runtime. I did find several registry entries on the target system referencing that path and dll name. Altering or changing them has broken the applications ability to launch. Very strange, still working on figuring out how the OS is referencing these areas of the registry instead of the OS's Search Path like you mentioned. – martinarcher Oct 19 '16 at 13:13
  • So ti turns out with some more investigation, the AMC (Axis Media) control looks up the path of the AxisMediaControl.dll file using the class ID int he registry...{745395C8-D0E1-4227-8586-624CA9A10A8D}. The path listed there is then used to load the DLL. I wish I could do this differently but it looks like what Axis did in their code since the AMC package is required to be pre-installed. At least I got to the bottom of why it is loading it from that path. – martinarcher Oct 19 '16 at 15:04
  • That means the DLL is implementing a COM object, which requires registration before it can be used. Unless your app use a manifest that enables [Registration-Free COM Activation](https://msdn.microsoft.com/en-us/library/ms973913.aspx), then you can reference the DLL file directly without involving the Registry. – Remy Lebeau Oct 19 '16 at 17:04

0 Answers0