GetProcAddress returning NULL

Question

I'm trying to load a dll using LoadLibrary and GetProcAddress. LoadLibrary returns a valid handle but my calls to GetProcAddress return NULL. A call to GetLastError returns 87 which is ERROR_INVALID_PARAMETER. I verified that the function name I'm passing to GetProcAddress is the same as returned when running dumpbin /exports on the dll. Unfortuantely this is for work so I can't include the actual code. But here is an editted version to give you an idea of what I'm doing.

HINSTANCE hDLL = NULL;

hDLL = LoadLibrary(L"<PATH TO DLL>");

if (hDLL == NULL)
{
    // error handling code
}

g_var1 = (VAR1_TYPE) GetProcAddress(hDLL, L"Function1Name");
g_var2 = (VAR2_TYPE) GetProcAddress(hDLL, L"Function2Name");

if (!g_var1 ||
    !g_var2 )
{
    // error handling code
}

I've looked at a number of related questions on SO and other forums but typically the issue is due to C++ name mangling. Since I'm using the same name as what dumpbin shows I don't think this is my problem. Any ideas?

UPDATE

I think I may have narrowed down the issue. There is an existing older version of this dll on the target (this is an embedded WinCE solution). But I need to use a newer version of the dll that has some extra function I need; unfortuanatley I can't update the old dll. This new dll and the application using the dll are packed into a cab file which is loaded onto the target. I tried GetProcAddress with a couple of the functions in the old dll and those worked. So it seems that even though I'm calling LoadLibrary with the path to the new dll it's really just loading the dll that is already on the target. Can anyone confirm that this is what would happen?

ANSWER TO PREVIOUS QUESTION

When Windows CE loads a DLL, all path information is ignored when determining if the DLL is already loaded. This means that a DLL with the same name but a different path can only be loaded once. In addition, a module ending with the extension .cpl is treated as if the extension is .dll.

Source: http://msdn.microsoft.com/en-us/library/ms886736.aspx

Answer 1

Yes, that's a common pitfall. If you don't provide a full path for the DLL, LoadLibrary will return a handle to an already loaded DLL of the same name.

From MSDN:

If lpFileName does not include a path and there is more than one loaded module with the same base name and extension, the function returns a handle to the module that was loaded first.

I believe you can get the exact DLL you want by providing an absolute path to LoadLibrary.