Ошибка времени загрузки отладки в программе C++ SDL2, скомпилированной с VS2015 на Win10

Я пишу проект на C++ с SDL2 на 64-разрядной Windows 10 с использованием Visual Studio 2015. Недавно я купил новый ноутбук для Windows 10 и клонировал свой проект с github. Мой проект компилируется правильно, но при запуске я получаю следующую ошибку:

Приложение не удалось запустить правильно (0xc000007b). Нажмите кнопку ОК, чтобы закрыть приложение.

Основываясь на моих исследованиях до сих пор, эта ошибка обычно вызвана загрузкой несовместимой DLL, например, 64-разрядной версии вместо 32-битного. Предложения, которые я нашел до сих пор, включают:

  • проверка того, что я использую 32-разрядные версии библиотек DLL SDL2
  • установка и переустановка x86-версии распространяемого пакета Visual C++ для Visual Studio 2015
  • Через зависимость Уокер, чтобы определить, какие библиотеки DLL не

Мой проект настроен на сборку для Win32, и я гарантировал, что использую 32-разрядные версии всех библиотек DLL, которые я явно связываю (libfreetype-6, libpng16-16, SDL2, SDL2_image, SDL2_mixer и SDL2_ttf). Я подтвердил, что на моей машине установлен распространяемый пакет x86 VC++.

Наконец, я попытался использовать Dependency Walker, чтобы определить, какая DLL может быть причиной проблемы (хотя я читал предостережения, что Dependency Walker имеет много ложных срабатываний). Таковы были результаты:

Зависимость статического анализа Уокера Статический анализ Уокера зависимостей

Профилирование Уокера зависимостей результаты Результаты профилирования Уокера зависимостей

После этой точки профилировщик зависает и никогда не продолжает работу. Обратите внимание, что компоненты SDL и среда выполнения VC загружаются без ошибок.

Программа компилируется и загружается правильно на двух моих старых машинах, одна из которых работает под управлением 32-разрядной Windows 7 и одна под управлением 64-разрядной Windows 10.

Теперь собственно вопрос. Какие еще шаги я могу предпринять для отладки этого сбоя? Или кто-нибудь видит из предоставленной мной информации, что я делаю неправильно?

Сопутствующие вопросы:

Правка:

Как и предполагал rflobao, я использовал 64-разрядную версию Dependency Walker на 32-разрядном exe. Вот новый результат моего профилирования выполнить:

Новый Вывод Профиля Уокера Зависимостей

В этот момент, как и раньше, зависимость Walker замирает. Я все еще в полной растерянности и не чувствую себя ближе к тому, чтобы определить, в чем причина проблемы.

3 10
c++ visual-studio-2015 windows-10 sdl-2

3 ответа:

Обратите внимание, что Dependency Walker имеет 32-и 64-разрядную версию. Если ваше приложение 32-разрядное, вы должны использовать 32-разрядную версию. В противном случае программа Dependency Walker будет видеть библиотеки System32, а не SisWOW64. Вы показываете изображение 32-битных и 64-битных библиотек, смешанных, где 64 имеет ошибку.

5

Это ни в коем случае не является полностью надежным, но вы можете попробовать. Для этого требуется помойка.exe, который входит в состав Visual Studio.

Во-первых, получите список зависимых библиотек DLL для вашей программы, разрешенных по вашему пути: 

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

Затем получаем битность каждого: 

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

Это приведет к следующему результату: 

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

Обратите внимание, что это неверное использование kernel32.dll из System32, а не из WOW6432, поэтому он показывает, что как x64. Это потому, что он просто использовал путь, когда загрузчик Windows будет фактически использовать wow6432 mapper, SxS, манифест приложения и только отступит на путь, если ни один из них не разрешит зависимость. Он также не находит иждивенцев иждивенцев (вы можете написать сценарий рекурсии через иждивенцев, но обязательно отфильтруйте дубликаты) и, конечно, ничего не знает о явных динамических нагрузках во время выполнения.

Тем не менее, это быстрый способ получить короткий список, чтобы проверить, и может определить вашу проблему.
4

Я чувствую себя полным идиотом, но в конце концов понял, в чем дело. Я использую библиотеку шрифтов СДЛ SDL2_ttf, и я просто не скопировал эту библиотеку.dll из каталога sdl2_ttf lib в мой каталог сборки. Я не понимаю, почему сообщение об ошибке было таким загадочным; в прошлом отсутствующие библиотеки DLL дали мне полезный " фу.dll отсутствует " сообщение об ошибке.

В любом случае, спасибо всем за вашу помощь. По крайней мере, я усвоил полезный урок: всегда убедитесь, что все необходимые библиотеки DLL присутствуют перед тем, как подозревая более сложную проблему.
2