Home/ Questions/Q 7812505
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-02T04:31:46+00:00

I have an application that runs as a WCF webservice on IIS7. It calls

  • 0

I have an application that runs as a WCF webservice on IIS7. It calls a COM control and this control then loads another dll with data. This application has been in use for quite a while and normally works fine, but recently I ran into a problem on one machine where the LoadLibrary call to load the data dll fails. However, the call doesn’t always fail, it will work for the first call after the IIS service is restarted, and then fails after that.

The data dll exists in the same directory as the COM control, and the current directory is set to this directory. I’ve checked and the current directory does not get set to another directory, it stays the same for both calls. The separate calls are separate calls to the webservice and in between them the com control gets unloaded, as does the data dll.

The data dll loads fine if I place it in the system directory or use the full path to the dll in the com directory, so I can work around this, but I’m just wondering why it would happen. When I call GetLastError after it fails to load the module, as I mentioned it just gives me ‘The specified module could not be found’ error.

The MSDN description for LoadLIbrary says that the current directory should be searched and all the other installations where this has worked seems to suggest that it normally does. The machine that it’s failing on is a Windows Server 2008 R2 machine, although the application has been run on this type of machine many times before.

Any ideas are welcome. Is there a way to get LoadLibrary to enumerate where it’s looking?

Thanks,
Jordan

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I haven’t found a function that will enumerate all the DLL search paths, and it looks rather complicated: http://msdn.microsoft.com/en-us/library/windows/desktop/ms682586%28v=vs.85%29.aspx

    The Windows behavior of searching the current working directory for libraries (in addition to the location of the .exe) is considered a potential security flaw. That article describes some ways to exclude the current directory within a process, including the SetDllDirectory function. I don’t know how IIS works, but if you don’t control the process, maybe someone else is tampering with the search settings? I think GetDllDirectory will tell you if that changed.

    There is also a global registry setting that disables searching the working directory, but since your load isn’t always failing I have to guess that’s not the cause.

    • 0