Устранение неполадок BadImageFormatException - PullRequest
92 голосов
/ 25 января 2012

У меня есть служба Windows, написанная на C # с использованием Visual Studio 2010 и предназначенная для полной версии .NET Framework 4. При запуске из сборки отладки служба запускается, как и ожидалось.Однако, когда я запускаю его из сборки Release, я получаю исключение System.BadImageFormatException (подробности ниже).Я искал решение в Интернете, но пока что все, что я нашел, не помогло мне найти решение.

Проблема существует как в Windows 7 64-bit (dev), так и в Windows XP32-разрядные (целевые) системы SP3.

Вот что я пробовал до сих пор:

  • Проверенные параметры сборки, такие как Platform Target, одинаковы (x86).
  • Используется peverify с параметром / verbose, чтобы убедиться, что двоичные файлы сборки действительны.
  • Использует fuslogvw для поиска проблем с загрузкой.
  • Используется CheckAsm для поиска отсутствующих файлов или сборок.

Все эти проверки ничего не изменили.Я включил полный текст информации об исключении ниже, с некоторыми именами, измененными, чтобы защитить секреты моих корпоративных мастеров.

System.BadImageFormatException was unhandled
  Message=Could not load file or assembly 'XxxDevices, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. An attempt was made to load a program with an incorrect format.
  Source=XxxDevicesService
  FileName=XxxDevices, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null
  FusionLog=Assembly manager loaded from:  C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll
Running under executable  c:\Dev\TeamE\bin\Release\XxxDevicesService.vshost.exe
--- A detailed error log follows. 

=== Pre-bind state information ===
LOG: User = XXX
LOG: DisplayName = XxxDevices, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null
 (Fully-specified)
LOG: Appbase = file:///c:/Dev/TeamE/bin/Release/
LOG: Initial PrivatePath = NULL
Calling assembly : XxxDevicesService, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null.
===
LOG: This bind starts in default load context.
LOG: Using application configuration file: c:\TeamE\bin\Release\XxxDevicesService.vshost.exe.Config
LOG: Using host configuration file: 
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework64\v4.0.30319\config\machine.config.
LOG: Policy not being applied to reference at this time (private, custom, partial, or location-based assembly bind).
LOG: Attempting download of new URL file:///c:/TeamE/bin/Release/XxxDevices.DLL.
ERR: Failed to complete setup of assembly (hr = 0x8007000b). Probing terminated.

  StackTrace:
       at XxxDevicesService.Program.Main(String[] args)
       at System.AppDomain._nExecuteAssembly(RuntimeAssembly assembly, String[] args)
       at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly()
       at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean ignoreSyncCtx)
       at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
       at System.Threading.ThreadHelper.ThreadStart()
  InnerException: 

Ответы [ 18 ]

114 голосов
/ 25 января 2012

Проверенные параметры сборки, такие как Platform Target, одинаковы (x86).

Это не то, что в журнале сбоев написано:

Менеджер сборки загруженfrom: C: \ Windows \ Microsoft.NET \ Framework64

Обратите внимание на 64 в названии, где находится 64-разрядная версия платформы.Установите настройку целевой платформы для вашего проекта EXE , а не для проекта библиотеки классов.Проект XxxDevicesService EXE определяет разрядность процесса.

36 голосов
/ 22 июня 2015

После того, как я перестал стучать головой по столу, думая о целой неделе, которую я потратил на решение этой проблемы, я делюсь тем, что сработало для меня. У меня Win7 64-битный, 32-битный Oracle Client, и мой проект MVC 5 настроен для работы на платформе x86 из-за битности Oracle. Я продолжал получать те же ошибки:

Не удалось загрузить файл или сборку «Oracle.DataAccess» или одну из ее зависимостей. Была предпринята попытка загрузить программу с неверным формат.

Я перезагрузил пакеты NuGet, я использовал копии библиотек DLL, которые работали для других в разных приложениях, я установил кодовую базу в зависимой сборке, чтобы она указывала на папку bin моего проекта, я попробовал CopyLocal как true или false, я пытался все. Наконец, у меня было достаточно всего, что я хотел проверить в своем коде, и, как новый подрядчик, у меня не было настроенной Subversion. Ища способ подключить его к VS, я споткнулся о ответ. Я обнаружил, что сработал, сняв флажок «Использовать 64-разрядную версию IIS Express для веб-сайтов и проектов» в разделе «Проекты и решения => Веб-проекты» в меню «Инструменты => Параметры».

18 голосов
/ 14 октября 2016

Что я нашел работающим, так это проверка опции «Использовать 64-разрядную версию IIS Express для веб-сайтов и проектов» в разделе «Проекты и решения => Веб-проекты» в меню «Инструменты => Параметры».

12 голосов
/ 11 апреля 2013

Обычно это может произойти, когда вы изменили целевую платформу .csproj и вернули ее обратно к тому, с чего начали.

Убедитесь, что 1, если supportRuntime version = "отличная среда выполнения от цели проекта cs" в теге запуска в app.config.

Убедитесь, что 2 Это также означает, что проверка других автоматически сгенерированных или других файлов может быть в папке свойств, чтобы увидеть, нет ли больше несоответствия времени выполнения между этими файлами и файлом, определенным в файле .csproj.

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

7 голосов
/ 02 апреля 2015

Вы также можете получить это исключение, когда ваше приложение предназначено для .NET Framework 4.5 (например), и у вас есть следующий app.config:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <startup>
    <supportedRuntime version="v2.0.50727" />
    <supportedRuntime version="v4.0" />
  </startup>
</configuration>

При попытке запустить отладку приложения вы будетеполучить BadImageFormatException.

Удаление строки, объявляющей версию v2.0, устранит ошибку.

Недавно у меня возникла эта проблема, когда я пытался изменить целевую платформу со старого проекта .NET 2.0.до .NET 4.5.

7 голосов
/ 18 июля 2013

У меня была такая же проблема, несмотря на то, что у меня 64-битная Windows 7, и я загружал 64-битную библиотеку DLL в свойствах проекта | Сборка у меня была проверена "Предпочитать 32-битный". (Не знаю, почему это установлено по умолчанию). Как только я снял галочку, все стало нормально

5 голосов
/ 09 марта 2016

Справочная информация

Мы начали получать это сегодня, когда мы переключили нашу службу WCF с AnyCPU на x64 на сервере Windows 2012 R2 с IIS 6.2.

Сначала мы проверилиединственная сборка, на которую ссылаются 10 раз, чтобы убедиться, что это не xll-библиотека x86.Затем мы много раз проверяли пул приложений, чтобы убедиться, что он не включает 32-битные приложения.

По какой-то причине я попытался переключить настройку.Оказывается, пулы приложений в IIS по умолчанию имеют значение Включить 32-разрядные приложения , равное False, но IIS по какой-то причине игнорирует его на нашем сервере и всегда запускает наш сервис в режиме x86.

Решение

  • Выберите пул приложений.
  • Выберите Установить значения по умолчанию для пула приложений ... или Расширенные настройки... .
  • Изменить Включить 32-разрядные приложения в True.
  • Нажмите OK .
  • Выбрать Установить значения по умолчанию для пула приложений ... или Дополнительные настройки ... снова.
  • Изменить Включить 32-разрядные приложения обратно в False.
  • Нажмите OK .
4 голосов
/ 08 мая 2015

Для тех, кто может приехать сюда позже ... У меня ничего не получалось. Все мои сборки были в порядке. У меня была конфигурация приложения в одном из моих проектов Visual Studio, которого не должно было быть. Поэтому убедитесь, что файл конфигурации вашего приложения необходим.

Я удалил дополнительную конфигурацию приложения, и она сработала.

4 голосов
/ 31 декабря 2014

Я исправил эту проблему, изменив веб-приложение на использование другого «пула приложений».

2 голосов
/ 24 июня 2015

При создании приложений для 32-разрядной или 64-разрядной платформы (мой опыт работы с Visual Studio 2010) не полагайтесь на Configuration Manager для установки правильной платформы для исполняемого файла. Даже если для приложения CM выбран x86, проверьте свойства проекта (вкладка «Сборка»): в нем все равно может быть «Любой процессор». И если вы запустите исполняемый файл «Любой ЦП» на 64-битной платформе, он будет работать в 64-битном режиме и откажется загружать сопутствующие библиотеки DLL, созданные для платформы x86.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...