-1

I have a strange issue, where my application that runs at my place doesn't work somewhere at customers place. In my application I try to load another dll with LoadLibrary() from within the same folder. If the application is run as normal user a 126 error is returned. If the same application is started with Admin rights the dll is loaded correctly.

It's hard to diagnose because I cannot reproduce the error at my machine. Any ideas?

EDIT

OK, it was a dependency: the dll was a Debug-Build and the MSVCP120D.dll and MSVCR120D.dll could not be found. I could tell this by a Process Monitor-Log.

BUT: I have a log as normal user and a log as Admin and in both cases the dependencies cannot be found. Why does LoadLibrary work in case of Admin-rights??

joerg
  • 717
  • 2
  • 8
  • 18
  • Was the application installed in the `Program Files` or `Program Files (x86)` folder on the customers machine? – KompjoeFriek Nov 17 '16 at 12:07
  • need more info - `LoadLibrary` used only dll name or full path ? what is the folder path ? – RbMm Nov 17 '16 at 12:47
  • @KompjoeFriek was installed in `Program Files (x86)` – joerg Nov 17 '16 at 13:04
  • @RbMm: I just use the name of the dll without a path specified – joerg Nov 17 '16 at 13:05
  • Probably the OP has configured the CWDIllegalInDllSearch option, see https://support.microsoft.com/en-us/kb/2264107 – Harry Johnston Nov 17 '16 at 18:37
  • Note that (if I remember rightly) this setting can prevent DLLs from being loaded from the current directory even if the current directory is also the application directory - it doesn't just remove it from the search path. – Harry Johnston Nov 17 '16 at 18:41
  • @HarryJohnston: good hint, but that wasn't the reason here. See my edit... – joerg Nov 18 '16 at 08:12

1 Answers1

3

That is ERROR_MOD_NOT_FOUND, which is pretty self-explanatory. Either the DLL you are loading, or one of its dependencies, cannot be found. Perhaps you failed to install the necessary dependencies, e.g. the MSVC runtime. Or perhaps it is something else.

You'll need to do some debugging and investigation. I would start by profiling the DLL load using Dependency Walker.

David Heffernan
  • 601,492
  • 42
  • 1,072
  • 1,490
  • 3
    Dependency Walker hasn't been updated in ages. If you want to play it safe, using [Process Monitor](https://technet.microsoft.com/en-us/sysinternals/processmonitor.aspx) instead of Dependency Walker's profiling might be a better option. – IInspectable Nov 17 '16 at 12:46
  • Maybe. But then again dynamic linking has been basically stable for a long time. I'd expect DW to tell you which module could not be found. – David Heffernan Nov 17 '16 at 12:58
  • The dll is there! The dependencies are in Windows/System folder and can be found. The question is: why can there be a difference between running as Admin and Non-Admin?! – joerg Nov 17 '16 at 13:03
  • Why don't you do what I suggest. Get some real information. Then nobody has to guess. Find out which dll cannot be found. – David Heffernan Nov 17 '16 at 13:14
  • 2
    @joerg - "The dll is there!" - your dll by self not found or one of it dependencies ? try `LoadLibraryEx(pat,0, DONT_RESOLVE_DLL_REFERENCES)` - if dll by self not found this call also fail, if problem in depended dll - will be no errors here. and try full path use,in place dll name. will be same result ? – RbMm Nov 17 '16 at 14:13
  • OK, so it was as I said. You now that you must not distribute the debug runtime? – David Heffernan Nov 18 '16 at 08:16