ローダーロックエラー

C＃でコードを記述して、C ++ dllを構築しています。

私はエラーを出して言った

LoaderLockが検出されましたメッセージ：OSローダーロック内で管理された実行を試みています。DllMainまたはイメージ初期化関数内でマネージコードを実行しようとしないでください。実行すると、アプリケーションがハングする可能性があります。

私はこのエラーが正確に何を意味するかを調べてみましたが、私は無意味な記事を描いています。ほとんどの場合それは単なる警告であり、Visual Studioでそれをオフにする必要があります。他の解決策は、iTunesまたはDirectXでプログラミングするときに発生するこの問題が原因であるようです。私の問題はどちらにも関係していません。

誰かが説明できますか、これは実際にはどういう意味ですか？

メニューのデバッグ->例外に移動し、マネージデバッグアシスタントを開き、LoaderLockを見つけてチェックを外す必要があります

ローダーロックの一般的な考え方：システムはDllMainのコードをロック内で実行します（同期ロックの場合と同様）。したがって、ここで説明するように、DllMain内で重要なコードを実行すると、「デッドロックを要求する」ことになります。

問題は、なぜDllMain内でコードを実行しようとしているのか、です。このコードがDllMainのコンテキスト内で実行されることが重要ですか、それとも新しいスレッドを生成してコードを実行でき、DllMain内でコードの実行が完了するのを待たないのですか？

マネージコードの問題は、具体的には、マネージコードの実行にCLRの読み込みなどが含まれる可能性があり、そこで何が起こり、デッドロックが発生するかわからないことです...「この警告を無効にする」のアドバイスには注意しません。 「もし私があなただったら、いくつかのシナリオでは、アプリケーションが予期せずハングする可能性が高いからです。

.NET 4.0以降のフレームワークの更新

これは、.Net 2.0の時点で尋ねられた古い質問です。混合モードDLLのサポートに重大な初期化の問題があり、ランダムデッドロックが発生する傾向がありました。.Net 4.0以降、混合モードDLLの初期化が変更されました。これで、初期化の2つの別個の段階があります。

1. DLLのエントリポイントで呼び出されるネイティブ初期化。これには、ネイティブC ++ランタイムのセットアップとDllMainメソッドの実行が含まれます。
2. 管理された初期化。システムローダーによって自動的に実行されます。

手順2はローダーロックの外部で実行されるため、デッドロックはありません。詳細は、混合アセンブリの初期化で説明されています。

混合モードアセンブリをネイティブ実行可能ファイルから確実にロードできるようにするには、DllMainメソッドがネイティブコードとして宣言されていることを確認するだけです。#pragma unmanagedここで助けることができます：

#pragma unmanaged

BOOL APIENTRY DllMain(HMODULE hModule,
    DWORD  ul_reason_for_call,
    LPVOID lpReserved
    )
{
    ... // your implementation here
}

DllMainが直接または間接的に呼び出す可能性のあるコードもすべて管理されていないことも重要です。DllMainが使用する機能の種類を制限することは理にかなっているので、DllMainから到達可能なすべてのコードを追跡し、すべてがでコンパイルされていることを確認し#pragma unmanagedます。

コンパイラーは、DllMainが非管理対象として宣言されていないことを検出した場合にC4747に警告することで、少し役立ちます。

1>  Generating Code...
1>E:\src\mixedmodedll\dllmain.cpp : warning C4747: Calling managed 'DllMain': Managed code may not be run under loader lock, including the DLL entrypoint and calls reached from the DLL entrypoint

ただし、DllMainが他のマネージ関数を間接的に呼び出した場合、コンパイラーは警告を生成しないため、発生しないようにする必要があります。そうしないと、アプリケーションがランダムにデッドロックする可能性があります。

ctr d + eを押してから、Managed Debugging Assistantsノードを拡張します。次に、LoaderLockのチェックを外しました。

これがお役に立てば幸いです。

ローダーのロックエラーが発生しないようにするには、「例外アシスタント」ではなく「例外ヘルパー」を無効にする必要があることをVS2017ユーザーに思い出してください。この設定パスはDebug-> Exceptionです。ちょうどこの問題にぶつかり、解決策を探すために2時間を無駄にした...

ネイティブコードで記述されたCOMオブジェクトのインスタンスを作成しているときに、最近このエラーが発生しました。

m_ComObject = Activator.CreateInstance(Type.GetTypeFromProgID("Fancy.McDancy"));

これにより、前述のエラーが発生しました。「LoaderLock was detected」-例外がスローされました。

追加のスレッドでオブジェクトインスタンスを作成することで、このエラーを克服しました。

ThreadStart threadRef = new ThreadStart(delegate { m_ComObject = Activator.CreateInstance(Type.GetTypeFromProgID("Fancy.McDancy")); });
Thread myThread = new Thread(threadRef);

myThread.Start();
myThread.Join(); // for synchronization

アンマネージDLLを呼び出してアンマネージコードを定義する必要があるC ++ CLR DLL（MSVS2015）を構築しています。#pragma managedおよび#pragma unmanagedを使用して、コードの特定の領域でのモードを制御します。

私の場合、私は単に#pragma unmanagedを私のDllMain（）の前に置くだけで問題が解決しました。DllMain（）のマネージドバージョンが必要だと思っているようです。

この問題は、Visual Studioのデバッガーが、1つ以上のDLLファイルでMicrosoft Foundation Classesバージョン8.0を使用するマネージアプリケーションを実行する方法が原因で発生します。

詳細については、http：//msdn.microsoft.com/en-us/library/aa290048（vs.71）.aspxをご覧ください。

私のVisual Studio 2017インスタンスの設定パスは、デバッグ-> Windows->例外設定です。例外設定の「ウィンドウ」が（別のウィンドウではなく）下部のタブグループに表示され、気づくまでに少し時間がかかりました。「ローダー」を検索します。