Wrapping a DLL - Understanding why Import Fails

Question

Background

I have an embedded system which runs an application originally written in C++ and compiled in Visual Studio, which results in a single executable and more than 30 DLLs. These libraries cannot be browsed in VS Object Browser or other tools such as P/Invoke Interop Assistant.

Loading some of the DLLs in Dependency Walker shows that all of them are missing some dependencies deep in their dependency tree (cdfview.dll, dwmapi.dll, w32topl.dll, ...) but according to this question, that is likely not an issue.

I have some of the source code files, and all of the compiled DLLs. The application currently runs without issue, indicating there are no real dependency issues.

I am trying to call some library functions and eventually make a wrapper using C#, but am unable to successfully import and call even the simplest of functions. I always receive the following error:

Unable to load DLL 'dllName.dll': A dynamic link library (DLL) initialization routine failed. (Exception from HRESULT: 0x8007045A)

Sample Code [EDITED]

From the C++ source code header file I have the following declarations:

#define OB_API __declspec(dllexport) __cdecl 

typedef unsigned long DWORD;  // From windef.h
typedef DWORD OBSTATUS;

OBSTATUS OB_API TestObj(void);

In the C++ source code file the following definition is given (which would seem to always return true):

BOOL WINAPI DllMain(HANDLE  /* hModule */, 
                      DWORD   ul_reason_for_call, 
                      LPVOID  /* lpReserved */
                      )
{
    switch (ul_reason_for_call)
    {
    case DLL_PROCESS_ATTACH:
    case DLL_PROCESS_DETACH:
    case DLL_THREAD_ATTACH:
    case DLL_THREAD_DETACH:
        break;
    }
    return TRUE;
}

In my C# application class, I add the following declaration:

[DllImport(@"dllName.dll", CallingConvention=CallingConvention.Cdecl)
public static extern ulong TestObj();

The DLL and C# application binary reside in the same directory.

Questions

From researching the error, it seems there is a large number of reasons this particular exception could be thrown and I was wondering how I could further troubleshoot this type of issue.

Is there any way to get more detailed information on why the initialization routine failed?

(Note: target system is running .NET framework 2.0)

Unrelated to the loading problem, but you need to use `CallingConvention.Cdecl` in your p/invoke declarations, to match the C++ side. — Ben Voigt, Dec 18 '12 at 14:44

score 4 · Accepted Answer · answered Dec 18 '12 at 14:36

4

The DLL you are loading contains a DllMain() function. That's pretty common, such a function initializes the state of the DLL. Windows makes sure that this function is called whenever the DLL gets loaded, it will happen automatically the first time you pinvoke a function exported by that DLL.

Problem is, that function returned FALSE to indicate that it could not properly initialize the DLL. That of course does not give a wholeheckofalot of information about why it returned FALSE. Windows can't do anything but generate error 1114, ERROR_DLL_INIT_FAILED. If the DLL itself doesn't output any diagnostic then you can't do anything but debug the code. Start with Project + Properties, Debug tab, tick the "Enable unmanaged code debugging" option.

Fingers crossed that you see a message in the Output window. Odds are not very good. If you don't have the source code for the DLL then you'll need the help of the vendor or author of the DLL. Give him a copy of a test project that fails like this.

answered Dec 18 '12 at 14:36

Hans Passant

922,412
146
1,693
2,536

So the reason the init fails is because of the `DLLMain` return value? That's very useful. I do have the source code for the library, including the definition of `DLLMain`, though I cannot see how the function could possibly return a false value. – nicholas Dec 18 '12 at 14:44
1

There's one level of indirection if the code was written in C or C++, the real DllMain() that Windows calls is _DllMainCRTStartup(). Which initializes the CRT and calls initializers, then calls DllMain(). Failure of initializers will also cause a FALSE return value, you'd typically see an exception getting thrown. – Hans Passant Dec 18 '12 at 14:50
Is there any way to know which initializers are being called? – nicholas Dec 18 '12 at 15:06
I have examined the code but not exactly sure what I am looking for. I have the entire VS project file, and note that there is no entry point specified for the DLL - implying that it should invoke the default `DllMain`. As for debuggers, I do not know how to accomplish that - the target environment does not have development software installed (very limited RAM, CPU). Here is another thought: should I also look for `FALSE` return values from the libraries this one depends on? Even if the parent functions are never invoked, are the parent libraries loaded? – nicholas Dec 18 '12 at 21:46
Well I left this question open for a time, hoping additional information or tips would become available. I guess the short answer is "it's complicated" and that there is no one single way to troubleshoot these issues. – nicholas Jan 02 '13 at 17:12

score 0 · Answer 2 · answered Jan 12 '22 at 02:30

0

Maybe the reason is need to install old Net Framework version like 2.0, 3.0, 3.5,....it's worked for me :D

answered Jan 12 '22 at 02:30

Tuấn Anh Lê Quang

11
1
2

Wrapping a DLL - Understanding why Import Fails

2 Answers2