• Status: Solved
  • Priority: Low
  • Security: Public
  • Views: 65
  • Last Modified:

GetProcAddress returns zero (not a name mangling problem)

I'm converting an old 32 bit dotNet application for use in a 64 bit environment.  The application GUI is VB, and the computational side is comprised of a set of DLLs written in Fortran.  At run-time the GUI loads the appropriate DLL using LoadLibrary and then locates the appropriate Fortran routine by calling GetProcAddress with the handle returned by LoadLibrary and the name of the Fortran routine.

This works fine in the original 32 bit environment (Windows XP), but when running as a 64 bit application (Windows 10) GetProcAddress fails to find the named routine, returning zero, following which GetLastError reports #126.  I am aware that a very common cause of this problem is failure to be aware of C++ name mangling, and have very carefully checked the routine names in the DLL using both Dependency Walker and Dumpbin and these do match the name being provided to GetProcAddress.

Though I'm not sure that it's relevant, there is one thing that distinguishes the Dumpbin output of the 64 bit DLL from that of the 32 bit DLL.  In the former case the names are shown in the form NAME = NAME.  In the Dumpbin listing of the 32 bit DLL the "= NAME" is missing.  I have attached copies of these two Dumpbin listings for reference.

Any guidance that is offered on how to resolve this problem will be greatly appreciated.

Thanks,
Randy
Dump64.txt
Dump32.txt
0
omegaomega
Asked:
omegaomega
  • 3
  • 2
3 Solutions
 
sarabandeCommented:
generally, there is no way to calling a 32-bit dll from 64-bit executable.

so the only thing you can do is to replace the 32-bit dll by a 64-bit dll.

Sara
0
 
omegaomegaDeveloperAuthor Commented:
Thanks for the input Sara.  Actually, I'm aware of that and the DLL has already been converted to 64 bit.

Thanks,
Randy
0
 
sarabandeCommented:
it isn't fortran no longer? where is it located? if not in the same folder as the 64-bit app (what would be best) it should be in system32 folder.

the name mangling shouldn't be an issue beside that you have to omit the number suffix at the function name and use plain text (no wide characters) for GetProcAddress as you see them in the DUMPBIN. 64-bit has only one calling convention ==> so omit __stdcall or similar.
note, for LoadLibrary exist 2 versions LoadLibraryW and LoadLibraryA which take either wide or ansi character array.

Sara
0
 
omegaomegaDeveloperAuthor Commented:
Thanks for your suggestions.

This turned out to be a simple (stupid) problem.  Due to a missed type conversion during the switch to 64 bit code, the handle returned by LoadLibrary was being truncated to 32 bits prior to passing it to GetProcAddress.
0
 
sarabandeCommented:
The Author found the mistake made by himself.

Sara
0

Featured Post

Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

  • 3
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now