LoadLibrary 193

Question

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

Когда происходит вызов LoadLibrary, происходит сбой с ошибкой 193. Обычно это означает, что какой-то не 64-битный компонент пытается загрузить.Когда я смотрю на вывод загрузки dll в Visual Studio 2010, я вижу, что сбой происходит при загрузке mscoree.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 для описания импорта и экспорта, но это здесь не важно)

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

Это полный вывод из-за сбоя загрузки.

Примечание: DLL-файл C ++ / CLI называется 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, что приводит к той же ошибке загрузки, которую я видел из собственной сборки.

Answer 1

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

Answer 2

У меня просто есть похожий сценарий.Ошибка LoadLibrary с 193. Моя DLL является управляемой C ++ / CLI DLL, вызываемой из собственного приложения с LoadLibrary.

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

Я сузил его до класса thread_local.Похоже, win7 поддерживает только базовые типы, такие как указатели C, как thread_local.Все более сложное, даже std :: shared_ptr, которое принимает win10, генерирует ошибку 193 при загрузке Dll.

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