マネージコードからの呼び出し時にC++ DLLがクラッシュする

Question

.NET Framework 3.5を使用してC＃で書かれたWinFormsアプリケーションがあります。 SQL Serverデータベースを使用して、指定されたODBC-DSNから

[DllImport(DllName)] 
public static unsafe extern int LoadDBData(String dsn, String userid, String password); 

この方法輸入データ：このアプリケーションは、次の宣言を使用して、インポートされたC++ DLLを使用します。データベースにデータが多すぎると、コールがクラッシュします。このextern dllのプロバイダは、dllがより多くのヒープサイズを取得することができず、アプリケーションがより多くのヒープメモリを提供する必要があるため、この問題が発生すると述べています。

どうすればこの問題を解決できますか？私が知っている限り、自動ガベージコレクションからコンポーネントを除外する唯一の可能性は、すでに使用している安全でないキーワードです。 何か考えていただければ幸いです。事前に

おかげ

マーティン

Answer 1

これは、コードではなく、ベンダーのライブラリに問題があるようです。

管理されたメモリと管理されていないメモリは完全に分離されているとみなす必要があります。管理対象メモリは、通常、ガベージコレクトされたメモリ ヒープ上に割り当てられますが、アンマネージメモリは他のものです。はmalloc（3）、カスタムメモリプール、および のCLI制御外のヒープ割り当てヒープ実装...

上記の引用はMono documentationからのものですが、（私が間違っていない場合は）一般的には.NETにも当てはまります。データがDLLの内部データ構造にロードされている場合は、独自のメモリを割り当てる必要があります。データでいっぱいになるバッファを提供している場合、バッファに割り当てられただけのデータで満たされます（マーシャリングの前に固定されます）。では、データはどこにロードされていますか？

Answer 2

あなたは.NETのヒープサイズを増やすことはできません。 .NETアプリケーションがProcess.Startを使用して呼び出すc/C++でEXEを作成できます。 c/C++ EXEは、DLL関数を呼び出して結果を返します（または、複数の関数がある場合は、コマンドラインパラメータを取ることができます）。別のEXEを必要としない場合は、代わりにRunDll32を使用してみてください。

Answer 3

これは.NET、管理されたメモリ、ガベージコレクションなどに固有のものではないかと疑いがあります。ネイティブDLLなので、通常の管理されていないメモリが使用されます。もちろん、.NETランタイムではメモリの共有も使用されますが、DLLを使用するネイティブアプリケーションでも同じことが行われます。

32ビットプロセスで実行している場合は、.NETおよびアンマネージコードの合計ヒープサイズを1.5 GBに制限できます。追加情報なしで話すのは難しいですが、その限界にぶつかったかもしれません。

したがって、1つの選択肢として、64ビットバージョンのライブラリがあり、64プロセスに切り替えるかどうかをベンダーに尋ねることがあります。 64ビットプロセスでは、メモリはほとんど無制限です（今日の標準によると）。