COM相互運用機能を使用して.NETアプリケーションでAccessViolationExceptionがランダムに発生する

Question

最近、メンテナンス性のために構造化プログラミング手法を使用して作業プロトタイプライブラリを書き直しました。アプリケーションのCOMベースのAPIを使用して、サードパーティのアプリケーション（TPA）からデータにアクセスします。 APIはWin32メッセージング（WM_COPYDATA）を使用してTPAと通信します。

新しいライブラリコード：

1. は、Visual Studio 2010 SP1でC＃で書かれています。
2. ターゲット.NET Framework 4（プロトタイプで3.5でした）。
3. 匿名メソッドと新しいカスタムジェネリッククラスを使用して、元のコードを分解し単純化します。これは、どちらも使用しません（ただし、HashSet <>などの.NET Frameworkユーティリティタイプは除きます）。
4. 組み込みの相互運用型（埋め込みInterop Types = False）と登録不要のCOM（Isolated = True）を使用するCOMベースのAPIを参照してください。
5. Marshal.ReleaseComObjectを使用して、COMベースのAPIによって返されるオブジェクトによる確定的なメモリ管理を実現します。
6. COMベースのAPIは、シングルスレッドアパートメント（COMベースのAPIはアパートメントスレッド）で実行されるワーカースレッドでのみ使用されます。
7. COMベースのAPIを呼び出すときに初期バインディングを使用します。

私たちのテスターアプリケーションは、COMベースのAPIのAccessViolationExceptionでランダムにクラッシュします。スタックトレースは、これがUnsafeNativeMethods.DispatchMessageW（下記のサンプルを参照）またはCOMベースのAPIのいくつかの異なるプロパティのいずれかで発生することを示しています。テスターアプリケーションは、メニュー、ステータスバー、およびRichTextBoxを備えた単純なWinFormsアプリケーションです。

この動作は、FinalReleaseComObjectでReleaseComObjectを置き換えるかどうかにかかわらず、ワーカースレッドとUIスレッド間のスレッド間通信が有効かどうかに関係なく、Windows XPおよびWindows 7に共通です。 TPAが非常に忙しいとき、より頻繁にクラッシュするようです。それが始まっている間。

プロトタイプライブラリはVS 2008を使用して開発されました。プロジェクトをVS 2010に変換した後でも、プロトタイプアプリケーションはクラッシュしません。

System.AccessViolationExceptionが処理されませんでした。メッセージ=しようとしました 保護されたメモリを読み書きします。これは、しばしば他の メモリが壊れていることを示しています。 Source = System.Windows.Forms StackTrace：at System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW（MSG & msg） at System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop（IntPtr dwComponentID、のInt32理由、のInt32 pvLoopData） System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner（のInt32 理由、ApplicationContextの文脈において） System.Windows.Forms.Application.ThreadContext.RunMessageLoop（のInt32 理由、ApplicationContextの文脈で） at System.Windows.Forms.Application.Run（フォームmainForm） at IndexerTester.Program.Main（）D：\ TestApps \ Indexer \ IndexerTester \ Program.cs：行17

同じような問題が発生しましたか？

原因を特定するためのアドバイスや潜在的な回避策はありますか？

Answer 1

これは少し遅れますが、誰かを助けるかもしれません。

COMオブジェクトのベンダーにバグレポートを送信しました。それぞれ異なるスレッド上に2つのインスタンスを使用すると、AccessViolationExceptionが発生します。ベンダーは、コードにバグ（スレッドセーフではない静的変数）があることを確認し、修正を発行しました。

サードパーティ製アプリケーション（TPA）とテスターアプリケーション（TPAからデータを読み取る）の両方がビジーだった場合、クラッシュが頻繁に発生することに気付きました。

重大な負荷がかかると、プロトタイプのアプリケーションを使用してもクラッシュが発生することがわかりました。私たちは書き換えがバグを導入したと誤って想定していました。この発見は私達がベンダーにこれを報告することを納得させました。