2

私は非常に奇妙な状況にあります、私は前にそのようなことを見たことがありません。

プログラムとの通信に、サードパーティアプリのCOMインターフェイスを使用しています。処理中のCOMサーバーです。動的型付けを使用して、ターゲットアプリケーションのオブジェクトモデルにアクセスします。

dynamic app = Activator.CreateInstance(Type.GetTypeFromProgID("SomeProgId"));

そのオブジェクトを使用して、アプリケーションappの他のオブジェクトを取得dynamicします。そのようなオブジェクトの1つは非常に大きな配列を表し、その要素には多数のプロパティがあります。この配列のすべての要素をトラバースし、それらのすべてのプロパティを読み取ります。つまり、大きなループで上記のオブジェクトを解析します(数分実行)。

問題は次のとおりです。たとえば、10回に1回の試行で、そのようなプロパティの1つ(毎回異なる)を読み取るときにスレッドが「ハング」することがあります。

string someString = app.SomeArrayObject.Get(i).SomeStringProperty;

私はこれを行うためにバックグラウンドワーカーを使用しますが、それは上記の割り当てにかかっています。クイックノート:上記のステートメントは1行の簡略化であり、実際には一度に1レベルずつオブジェクトにアクセスするため(「各ステートメントに1つのドットのみ」)、実際にはSomeStringPropertyプロパティの読み取りにハングします。例外などをスローせず、無期限にハングします。The thread '<No Name>' (0x1240) has exited with code 0 (0x0).その直前にデバッガーの出力ウィンドウにメッセージが投稿されていることに気づいたので、一部のスレッドが予期せず終了したと思います(例外は記録されていません!)。デバッグを中断すると、そのようなシナリオ(COMオブジェクト内)では使用が非常に制限されるため、呼び出しスタックは実際には役に立ちません。

なぜそれが起こるのか、そしてそれがどのように可能であるのか私にはわかりません。単純な文字列プロパティを読み取ると、永続的にハングします。あなたはなにか考えはありますか?..

4

1 に答える 1

1

COM サーバーは MTA 対応として登録されていましたが、実際には STA モード専用に設計されていたことが明らかになりました。フレームワークは、MTA モードで使用しても問題ないと想定し (レジストリ内の対応する登録エントリが MTA をサポートしていると述べているため)、おそらくいくつかのバックグラウンド スレッドを定期的に作成していたため、例外が発生していました。スレッドのモードを STA に設定するか、レジストリ内の COM サーバーのパラメーターを変更して STA のみを報告すると、この不思議なランダム クラッシュの問題が解決されました。

于 2012-10-01T08:56:50.717 に答える