問題をできるだけ詳しく説明するように努めますが、より詳細な説明が必要な場合はお知らせください。
簡単にするために、私が3つのDLLを持っているとしましょう(実際にはもっと持っていますが、それほど重要ではないと思います):
- managed-1.dll-マネージDLL(C#.NET 4.0で記述)-リクエストを処理し、一部のリクエスト中に2番目のDLLでアンマネージコードを呼び出す
- unmanaged.dll-アンマネージDLL(古い学校のVC ++ 6.0で記述)-いくつかの操作を実行し、3番目のDLLを呼び出すこともあります
- managed-2.dll-マネージDLL(CLI / C ++ .NET 3.5で記述)-私の問題の根本
私は3つの異なるシナリオでコードを実行します:
- コンソールアプリケーションから呼び出し - managed-1.dllます-すべてがうまく機能します
- 私はから電話 - managed-1.dllします- ASP.NET Development Server-すべてもうまくいきます
- 私はから電話 - managed-1.dllします-シーケンス全体が関与- IISするまで、すべてがうまく機能します。- managed-1.dll -> unmanaged.dll -> managed-2.dll
シナリオ3では、StackOverflowExceptionがスローされます。デバッガーは、再帰が含まれていないことを示しています。また、次のタイプの呼び出しスタックで例外が発生していることも明らかです。
- managed-1.dll::CallUnmanagedCode()
- unmanaged.dll::SomeMethod1()
- unmanaged.dll::SomeMethod2()
- unmanaged.dll::CallManagedCode()
- managed-2.dll::CallUnmanagedCode()!! でマークされ- __declspec(dllexport)、管理されたタイプを使用しません!!
- managed-2.dll::FailingMethod()!! 管理対象タイプを使用します。非常に最初に(コードの最初の行が実行されない場合でも)、例外が発生します!!
もう1つ興味深いのは、デバッガーはFailingMethod、メソッド呼び出しポイントの値と比較して、に同じパラメーター値を表示しないことです。
誰かが手がかりを持っているなら、アドバイスしてください。
解決策:問題は、マネージド-アンマネージドのものではなく、IISスタックサイズに関連していました。私にとって、editbinツールの使用は受け入れられない解決策でした。したがって、私の解決策-を呼び出す前に新しいスレッドを作成し、unmanaged.dllスタックを1MBに設定します。
var result = unchecked ((int)0x800000FF);
var thread = new Thread(() => { result = pinvoke_func(); }, 1024 * 1024); // 1MB
thread.Start();
thread.Join();