LoadLibrary 193

Question

Je crée un C ++ / CLI dll qui sera chargé dans une application héritée c ++. L'application héritée fait avec un appel traditionnel à LoadLibrary. L'application et la DLL C ++ / CLI sont compilés en mode 64 bits.

Lorsque l'appel LoadLibrary se produit, il échoue avec l'erreur 193. Ce généralement signifie que certains composants non-64bit tente de charger. Quand je regarde la sortie de charge dll en studio visuel 2010, je vois l'échec se produit lorsque mscoree.dll est chargé (pour être exact, je vois mon dll chargé, Mscoree chargé, puis Mscoree déchargé, puis mon dll déchargé , l'erreur renvoyée). Plus précisément C: \ Windows \ System32 \ mscoree.dll est chargé, quand j'examine ce mscoree.dll, je trouve qu'il vise I386.

Comment puis-je faire en sorte que ma demande lien contre la mscoree.dll correcte? Je comprends cela pourrait se faire avec un manifeste, mais je ne peux trouver aucune bonne information sur une mise en place. La solution idéale permettrait la compilation en mode 32bit ou 64bit et cibler le mscoree.dll correct.

Comme une note de côté, je l'ai trouvé un mscoree.dll dans un dossier côte à côte que je vérifiais est en mode 64 bits et recopié dans mon répertoire d'applications avec l'espoir qu'il ramasser ce premier. Ce travail n'a pas fonctionné et le répertoire C:. La version \ Windows \ System32 était encore chargé

Merci,

Max

Sortie de CorFlags.exe sur le 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

Sortie de pedump.exe sur 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 passe d'ici pour décrire non importants ici les importations et les exportations mais c'est à)

Informations de chargement prolongée

Ceci est la pleine puissance de la charge a échoué.

Note: C ++ / CLI dll est appelé DsfClr.dll
la sortie a été obtenue en exécutant Gflags.exe -i [exename] + sls et l'examen des résultats dans un débogueur

http://pastebin.com/FyumUiMN

MISE À JOUR:

En utilisant une pointe affichée dans un commentaire ci-dessous par Reuben, j'ai pu déterminer que mscoree.dll est en effet ciblage AMD64, mais pedump fournit des informations non valides parce qu'elle est en cours d'exécution dans WOW64. Cela étant dit, je ne peux toujours pas charger cette bibliothèque, si quelqu'un a des suggestions qu'ils seraient grandement appréciés.
Une chose que j'ai essayé: j'ai fait une nouvelle application C # et référencé C ++ / CLI dll, puis, dans la fonction principale (), j'instancié une classe dans le répertoire C ++ / CLI dll. Cela a provoqué une exception de violation d'accès avant que la fonction principale () est appelée. Lorsque je supprime l'instanciation, la fonction principale fonctionne très bien. Je pense que l'instanciation est à l'origine d'une charge de retard de mon assemblage C ++ / CLI, ce qui provoque la même erreur de charge que je voyais de l'ensemble natif.

Answer 1

exécute quelqu'un En cas à travers cette erreur, il est apparu qu'il a été causé par mes bibliothèques natives d'utiliser boost :: thread. La bibliothèque boost :: threading utilise des paramètres de compilation étranges. Le résultat est une bibliothèque statique qui est incompatible avec les binaires clr ou en mode mixte. Bien sûr, studio visuel n'a aucune idée de cela, il lie heureusement coup de pouce et se bloque lorsque le dll est chargé.
La solution est de lien dynamique en boost :: filetage. La meilleure façon de le faire est de définir BOOST_THREAD_DYN_LINK dans les paramètres du projet. Une fois que je définissais que, le dll chargé très bien.
Une recherche rapide Google de filetage boost C ++ / CLI donnera beaucoup plus d'informations sur cette erreur

Answer 2

I a juste un scénario similaire. LoadLibrary a échoué avec 193. Ma DLL est une DLL géré C ++ / CLI appelé à partir d'une application native avec LoadLibrary.

Cependant je reçois que l'erreur sur les systèmes de Win7. Il charge bien sur win10. La date de cette question originale donne à penser qu'il était win7.

Je réduit à une classe thread_local. Il semble win7 ne supporte que les types de base tels que les pointeurs C comme thread_local. Quelque chose de plus complexe, même std :: shared_ptr qui accepte win10, génère l'erreur 193 sur la charge dll.

Pour mémoire, le compilateur est VS2015 et le style de code est c ++ 11.