Runtime error (dll loading) with win32 applications on x64 system, while compiling 0K
Asked Answered
S

1

5

I originally designed a win32 application on win7 32bits, with VC9.0. I recently upgraded to win7 64 bits, and tried to build+execute the previous application.

Building runs fine (win32 application), but on runtime I get the error "[...] has exited with code -1073741701 (0xc000007b)."

I guess this results of the loading of a 64bits version of an [intended] 32bits dll.

Specific dependencies for this project are: SDL.lib SDLmain.lib SDL_ttf.lib opengl32.lib glu32.lib wininet.lib

SDL and SDL_ttf are only in 32bits version. I assume that Visual Studio is clever enough to fetch the opengl and glu lib files in \syswow64 as I request a win32 application.

Could it be because of wininet? Or did I make a mistake?

Thanks,

Satinwood answered 21/3, 2011 at 0:10 Comment(3)
You guess? So you haven't actually tried debugging it? Have you at least checked it out with Dependency Walker?Duenas
That's STATUS_INVALID_IMAGE_FORMAT, you cannot load a 32-bit DLL into a 64-bit process. Cats and dogs.Barbur
Indeed it was a guess. I am quite a newbie, and not acquainted with this kind of issues. Cats and dogs, effectively.Satinwood
A
8

It appears you are loading a 64-bit DLL into a 32-bit process or vice versa. Here's how I would go about tracking down the offending DLL.

The first step is to run dumpbin.exe (use a VS command prompt to get it on the PATH) on the executable to ensure the architecture is what you expect: dumpbin.exe /headers foo.exe. In the file header output, you should see a "machine" value of "x86" or "x64". In the optional header output, you should see a magic of "PE32" (for x86) or "PE32+" (for x64).

The next step is to run the appropriate dependency walker, available at www.dependencywalker.com, depending on the architecture (x86 or x64) of the executable. This tool should tell you if it locates a dependency on the search paths that is not of the same architecture.

If dependency walker finds a problem, the fix would then be to replace the offending library with a library of the same architecture or ensure the correct library is located before the incorrect library based on search paths.

Adage answered 21/3, 2011 at 0:58 Comment(6)
Thanks for the tracking method. Dumpbin reports a machine value of x86, and a magic of PE32. Dependency walker reports that ZLIB1.dll for x64 architecture is loaded. How come? To be honest, I don't even know what this dll is for. May be you could shed a light on this? Thanks.Satinwood
I forgot, ZLIB1.dll (x64) is requested by LIBFREETYPE-6.dll (x86), accordign to what I see [and understand] in Dependency Walker.Satinwood
Where is zlib1.dll currently installed to? Try replacing it with a 32-bit version and see if that solves your problem.Adage
It was in ProgramFiles/Intel/Wifi/bin. Obviously replacing it with a 32-bit version did the trick. But I would have liked to know why this dll was asked for! Anyway, at least Dependency Walker pointed out the culprit. Then thanks!Satinwood
My guess is that this is just a normal dependency of something your application depends on. An installer likely modified the PATH to point at this directory (%ProgramFiles% is for 64-bit software; %ProgramFiles(x86)% is for 32-bit software) and you just happen to pick up the 64-bit version. You probably don't want to replace this library with the 32-bit version, as it will likely break something that depends on it. Instead, I'd just copy the 32-bit version local to your application. Shouldn't be anything to worry about.Adage
Thanks for your informations. I copied it locally, this is the safest indeed.Satinwood

© 2022 - 2024 — McMap. All rights reserved.