How do I find the source of a "A procedure imported by 'xxx.dll' could not be loaded." exception?

Question

I have been chasing this exception for the past week.

Situation is:

I have an application that is written in C# and built in Visual Studio 2010. The application includes a DLL that is a wrapper of an unmanaged code library. The unmanaged code is written in C++ and built in Visual Studio 2008. This is required because the code references additional libraries (Qt) and that code targets WinCE version 5 (necessary due to devices supported in the field).

I have tried many of the suggestions I have seen here, including using various dependency walkers (VS 2008 depends, dependency_walker, and Dependz) as well as other tools such as Reflector and Process Monitor from SysInternals.

All of the tools either show no problems (Reflector) or old dependencies that are obsolete in my environment (Win 7) like DCOMP.DLL, GPSVC.DLL, & IESHIMS.DLL.

In the debugger, I can step through my code right up until I instantiate an object that references my Managed Wrapper DLL. It does not step into the instantiation of the object, but throws the exception immediately.

In Process Explorer (from SysInternals) I can see the Managed DLL loaded, along with the necessary subsidiary DLLs. In Process Monitor (from SysInternals) at the point of the problem there are no stacks of not found messages. It just fails.

Any ideas or thoughts in finding this problem would be appreciated.

Answer 1

@ Hans Passat - Thank you for the hint on Global Flags.

Here is an excellent blog post on using the tools. The gflags.exe program referred to by most of the Google references to "Show Loader Stacks" is part of the Windows Device Driver Development Kit (WinDDK) and it manages the Registry settings mentioned in that post for you.

The output from running with "Show Loader Stacks" identified that a symbol that should have been in my unmanaged DLL was not in the DLL I was using.

It turns out that I was building the wrong version of the DLL. This was due to my poor understanding of the build process (too many versions built too many different ways).