Альтернативная причина BadImageFormatException в блоке.NET?
Я работаю над.NET 3,5 консольных приложения в C#, который использует VC ++ неуправляемый DLL. Это работало без проблемы, когда я работал над ним несколько недель назад, но я возвращаюсь к нему сегодня и теперь добираюсь, BadImageFormatException ("Попытка был сделан загрузить программу неверным форматом. (Исключение из HRESULT: 0x8007000B)).
Моя рабочая станция разработки запускает Windows 7 на 64 бита, и я делаю изрядный объем работы с неуправляемым кодом, таким образом, я сразу проверил, что блок.NET и библиотека VC ++ оба имели цели x86. Они сделали.
Только, чтобы быть уверенным, я убрал и восстановил библиотеку VC ++ и блок.NET, напрасно.
Никакая система не делает ничего особенно необычного. Библиотека VC ++ загружает файл двоичных данных и делает некоторую математическую обработку на ее содержании. Блок.NET имеет DllImports для библиотеки и некоторого кода для обеспечения электричеством его. Это все работало несколько недель назад.
Таким образом, теперь меня оставляют, задаваясь вопросом, существует ли некоторая другая причина BadImageFormatException, это менее распространено, чем конфликт x86/x64, с которым я мог бы сталкиваться.
Спасибо.
Править: Я получаю ту же ошибку независимо от x86 или x64 режима, но, когда установлено на 'Любой ЦП', выполнение заканчивает ту точку, но аварийные прекращения работы выполнения на более позднем вызове к библиотеке VC ++ без исключения. Независимо от того, связано ли это с этой проблемой, есть ли что-то, что 'Какой-либо ЦП' делает и по-другому по сравнению с x86 и по-другому по сравнению с x64, который мог пролить некоторый свет на это?
4 ответа
Учитывая, что вы используете родной код, я думаю, что наиболее вероятная проблема заключается в том, что вы пытаетесь загрузить родную DLL так, как будто это сборка .Net. Это один из сценариев, который вызовет BadImageFormatException.
Попробуйте запустить свое приложение и настроить его на прерывание при броске для BadImageFormatException и посмотрите, какая DLL загружается. Если это нативная DLL, то проблема в ней.
Когда я получаю эту ошибку, она всегда вызвана загрузкой 32-битной DLL в 64-битный процесс.
Установите в EXE-файле компиляцию в x86 и посмотрите, работает ли это.
Возможно, вы пытаетесь загрузить сборку, созданную для CLR 4.0, на CLR 2.0.
Проверьте конфликт загрузки .dll!
Я вызывал C++/CLI dll из C#; библиотека C++/CLI - это обертка вокруг сторонней нативной dll.
Оказалось, что у меня было две dll с одинаковым именем, обе в пути (libeay32.dll).
Чтобы обнаружить источник проблемы, я установил инструменты отладки windows:
https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/debugger-download-tools
Старая ссылка: http://www.microsoft.com/whdc/devtools/debugging/default.mspx
Запустите 'gflags' (в папке "c:\Program Files\Debugging Tools . . ."), чтобы включить отображение "привязок" загрузчика
т.е.
> gflags -i <my test app.exe> +sls
затем запустите приложение в cdb (консольный отладчик) или windbg и просмотрите вывод, чтобы выяснить, какая dll вызвала исключение.
например,
> cdb -g <my test app.exe>
Переименование "неправильной" libeay32.dll устранило проблему, но это лишь временное решение!
Тот же подход к поиску неисправностей может сработать и для вас.