Using MinGW-Builds to compile a 32-bit exe on a 64-bit system — compiles a 32-bit exe but links against 64-bit DLLs

1
votes

I am using MinGW-Builds to compile a 32-bit DLL and exe on a 64-bit system. I am using the m32 bit flag. The compilation and linkage stage produces no errors. When I try to run the program, I get:

The application was unable to start correctly (0xc000007b). Click OK to close the application.

I loaded up Dependency Walker and I got the following error message:

Error: Modules with different CPU types were found.

Indeed, Dependency walker shows that my DLL and executable are 32-bit. However, everything else it links against is 64-bit. For example, NTDLL.DLL, MSVCRT.DLL, LIBWINPTHREAD-1.DLL are all marked 64-bit. So, I believe I am not linking against the 32-bit DLLs correctly.

What is the command to get the linker to link against the 32-bit DLLs instead of the 64-bit DLLs?

Update

What exactly am I looking for when I run the 32-bit Dependency Walker profile mode? I get this output in the log window:

--------------------------------------------------------------------------------
Starting profile on 3/31/2014 at 10:14:41 PM

Operating System: Microsoft Windows NT/2000/XP/2003/Vista based Media Center (64-bit), version 6.01.7601 Service Pack 1
Program Executable: c:\mingw\msys\1.0\home\samuel\projects\bmd2\build\debug\32\testcore\BMD2TESTCORE.EXE
Program Arguments: 
Starting Directory: C:\MinGW\msys\1.0\home\samuel\projects\bmd2\build\debug\32\testcore\
Search Path: C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common;C:\MinGW\bin;C:\MinGW\libexec\gcc\x86_64-pc-mingw32\4.7.0;C:\Users\samuel\gcc\bin;C:\Users\samuel\gcc\libexec\gcc\x86_64-pc-mingw32\4.7.0;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files\Eclipse\adt-bundle\sdk\platform-tools;C:\Program Files\Eclipse\adt-bundle\sdk\tools;C:\Program Files (x86)\QuickTime\QTSystem\;C:\ant\bin;C:\Java\bin;C:\Program Files\TortoiseSVN\bin;C:\Users\samuel\Desktop\work\bmd2\build\debug\lib

Options Selected:
     Simulate ShellExecute by inserting any App Paths directories into the PATH environment variable.
     Log DllMain calls for process attach and process detach messages.
     Log DllMain calls for all other messages, including thread attach and thread detach.
     Hook the process to gather more detailed dependency information.
     Log LoadLibrary function calls.
     Log GetProcAddress function calls.
     Log thread information.
     Use simple thread numbers instead of actual thread IDs.
     Log first chance exceptions.
     Log debug output messages.
     Log a time stamp with each line of log.
     Automatically open and profile child processes.
--------------------------------------------------------------------------------

00:00:00.000: Started "BMD2TESTCORE.EXE" (process 0x1DC) at address 0x00400000 by thread 1.  Successfully hooked module.
00:00:00.000: Loaded "NTDLL.DLL" at address 0x778C0000 by thread 1.  Successfully hooked module.
00:00:00.031: Loaded "KERNEL32.DLL" at address 0x75510000 by thread 1.  Successfully hooked module.
00:00:00.031: Loaded "KERNELBASE.DLL" at address 0x77340000 by thread 1.  Successfully hooked module.
00:00:00.031: DllMain(0x77340000, DLL_PROCESS_ATTACH, 0x00000000) in "KERNELBASE.DLL" called by thread 1.
00:00:00.031: DllMain(0x77340000, DLL_PROCESS_ATTACH, 0x00000000) in "KERNELBASE.DLL" returned 1 (0x1) by thread 1.
00:00:00.031: DllMain(0x75510000, DLL_PROCESS_ATTACH, 0x00000000) in "KERNEL32.DLL" called by thread 1.
00:00:00.046: DllMain(0x75510000, DLL_PROCESS_ATTACH, 0x00000000) in "KERNEL32.DLL" returned 1 (0x1) by thread 1.
00:00:00.046: Injected "DEPENDS.DLL" at address 0x08370000 by thread 1.
00:00:00.078: DllMain(0x08370000, DLL_PROCESS_ATTACH, 0x00000000) in "DEPENDS.DLL" called by thread 1.
00:00:00.093: DllMain(0x08370000, DLL_PROCESS_ATTACH, 0x00000000) in "DEPENDS.DLL" returned 1 (0x1) by thread 1.
00:00:00.093: Loaded "MSVCRT.DLL" at address 0x75C90000 by thread 1.  Successfully hooked module.
2
c++windowsdllcompiler-constructionmingw
Don't you need to build with a manifest file, so that when the application loads, it knows which version of the DLL's to use? Windows does not differentiate between a 32 or 64-bit DLL if they have the same name. The OS will attempt to load the first one it finds, and will give you that error if the module fails to load due to the module being the wrong "bitness". (Note -- I am a Visual Studio user, not MingW, but it should be the same sort of setup) - PaulMcKenzie
To prove my point, just for kicks, copy those 32-bit DLL's to a local directory along with your program. I bet your program starts normally without the error. - PaulMcKenzie
I'm not sure this is the actual source of the problem in your case. This is a screenshot of Dependency Walker from my 32-bit program, as you can see it also shows and complains about 64-bit DLLs but the program works fine. - user2802841
I think it's a manifest issue, or more on a basic level, a DLL module search issue when the program loads. Basically Windows uses the LoadLibrary algorithm for module searching, and attempts to load the first one it finds that matches the name -- msdn.microsoft.com/en-us/library/windows/desktop/… That's why we developers name our DLL's differently if we have 32-bit and 64-bit versions (or at least I hope most do). Why Windows went this route of naming their 32 and 64-bit DLL's the same, I don't know... - PaulMcKenzie
@DavidHeffernan - To each his own. I feel it's easier to deal with DLL's that are named MyDLL32.dll and MyDLL64.dll then to have identical names. - PaulMcKenzie

2 Answers

1
votes

You don't specify the bitness of a DLL when you link against it. You merely specify the name of the DLL. It's up to the loader to find the DLLs with the names that you have specified.

Two of the DLLs that you name, ntdll and msvcrt, are system components. They reside in the system32 directory. Your 32 bit process is subject to the file system redirector. That means that when the loader looks in system32, the redirector silently maps that to syswow64, the 32 bit system directory. That happens transparently so the loader will find 32 bit versions of ntdll and msvcrt.

The error code that you report is 0xC000007B. That is an NTSTATUS error code. Specifically STATUS_INVALID_IMAGE_FORMAT. Which is indeed the error reported when you attempt to load a 64 bit DLL in a 32 bit process. So it seems likely that this is what is happening.

You've done some debugging with Dependency Walker. This is an excellent tool for the job, but in the mode you have used it in (static mode) it does sometimes report false positives. It sounds like you are using the 64 bit version of Dependency Walker. You might get better diagnostics with the 32 bit version.

All that said, what you really need to do is to run your program under the Profile mode of Dependency Walker. That can be found under the Profile menu. When you do this you'll get a stream of diagnostics from the loader, including the name of the DLL that failed to load with error STATUS_INVALID_IMAGE_FORMAT. At that point it should become clear what has gone wrong.

1
votes

You're using Dependency Walker wrong.

The 64-bit version of Dependency Walker isn't smart enough to search the 32-bit DLL paths (David's answer explains how these actually get used when your program runs, via redirection).

You need to use the 32-bit Dependency Walker for analyzing 32-bit code.