質問

レガシーC ++アプリケーションにロードされるC ++/CLI DLLを作成しています。 Legacyアプリケーションは、従来のLoadLibraryへの呼び出しでこれを行います。アプリケーションとC ++/CLI DLLの両方が64ビットモードでコンパイルされます。

LoadLibrary Callが発生すると、エラー193で失敗します。これは通常、一部の非64ビットコンポーネントがロードしようとしていることを意味します。 Visual Studio 2010のDLLロード出力を見ると、mscoree.dllがロードされているときに障害が発生していることがわかります（正確には、dllがロードされ、mscoreeがロードされ、mscoreeがアンロードされ、dllがアンロードされます。 、エラーが返されました）。具体的には、c： windows system32 mscoree.dllがロードされています。このmscoree.dllを調べると、i386をターゲットにしていることがわかります。

アプリケーションが正しいMscoree.dllに対してリンクすることを確認するにはどうすればよいですか？これはマニフェストで行われる可能性があることを理解していますが、セットアップに関する良い情報は見つかりません。理想的なソリューションにより、32ビットまたは64ビットモードでのコンパイルが可能になり、正しいMscoree.dllをターゲットにします。

サイドノートとして、私は64ビットモードであることを確認した並んでいるフォルダーにmscoree.dllを見つけ、それを最初にピックアップすることを期待してアプリケーションディレクトリにコピーしました。これは機能せず、C： Windows System32バージョンはまだロードされていました。

ありがとう、

マックス

c ++/cli dll上のcorflags.exeの出力

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

c： system32 mscoree.dll上のpedump.exeの出力

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

アップデート：

Reubenが以下のコメントに投稿したヒントを使用して、Mscoree.dllが実際にAMD64をターゲットにしていると判断することができましたが、PedumpはWOW64で実行されているため、無効な情報を提供しています。とはいえ、私はまだこのライブラリをロードすることはできません。
もう1つ試したことがあります。新しいC＃アプリケーションを作成し、C ++/CLI DLLを参照し、メイン（）関数で、C ++/CLI DLLにクラスをインスタンスしました。これにより、メイン（）関数が呼び出される前にアクセス違反例外が発生しました。インスタンスを削除すると、メイン関数は正常に実行されます。私の推測では、インスタンス化により、C ++/CLIアセンブリの遅延負荷が発生しているため、ネイティブアセンブリから見たのと同じ負荷エラーが発生します。

役に立ちましたか？

解決

誰かがこのエラーを実行した場合、それは私のネイティブライブラリがBoost :: Threadingの使用によって引き起こされたことが判明しました。ブースト::スレッディングライブラリは、奇妙なコンピレーション設定を使用しています。結果は、CLRまたは混合モードバイナリと互換性のない静的ライブラリです。もちろん、Visual Studioにはこれについてはわかりませんので、DLLがロードされたときにブーストをリンクしてクラッシュします。
解決策は、Boost :: Threadingで動的にリンクすることです。これを行う最も簡単な方法は、プロジェクト設定でboost_thread_dyn_linkを定義することです。それを定義すると、DLLは正常にロードされました。
C ++/CLIブーストスレッドをすばやく検索すると、このエラーに関する詳細情報が得られます

他のヒント

同様のシナリオがあります。 LoadLibraryは193で失敗しました。私のDLLは、LoadLibraryを使用したネイティブアプリケーションから呼び出される管理されたC ++/CLI DLLです。

ただし、Win7システムでのみエラーが発生します。 Win10には問題ありません。この元の質問の日付は、それがWin7であったことを示唆しています。

Thread_Localクラスに絞り込みました。 win7は、sward_localなどのcポインターなどの基本タイプのみをサポートしているようです。より複雑なものはすべて、win10が受け入れるSTD :: Shared_ptrでさえ、DLLロードでエラー193を生成します。

レコードの場合、コンパイラはVS2015で、コードスタイルはC ++ 11です。

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top