6

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.

user1542042
  • 195
  • 1
  • 9
  • 1
    You are using a Qt version for CE on a desktop machine? Look no further :) Google "loader snaps" if you want a diagnostic. – Hans Passant Aug 12 '13 at 23:23
  • Actually no. We rebuild Qt in both Windows and Windows CE versions. But the code that runs is the same in each. – user1542042 Aug 12 '13 at 23:45
  • I would separate problems of loading managed and unmanaged parts first. Convert your wrapper into a stub and try to load it. Load your C++ dll into native process and see if this will work or not. Posting pieces of code of your wrapper might be very helpful. – Kirill Kobelev Aug 13 '13 at 02:41

2 Answers2

3

@ 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).

Community
  • 1
  • 1
user1542042
  • 195
  • 1
  • 9
0

Standard tool for the job: Dependency Walker

MSalters
  • 173,980
  • 10
  • 155
  • 350