Вопрос

Я создаю DLL C ++/CLI, который будет загружен в устаревшее приложение C ++. Унаследованное приложение делает это с традиционным вызовом для LoadLibrary. И приложение, и C ++/CLI DLL собираются в 64 -битном режиме.

Когда происходит вызов LoadLibrary, он сбой с ошибкой 193. Это обычно означает, что какой-то не 64-битный компонент пытается загрузить. Когда я смотрю на выход на нагрузку DLL в Visual Studio 2010, я вижу, что сбой возникает, когда загружается mscore.dll (если быть точным, я вижу загруженный DLL, затем загружается MSCOREE, затем MSCOREE выгружен, затем мой DLL выгружен , затем ошибка вернулась). В частности, C: Windows System32 MSCOREE.DLL загружается, когда я изучаю этот mscoree.dll, я обнаружил, что он нацелен на i386.

Как я могу убедиться, что мое приложение будет связано с правильным mscoree.dll? Я понимаю, что это может быть сделано с манифестом, но я не могу найти хорошую информацию о том, чтобы настроить ее. Идеальное решение позволит компиляцию в 32 -битном или 64 -битном режиме и нацеливаться на правильный MSCOREE.DLL.

В качестве примечания я обнаружил, что MSCOREE.DLL в папке бок о бок, который, как я проверил, представляет собой 64-битный режим и скопировал его в каталог моего приложения с надеждой, что он сначала поднимет один. Это не сработало, и версия C: Windows System32 все еще была загружена.

Спасибо,

Максимум

Вывод corflags.exe на C ++/CLI DLL

Microsoft (R) .NET Framework CorFlags Conversion Tool.  Version  4.0.30319.1
Copyright (c) Microsoft Corporation.  All rights reserved.

Version   : v4.0.30319
CLR Header: 2.5
PE        : PE32+
CorFlags  : 16
ILONLY    : 0
32BIT     : 0
Signed    : 0

Вывод Pedump.exe на C: System32 mscoree.dll

PS C:\Windows\System32> pedump.exe .\mscoree.dll
Dump of file .\MSCOREE.DLL

File Header
  Machine:                      014C (I386)
  Number of Sections:           0004
  TimeDateStamp:                4B90752B -> Thu Mar 04 22:06:19 2010
  PointerToSymbolTable:         00000000
  NumberOfSymbols:              00000000
  SizeOfOptionalHeader:         00E0
  Characteristics:              2102
    EXECUTABLE_IMAGE
    32BIT_MACHINE
    DLL
...

(Pedump продолжается отсюда, чтобы описать импорт и экспорт, но здесь это не важно)

Расширенная информация о загрузке

Это полный выход из неудачной нагрузки.

Примечание. C ++/CLI DLL называется dsfclr.dll
Вывод был получен путем запуска gflags.exe -i [exename] +sls и изучения результатов в отладчике

http://pastebin.com/fyumuimn

ОБНОВИТЬ:

Используя наконечник, опубликованный в приведенном ниже комментарии Рубена, я смог определить, что MSCOREE.DLL действительно нацелен на AMD64, но Pedump предоставляет недопустимую информацию, потому что он работает в WOW64. При этом я до сих пор не могу загрузить эту библиотеку, если у кого -то есть какие -либо предложения, они будут очень оценены.
Еще одна вещь, которую я попробовал: я сделал новое приложение C# и ссылался на DLL C ++/CLI, тогда в функции Main () я создал класс в DLL C ++/CLI. Это вызвало исключение по нарушению доступа до того, как была вызвана функция Main (). Когда я удаляю экземпляр, основная функция работает нормально. Я предполагаю, что экземпляр вызывает задержку нагрузки моей сборки C ++/CLI, что вызывает ту же ошибку нагрузки, которую я видел из нативной сборки.

Это было полезно?

Решение

В случае, если кто -то работает по этой ошибке, оказалось, что это было вызвано использованием моих родных библиотек Boost :: Threading. Библиотека Boost :: Threading использует некоторые странные настройки компиляции. Результатом является статическая библиотека, которая несовместима с CLR или двоичными файлами смешанного режима. Конечно, Visual Studio не имеет представления об этом, поэтому она с радостью связывает усиление и сбои при загрузке DLL.
Решение состоит в том, чтобы динамически ссылаться в Boost :: Threading. Самый простой способ сделать это - определить boost_thread_dyn_link в настройках вашего проекта. Как только я определил это, DLL загружен нормально.
Быстрый поиск в Google в потоке CLI Boost даст больше информации об этой ошибке

Другие советы

У меня просто похожий сценарий. LoadLibrary не удалась с 193. My DLL - это управляемый C ++/CLI DLL, вызванный из нативного приложения с LoadLibrary.

Однако я получаю ошибку только в системах Win7. Он хорошо загружается на Win10. Дата этого первоначального вопроса предполагает, что это был Win7.

Я сузил его до класса Threat_local. Похоже, Win7 поддерживает только основные типы, такие как указатели C как Thread_local. Что -нибудь более сложное, даже std :: shared_ptr, который принимает win10, генерирует ошибку 193 при нагрузке DLL.

Для записи компилятор - VS2015, а стиль кода - C ++ 11.

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top