Вызов DLL-библиотеки x86 из целевого приложения VS 2010 / DotNet 4.0 x86

Question

Я получаю 'AccessViolationException' 'Попытка чтения или записи защищенной памяти' при вызове метода в dll x86 при работе на платформе x64 (Windows 7). Все отлично работает на платформах x86.

Я прочитал много-много постов о похожих проблемах, но не смог заставить мой код работать.

Я пытаюсь заставить наше старое приложение x86 успешно работать на Windows 7 (x64) и Server 2008 R2 (x64). Приложение представляет собой ассортимент VB6, VB.Net, C #, MicroFocus COBOL и C ++. (Мы не могли придумать другие языки, которые можно было бы добавить в то время). Код DotNet изначально был написан в Visual Studio 2003 для DotNet 1.1. Я портировал код до Visual Studio 2010 и DotNet 4.0. Я установил цель для всех проектов на x86. Когда я звоню в неуправляемые 32-битные библиотеки DLL, я получаю вышеуказанную ошибку.

Наша процедура установки InstallShield устанавливает библиотеки x86 в C: \ Windows \ sysWOW64 вместо C: \ Windows \ System32. Такое поведение кажется правильным. DLL - это некоторый объектный код COBOL и компоненты времени выполнения, связанные вместе в dll «стиль C». Я не думаю, что проблема связана с COBOL или процессом связывания, так как я также перенес пример приложения из Code Project с приложением VB.Net WinForms, которое вызывает простой C ++ dll, все ориентированные на x86. Я получаю ту же ошибку там. Я также пытался создать приложение командной строки C ++ для вызова DLL. Загрузка библиотеки выполнена успешно. GetProcAddress успешно завершен. Вызов указателя функции для конкретного метода завершается неудачно. Наши приложения VB6 могут вызывать DLL просто отлично при работе на Windows 7 x64. Я также попытался отключить UAC и задать для параметра visibleExecutionLevel в манифесте значение максимально допустимое. Я пытался работать от имени администратора.

Похоже, это должно работать, но не уверен, что попробовать дальше. Есть идеи?

Answer 1

Хорошие новости,

Мы исследовали DEP как возможную причину проблемы, поскольку увидели, что даже наш код VB6 не будет работать, когда DEP включен.Мы заметили, что код VB.Net не срабатывал так же, как и VB6, когда был включен DEP.По-видимому, наши DLL на языке COBOL делают что-то, что не устраивает DEP.К сожалению, сборки DotNet, похоже, не соответствуют настройке DEP операционной системы, поэтому вы должны отключить DEP с помощью editbin.exe:

editbin.exe / nxnocompat: нет

Я все ещенужно протестировать его в нашем полном приложении, но похоже, что у нас есть решение!

Answer 2

На x64 .net программы будут работать как 64-битные программы и не могут вызывать 32-битные DLL.

Попробуйте скомпилировать приложение с целевым x86 вместо «Any Target». Вы также можете заставить цель встроенного .exe с утилитой .Net CorFlags.exe для запуска в 32-битном режиме.

Конечно, ваша программа будет работать в 32-битной среде, особенно она будет иметь максимум 2 ГБ ОЗУ.