4

I am getting the following error when we load up a DLL in our program that throws the following error:

Unable to load DLL 'xxx.dll': The specified procedure could not be found. (Exception from HRESULT: 0x8007007F)

This doesn't make sense to me because the DLL exists and is built into our installer every time we make a change to our code. This DLL has not changed in months and this just started happening about a week ago from our newly installed copies. Any ideas? The project in question is an unmanaged C++ project that gets called from a .NET 3.5 app.

codewario
  • 19,553
  • 20
  • 90
  • 159

2 Answers2

4

Probably one of xxx.dll's dependencies is not being found. You can inspect its dependencies using DUMPBIN /dependents xxx.dll, and intuit some additional information by using Dependency Walker to see which ones might not be present or unfindable on the system under test.

LeopardSkinPillBoxHat
  • 28,915
  • 15
  • 75
  • 111
Andy Finkenstadt
  • 3,547
  • 1
  • 21
  • 25
  • Just be aware that Dependency Walker may show some "false positives", some dependencies that don't really matter. (The auther explains this in the website FAQ.) For example, I had a problem with a DLL, and Dependency Walker said it needed ieshims.dll and wer.dll, but this was not my problem - my DLL can function fine without those two DLLs. – RenniePet Sep 16 '13 at 09:59
3

The error isn't saying that the DLL doesn't exist; it's saying that the DLL is missing the procedure call you're trying to make. This most likely means there is another DLL with the same file name earlier in the search path, that's an older version.

Are you installing the DLL into the same folder as the calling application?

Michael Edenfield
  • 28,070
  • 4
  • 86
  • 117
  • Yes, it is installed to the same folder as the exe is. – codewario May 02 '11 at 18:41
  • The next step to track this kind of problem down is to run a utility like Procmon from Sysinternals and verify that the correct DLL files are being loaded from the correct locations; as @Andy mentioned, you'll need to make sure that indirect dependency libraries aren't being loaded from the wrong place as well. – Michael Edenfield May 03 '11 at 19:39
  • Turns out the issue was we never added our DLL location to the search path. This was never a problem in the past, however, in particular the issue was caused by DropBox, which loads dbghelp.dll from System32 as a part of it's shell extension. The issue was only present in XP it seems as the version in Vista and up is a new enough version that has the functions our dll that failed was trying to access. – codewario May 20 '11 at 18:03