Debugging load time error in C++ SDL2 program compiled with VS2015 on Win10

Question

I'm writing a project in C++ with SDL2 on 64-bit Windows 10 using Visual Studio 2015. I recently purchased a new Windows 10 laptop and cloned my project from github. My project compiles correctly, but I get the following error when I run it:

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

Based on my research so far, this error is usually caused by loading an incompatible DLL, e.g. a 64-bit version instead of 32-bit. Suggestions I've found so far include:

• Checking that I'm using the 32-bit versions of the SDL2 DLLs
• Installing/reinstalling the x86 version of the Visual C++ Redistributable for Visual Studio 2015
• Using Dependency Walker to troubleshoot which DLL is failing

My project is set to build for Win32, and I've ensured that I'm using the 32-bit versions of all DLLs I'm explicitly linking (libfreetype-6, libpng16-16, SDL2, SDL2_image, SDL2_mixer, and SDL2_ttf). I have confirmed that the x86 VC++ Redistributable is installed on my machine.

Finally, I've attempted to use Dependency Walker to determine what DLL might be causing the problem (although I've read caveats that Dependency Walker has a lot of false positives). These were the results:

Dependency Walker static analysis

Dependency Walker profiling results

After that point, the profiler freezes and never continues. Note that the SDL components and the VC runtime are loading without error.

The program compiles and loads correctly on my two older machines, one running 32-bit Windows 7 and one running 64-bit Windows 10.

Now for the actual question. What other steps can I take to debug this crash? Or does anyone see from the information I've provided what I'm doing wrong?

Related questions:

• The application was unable to start correctly (0xc000007b)
• Win 7, 64 bit, dll problems
• Using SDL_image in Visual studio 2010, with error "application was unable to start correctly 0xc000007b"

Edit:

As rflobao suggested, I was using the 64-bit version of Dependency Walker on a 32-bit exe. Here is the new output of my profiling run:

At this point, as before, Dependency Walker freezes. I'm still totally lost and don't feel like I'm any closer to being able to determine what's causing the problem.

Answer 1

Note that Dependency Walker has 32 and 64 bit version. If your application is 32-bit you should use the 32 bit version. Otherwise the Dependency Walker will see the libs to System32 and not SisWOW64. You image show 32bit and 64bit libs mixed, where 64 has error.

Answer 2

This is by no means completely reliable, but you can give it a try. It requires dumpbin.exe, which is included with Visual Studio.

First, get a list of dependent DLLs for your program, resolved against your path:

del dlls.txt
for /f %d in ('dumpbin /dependents Questless.exe ^| findstr /ic:".dll"') do @echo %~$PATH:d >> dlls.txt

Then get the bitness of each:

for /f "delims=" %d in (dlls.txt) do @echo %d & dumpbin /headers "%d" | findstr /c:"machine (x"

This will produce output like:

C:\Windows\System32\kernel32.dll
            8664 machine (x64)
C:\programs\ed23\bin\hydra.dll
             14C machine (x86)

Note that this is incorrectly using the kernel32.dll from System32, rather than the WOW6432 one, so it shows that as x64. That's because it just used the path, when the Windows loader will actually use the WOW6432 mapper, SxS, the application manifest, and only fall back on the path if none of those resolve the dependency. It also doesn't find dependents of dependents (you could script recursing through the dependents, but be sure to filter out duplicates), and of course doesn't know anything about run-time explicit dynamic loads.

Nevertheless, it's a quick way to get a short list to check, and might identify your problem.

Answer 3

I feel profoundly dumb, but I finally figured out the real problem. I'm using the SDL font library SDL2_ttf, and I simply hadn't copied zlib.dll from the SDL2_ttf lib directory into my build directory. I don't understand why the error message was so cryptic; in the past missing DLLs have given me a helpful "foo.dll is missing" error message.

Anyway, thank you all for your help. At least I've learned a useful lesson: always make sure all the required DLLs are present before suspecting a more complex problem.