問題タブ [loadlibrary]

ここに私の問題があります。同じ DLL の 2 つの別個のインスタンスを作成したいと考えています。

以下は、Handle1 と Handle2 が同じアドレスを取得するため機能しません。

以下は機能しますが、DLL のコピーを作成し、別の名前に変更する必要があります (これは少しばかげているようです)。

DLL ファイルは 1 つだけにして、その複数のインスタンスをロードする方法はありますか?

アプリの起動時に表示される説明のないエラーメッセージ「割り当てを設定できません」について、お客様からの不定期の報告に数年間悩まされてきました。これまで、独自のテスト環境で問題を再現することはできませんでした。私は今、これを追跡しようとするためのアイデアを使い果たしました。これは、時間の経過とともに蓄積された観測のコレクションです。

• エラーメッセージテキストには、「割り当てを設定できません」と表示されます（句読点がないことに注意してください）。
• ウィンドウのタイトルは単に「エラー」（またはローカライズされた同等のもの）と表示されます。
• 「割り当てを設定できません」というテキストは、OSのロケールに関係なく、常に英語で表示されます。

• これまでのところ、メッセージテキストを含むDLLまたはEXEを見つけることができませんでした。

• Googleは、さまざまな製品に関するこのエラーの報告でいっぱいですが、解決策はありません。

• 私がこれまでに理解できた影響を受けた製品間の唯一の統一的な側面は、それらがすべてサードパーティのプロセス（VisualStudioやWindowsExplorerシェル拡張機能のアドインなど）に読み込まれるDLLの形式で提供されているように見えることでした。

• 私たちのアプリは、実際にはDelphiで記述されたMS Outlook用のシェアウェアCOMアドインです（つまり、ネイティブコード-.NETなし）。

• 私たちの場合の主な容疑者は、DLLをその場で復号化してメモリに解凍する、使用しているサードパーティのライセンスラッパーです。明らかに、この疑いを確認するために、影響を受けた顧客に保護されていないバージョンのアプリを提供することはできませんでした。おそらく、これが報告されている他のベンダーが同様の製品を使用しています。

• ライセンスベンダーから提供された保護ラッパーのデバッグバージョンでは、結果は得られませんでした。ログファイルは、エラーが発生しなかったセッションのログファイルとまったく同じように見えました。どうやら「内部」DLLは正常に復号化および解凍されますが、何らかの理由でホストプロセスによるロードに失敗します。

• 保護されていない「ローダー」DLLを作成することにより、LoadLibraryDLLをメモリにロードすることになっている呼び出しの背後のどこかでエラーの発生を特定することができました。

• 独自のコード（保護されていないローダーと保護された「コア」-DLLの両方）での広範なロギングとグローバル例外フックは、まったく結果をもたらしませんでした。エラーは明らかにどこか別の場所で発生します。

• 私のこの以前の質問で説明された問題は、おそらく同じ問題によって引き起こされました。これは、保護されていないローダースタブを作成する前のことです。

• エラーはお客様の約1〜2％でのみ発生しますが、通常、影響を受けるお客様のサイトのすべてのインストールは同じように影響を受けます。

• 新しいバージョンをリリースした後にエラーが消えることがありますが、多くの場合、数週間または数か月後に再びエラーが発生します。
• マシンでエラーが発生し始めると、それは一貫して発生します。

• リモートアクセス（VNC、RDP、TeamViewerなど）を介して影響を受けるマシンに接続している間はエラーが発生することはなく、影響を受ける顧客は誰も私たちから移動距離内にいないため、ログファイルと「目-目撃者の報告」。

• ある顧客は、エラーメッセージダイアログが明らかに非モーダルであると報告しました。つまり、ダイアログボックスを横に移動して、アプリケーションでの作業を続行できました（DLLが提供する機能を除く）。これが他のすべての出来事にも普遍的に当てはまるかどうかはわかりません。

• 場合によっては、お客様は、ホストアプリケーションを自社製品と共有していた他のベンダーの他のアドインを無効にするかアンインストールすることで、エラーを完全に取り除くことができました。

• このエラーは、これまでのところWindows XP、Vista、および7で確認されています。

• 過去数週間の間に、Outlook 2003 /Windows7ユーザーからのレポートが急増しました。最近のWindows/Officeの更新によって状況が悪化した可能性はありますか？

誰かがこのエラーの経験がありますか？

または、これを調査するためのアイデアは他にありますか？

背景
私はアプリケーションのプラグインを維持しています。Visual C++ 2003 を使用しています。

プラグインは複数の DLL で構成されています。アプリケーションが LoadLibrary を使用してロードするメイン DLL と、メイン DLL および相互に使用されるユーティリティ DLL がいくつかあります。
依存関係は一般的に次のようになります。

• plugin.dll -> utilA.dll、utilB.dll
• utilA.dll -> utilB.dll
• utilB.dll -> utilA.dll、utilC.dll

あなたは絵を手に入れます。

DLL 間の依存関係には、読み込み時と実行時があります。

すべての DLL ファイルは、実行可能ファイルのディレクトリに保存されます (要件ではなく、現在の動作のみです)。

問題
アプリケーション内でプラグインの複数のインスタンスを実行するという新しい要件があります。
アプリケーションはプラグインの各インスタンスを独自のスレッドで実行します。つまり、各スレッドは plugin.dll によってエクスポートされた関数を呼び出します。ただし、プラグインのコードはスレッドセーフではありません - 多数のグローバル変数など..

残念ながら、すべてを修正することは現在のところオプションではないため、同じプロセスでプラグインの DLL の複数 (最大 3 つ) のコピーをロードする方法が必要です。

オプション 1: 個別の名前アプローチ
各 DLL ファイルの 3 つのコピーを作成して、各ファイルが個別の名前を持つようにします。たとえば、plugin1.dll、plugin2.dll、plugin3.dll、utilA1.dll、utilA2.dll、utilA3.dll、utilB1.dll などです。アプリケーションは、plugin1.dll、plugin2.dll、および plugin3.dll をロードします。ファイルは実行可能ファイルのディレクトリにあります。

DLL の各グループが名前で相互に認識できるように (相互依存関係が機能するように)、コンパイル時に名前を認識している必要があります。つまり、DLL を複数回コンパイルする必要がありますが、毎回異なる出力ファイル名を使用する必要があります。

それほど複雑ではありませんが、VS プロジェクト ファイルのコピーを 3 つ持つのは嫌いで、同じファイルを何度もコンパイルする必要はありません。

オプション 2: サイド バイ サイド アセンブリ アプローチ
DLL ファイルの 3 つのコピーを作成し、各グループを独自のディレクトリに作成し、アセンブリ マニフェスト ファイルをディレクトリに配置して各グループをアセンブリとして定義し、プラグインの DLL をリストします。
各 DLL にはアセンブリを指すアプリケーション マニフェストが含まれているため、ローダーは同じディレクトリにあるユーティリティ DLL のコピーを見つけます。LoadLibrary を使用して DLL をロードするときにマニフェストが見つかるように、マニフェストを埋め込む必要があります。VS2003 にはマニフェストの埋め込みサポートが組み込まれていないため、このジョブには新しい VS バージョンの mt.exe を使用します。

私はこのアプローチを試してみましたが、部分的に成功しました.DLLのロード時に依存関係が見つかりましたが、別のDLLをロードするDLL関数が呼び出されたときではありません. この記事
によると、これは予想される動作のようです。DLL のアクティベーション コンテキストは、DLL の読み込み時にのみ使用され、その後は非アクティブ化され、プロセスのアクティベーション コンテキストが使用されます。

編集：期待どおりに動作します-DLLISOLATION_AWARE_ENABLEDのランタイムロードは、ロードDLLの元のアクティブ化コンテキストを使用します。

質問
他に選択肢はありますか? 迅速で汚い解決策は何でも構いません。:-)

ISOLATION_AWARE_ENABLEDVS2003 でも動作しますか? 編集：そうです。

コメントをお待ちしております。

ありがとう！

私は C++ でプログラミングしており、Visual Studio 2008、Windows XP を使用しており、次の問題があります: Python から使用できる DLL である私のアプリケーションは、外部 dll をロードし、必要なメソッドを使用し、次に、この外部 Dll をアンロードします。正常に動作していますが、1000 サイクルを超えると、メソッド「LoadLibraryA」は NULL 参照を返します。

主な手順は次のとおりです。

得られたエラーは次のとおりです。

Dll は、次を使用してアンロードされます。

mDLL は次のように定義されています。

最初に試みた代替方法: Dll を 1 回だけロードし、アプリケーションの終了時にアンロードします。これで問題は解決しますが、新しい問題が発生します。

アプリケーションが終了すると、最初にアプリケーションの DllMain メソッドを実行する代わりに、外部 DLL をアンロードし、最初に他の Dll の DllMain メソッドを実行します。これにより、アプリケーションが以前に単独でアンロードされた Dll をアンロードしようとしているため、次のエラーが発生します。

「Python.exe の 0x04a00d07 (DllName.DLL) で未処理の例外: 0xC0000005: アクセス違反の読み取り場所 0x0000006b」.

どんな提案も歓迎します。前もって感謝します。よろしく。

問題 1:

C++/CLI でコンパイル時ではなく実行時にライブラリを明示的にロードする方法はありますか。現在、コンパイル時に.NETの「参照の追加」を使用しています。管理された dll を明示的にロードしたいと思います。LoadLibrary に相当する .NET はありますか?

更新:ランドルフォに感謝

MSDNの Assembly::LoadFrom の例

問題 2:

Assembly::LoadFrom が LoadLibrary と同等の .NET である場合。GetProcAddress に相当するものは何ですか? メソッドへの FunctionPointers を作成するにはどうすればよいですか?

更新: MSDNの MethodBase.Invoke

現在、ZIP ファイルの読み取りに DotNetZip を使用する .NET Compact Framework のプロジェクトに取り組んでいます。プロジェクトは 2 つの部分に分割されます。CF プロジェクトとデスクトップ プロジェクトの両方で使用できる、プラットフォームに依存しない 1 つのライブラリ。この共通ライブラリには、ZIP ファイルを抽出するためのコードが含まれています。問題は、DotNetZip ライブラリの 2 つの異なる DLL があることです。1 つは .NET CF 用で、もう 1 つは .NET Desktop Framework 用です。デスクトップ フレームワークでライブラリの CF バージョンを使用することはできません。またその逆もできませんが、同じインターフェイスを共有します。

Visual Studio でプロジェクトを編成して、共通の郵便番号を使用し、適切な DLL (郵便番号によって使用される) を動的にロードできるようにするにはどうすればよいですか? PC 上で CF アプリケーションを実行することもできるはずですが、実行時に DLL を選択する方法はありますか?

LoadLibrary 関数からエラー コード 182 が返されます。MSDN から:

ERROR_INVALID_ORDINAL: "オペレーティング システムは %1 を実行できません"

このエラーが何であるかをよりよく説明している人はいますか?

Win32 API LoadLibraryを使用して同じ DLL を 3 回続けてロードすると、3 つの異なるハンドルが返され、各ライブラリの関数はすべて異なるアドレスを持つ必要がありますか? (または、何か「賢い」ことを行い、dll がプロセス用に既にロードされているかどうかを検出し、同じモジュールを指すだけですか?)

残念ながら、これはかなり自由形式の質問になりますが、私は気が遠くなり、アドバイスを求めたいと思いました。

これは、Visual Studio2008SP1を使用するVisualC++MFCアプリです。

同僚と私は両方ともOffice2007をインストールしていましたが、それ以来、アプリで奇妙なDLLの読み込みの問題が発生しました。具体的には、LoadLibraryはDLLの1つ（最初にロードするDLL）のロードに失敗し、エラーコード126（モジュールが見つかりません）を返します。本当に奇妙なのは、Windowsエクスプローラーから実行可能ファイルを実行するだけで正常に動作することです。

私は問題を診断するために通常の手順を実行しました。

1. ファイルが存在し、現在の作業ディレクトリがそのファイルを指していることを確認します。
2. 依存関係ウォーカーを実行し、依存関係が正しく読み込まれていることを確認します。この質問が失敗しても大丈夫だと言っているものを除いて、それらはすべて正常にロードされています。
3. コード内の同じ場所にいくつかの異なるDLLをロードしてみてください。単純な「スタブ」dllのいくつかは成功しますが、ほとんどは失敗します。
4. 別々のテストアプリから失敗しているDLLをロードしてみてください-空のコンソールアプリとベアボーンMFCアプリでは、すべてのDLLが正常にロードされています！
5. LoadLibraryExとLOAD_LIBRARY_AS_DATAFILEフラグを使用してDLLをロードしてみてください。これは成功しますが、依存関係の問題である可能性があることを指摘する以外は、それほど遠くはありません。

この時点で他に何をすべきか本当にわかりません。私が言ったように、Office 2007は私たちの問題の一般的なスレッドですが、それがどのような問題を引き起こす可能性があるのか​​わかりません。次に何をすればいいのかわからない。何か案は？

編集：現在の作業ディレクトリが何らかの理由でDLLパスにないことはかなり確信しています。失敗しているDLLは、他のDLLを必要としているようです。ローダースナップのデバッグ出力をオンにすると、現在の作業ディレクトリがDLLの読み込みパスにないように見えます。これを引き起こす可能性のあるアイデアはありますか？

edit2：現在のビルドは、実行可能ファイルを作業ディレクトリ以外のディレクトリにダンプしました。何らかの理由で、DLLをロードしようとしたときに別のDLLをロードしようとすると、現在の作業ディレクトリが検索されなくなりました。ロードしようとしているすべてのDLLを含むディレクトリに実行可能ファイルを配置することで、問題は解決します。これらすべてとローダースナップによる出力に基づいて、これはVisual Studioの奇妙なバグであると98％確信しており、単に回避する必要があります。

Microsoftがセキュリティアドバイザリ（2269637）をリリースしました。ライブラリの読み込みが安全でないため、リモートでコードが実行される可能性があります。

このメモは、この問題の検出に役立つツールと、ダイナミックリンクライブラリのセキュリティに関するプログラミングガイドラインに言及しています。

これらのガイドラインはどのように.NET開発に変換されますか？これはPlatformInvokeにのみ影響すると思います。

これは、システムライブラリをインポートするための推奨される方法のままですか？