1

I have a problem with GetProcAddress: I wrote a simple DLL with just one function in it:

extern "C" LRESULT WINAPI Function(HWND Hwnd, UINT Message,
                                   WPARAM wParam, LPARAM lParam)
{
    Beep(1000, 1000);
    return CallNextHookEx(0, Message, wParam, lParam);
}

When I try to get function's address GetProcAddress fails with the ErrorCode 127 (ERROR_PROC_NOT_FOUND). However, if I use void as the function type it works perfectly. I can't really figure out why it behaves like this. Any suggestions would be greatly appreciated!

BTW: DependencyWalker shows that the function's name is indeed "Function" no changes have been applied.

dllloader
  • 11
  • 1
  • 2

2 Answers2

4

There are only two failure modes for GetProcAddress:

  • you didn't export the function
  • you didn't get the name right

The exported named of this function is not "Function" unless you used a .def file to rename the export or created a 64-bit DLL. It will be "_Function@16" for a 32-bit build. The @16 postfix would be strongly associated with the fact that you have trouble making it work for functions with any arguments.

From the Visual Studio Command Prompt run Dumpbin.exe /exports on your DLL to see the exports. Delete a .pdb file in the same directory if there is one.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
  • Hm, tried importing "_Function@16", "_Function@32" and "_Function@64", but it didn't work.... I experimented a litte and now it gets really weird. When I change the functions type from LPARAM WINAPI to void, GetProcAddress works fine for all function names, even stuff like "abc" although those functions don't exist! If I use the original type though GetProcAddress doesn't work! – dllloader Jul 01 '11 at 12:46
  • Not using WINAPI makes a *big* difference, that disables __stdcall and stops the @ postfix. Running dumpbin.exe /exports is essential to find the real name, don't skip it. – Hans Passant Jul 01 '11 at 12:53
  • I'm using Code::Blocks together with MinGW64, so I'm not able to; are there any alternatives? – dllloader Jul 01 '11 at 13:13
  • Just ran DependencyWalker again with the current DLL and now it showed "Function@16" (without "_"). I tried importing that and it worked. I have one question left though: Why does my function run in 16bit? – dllloader Jul 01 '11 at 13:16
  • It doesn't. @16 is the size of the stack activation frame. 4 arguments that are each 32 bits (4 bytes), 4 x 4 = 16. – Hans Passant Jul 01 '11 at 13:18
2

It's good idea to use module definition (.def file) with names of exported functions instead of __declspec(dllexport). It's much easier to manage them.

Also this

#define DllExport extern "C" __declspec (dllexport)

causes that exported dll function names are without any c++ "decorations"

Jakub C
  • 595
  • 1
  • 5
  • 14