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
LVL 12
omegaomegaDeveloperAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

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

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
sarabandeCommented:
The Author found the mistake made by himself.

Sara
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
VB Script

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.