Visual Studio上のデバッグ時の挙動

Question

デバッグ時の動作としてよく分からない現象が起きています。 この辺の動作に関して解決方法、情報がありましたら、教えていただける様お願いします。

環境: Visual studio 2015 Professional, Windows7 (ネット接続無し)
  C# formアプリ, .Net 4.61

1. 直接、実行すると動作するが、デバッガ(Visual studio)上で、実行するとエラーになる。

具体的には、別スレッドから、フォーム上のコントロールを制御した際のエラー。ソースを確認したところ、別スレッドからのアクセスとなっていたのですが、ある日、突然、デバッガ上で、エラーとなりました。こういう事はあるのでしょうか? 同じ実行ファイルを直接、実行したところ、問題無く、動きました。
本来、エラーとなるのが、正しい動作のようですが、理由が分かりません。 (ネットから切り離された環境ため、その間、updateとかは行われていません)

2. ブレークポイントで停止すると、PCがハングアップ状態となる。

デバッグ中のアプリと、Visual Studioだけでなく、PCまで含め、ハングアップ状態となり、マウスも追従しなくなります。　Ctrl-Alt-Delもレスポンスがなくなります。 ただ、5分位すると、何事もなかったかのように、動きます。
Sentech SDK(カメラ画像取得)を使いだしてから、多発しているのですが、メーカーに問い合わせても、(当然ながら)そのような事は無い、との事。このような事が起きる原因としては何があるでしょうか? 解決方法、または、どのように調べたら、良いかの情報があると助かります。

また、勝手で申し訳ないですが、オフラインでの作業のため、すぐに返信できない事が多いです。
(さらには、とりあえず、動いてるので、プライオリティは下がってます、、、が、困っているのは変わらず)

Answer 1

pepperleaf01さん、こんにちは。フォーラムオペレーターのHarukaです。
MSDNフォーラムにご投稿くださいましてありがとうございます。

バックグラウンドで実行されているスレッドが1つあるようです。 
ブレークポイントをヒットすると、スレッドは実行を終了する必要があります。

シンプルなSDKコードを使用して新しいコンソールアプリケーションを作成し、デバッグすることで、この問題が引き続き発生するかどうかをご確認してください。

どうぞよろしくお願いいたします。

---

MSDN/ TechNet Community Support Haruka
～参考になった投稿には「回答としてマーク」をご設定ください。なかった場合は「回答としてマークされていない」も設定できます。同じ問題で後から参照した方が、情報を見つけやすくなりますので、 ご協力くださいますようお願いいたします。また、MSDNサポートに賛辞や苦情がある場合は、[e-mail]までお気軽にお問い合わせください。～

Answer 2

1. については、そういう仕様です。
Control クラスに static なプロパティ CheckForIllegalCrossThreadCalls があります。

「Control.CheckForIllegalCrossThreadCalls プロパティ」
https://docs.microsoft.com/ja-jp/dotnet/api/system.windows.forms.control.checkforillegalcrossthreadcalls

このプロパティが True なら別スレッドからのアクセスをエラーにします。
で、このプロパティの初期値が Debugger.IsAttached です。

「Control.cs」
https://referencesource.microsoft.com/#System.Windows.Forms/winforms/Managed/System/WinForms/Control.cs,f9d81f74d420451e

「Debugger.IsAttached」
https://docs.microsoft.com/ja-jp/dotnet/api/system.diagnostics.debugger.isattached

つまり、Control クラスが初めて使用されたときに、デバッガがアタッチされていれば CheckForIllegalCrossThreadCalls は True になり、アタッチされていなければ False になります。

2. についてはわかりませんが、たとえばドラッグ＆ドロップ操作中にデバッガを止めてしまうとハングすることはあったような気がします。
ブレークポイントを置くのではなく、ログ出力等でデバッグするしかないのでは？

Answer 3

> 環境: Visual studio 2015 Professional, Windows7 (ネット接続無し)

ネットワークに接続した状態での確認は実施されたのでしょうか？
もし実施されていないのであれば、ネットワーク接続での検証をお薦めします。
というのも。。。
Visual Studio に限らず Microsoft が提供しているデバッガ ツールは、デバッグ実行中に関連するシンボル ファイル (ntdll.pdb, kernel32.pdb, kernelbase.pdb, etc.) のダウンロードを、バックグラウンドで実施しています。
で、シンボル ファイルのダウンロードに失敗すると、なんども再試行が繰り返されるので、非常に重くなることがあります。

Answer 4

Haruka6002さん、返信ありがとうございます。

> バックグラウンドで実行されているスレッドが1つあるようです。 
> ブレークポイントをヒットすると、スレッドは実行を終了する必要があります。

こちらの意味がよく分かりません。 確かに、バックグラウンドで多数のタスク(スレッド)は動いていますが、、

> シンプルなSDKコードを使用して新しいコンソールアプリケーションを作成し、

こちらについては、取得した画像表示(及び、処理)をしたいので、コンソールアプリでは難しいかと。
多分、複数のスレッドが絡んでいるのでは? とも思うのですが、よく分からない状況です。

Answer 5

KOZ6.0さん、返信ありがとうございます。

> Control クラスに static なプロパティ CheckForIllegalCrossThreadCalls があります。

こちらの情報については、ありがとうごさいます。こういう違いがあるのですね。
ただ、ある日、突然、エラーになったのは謎なのですが、とりあえず、このような理解とします。

> ブレークポイントを置くのではなく、ログ出力等でデバッグするしかないのでは？

こちらについては、必要に応じてそうしてますが、途中で止められないのは、痛いです。
今日も、(コードにバグがあり)例外発生で、10分以上、操作不能となりました。PCリセットと思いつつ、放置。

Answer 6

お馬鹿さん、返信ありがとうございます。

> Visual Studio に限らず Microsoft が提供しているデバッガ ツールは、デバッグ実行中に関連するシンボル ファイル (ntdll.pdb, kernel32.pdb, kernelbase.pdb, etc.) のダウンロードを、バックグラウンドで実施しています。
で、シンボル ファイルのダウンロードに失敗すると、なんども再試行が繰り返されるので、非常に重くなることがあります。

そういう事もあるのですね。 確実に再現するパターンがあれば、その時にネット接続は可能ですが、常時は難しいです。ネット接続しない前提のでの作業なので。 他に確認する方法があると嬉しいです。

Answer 7

> 確実に再現するパターンがあれば、その時にネット接続は可能ですが、常時は難しいです。

常にこの問題が起きる訳ではないのでしょうか？
とりあえず、SDK に同梱されている WinDbg を使って同様の問題が発生するか、確認してみては？
WinDbg 上から該当アプリを起動させ、同様の現象が起きるのであれば、そのアプリのコード上の問題が考えられると思います。
逆に WinDbg 上では発生しないのであれば、Visual Studio 側の設定上の問題。。。。ということになると思います。

Answer 8

pepperleaf01さん、こんにちは。フォーラムオペレーターのHarukaです。
ご返信いただきありがとうございます。

スレッド/イベントの開始時間と終了時間を記録するログファイルを作成することをお勧めします。
下記コードをご参照いただければと思います。

string[] start = { DateTime.Now + ": Thread/Event Started\n" };
File.AppendAllLines(@"D:\Log.txt", start);
            ...
string[] end = { DateTime.Now + ": Thread/Event End\n" };
File.AppendAllLines(@"D:\Log.txt", end);

そして、ブレークポイントを使用してアプリケーションを再デバッグします。 
ブレークポイントにヒットしたら、ログファイルをチェックし、1つのスレッド/イベントの終了時刻に中断された時間が含まれているかどうかを確認してください。

どうぞよろしくお願いいたします。

---

MSDN/ TechNet Community Support Haruka
～参考になった投稿には「回答としてマーク」をご設定ください。なかった場合は「回答としてマークされていない」も設定できます。同じ問題で後から参照した方が、情報を見つけやすくなりますので、 ご協力くださいますようお願いいたします。また、MSDNサポートに賛辞や苦情がある場合は、[e-mail]までお気軽にお問い合わせください。～

Answer 9

> SDK に同梱されている WinDbg

については、これから、調べてみます。ただ、ちょっと忙しいので来週になります。

書き忘れたのですが(自分も忘れてた)、動かなくなった時は、CPUの稼働率が ほぼ100% 何が起きてるかは気になるのですが、確認もできない。

問題の発生頻度は、昨日今日は、ほぼアウト。それ以前は、もう少し低いと思ったのですが、、
カメラSDKが異なるのを同時進行で作業しているので、それだけかも知れませんが。

ネット接続については、しばらく接続してないので、今繋ぐとほぼ確実に、半日は使えなくなる予感。(諸般のアップデート) 当分出来そうもないです。

Answer 10

Haruka6002さん、

> ブレークポイントにヒットしたら、ログファイルをチェックし、1つのスレッド/イベントの終了時刻に中断された時間が含まれているか

「中断された時間」とはどのような意味でしょうか?
また、ブレークポイントにヒットしたら、、ですが、ここで(実質) ハングアップ状態なので、ログファイルの確認はできません。また、スレッド/イベントが多く、把握しきれていません。(これはこれで問題ですが、、)

Answer 11

> 書き忘れたのですが(自分も忘れてた)、動かなくなった時は、
> CPUの稼働率が ほぼ100% 何が起きてるかは気になるのですが、
> 確認もできない。

ハングアップ現象発生時の完全メモリ ダンプを採取しそれを確認すれば、とりあえず何のプロセスが CPU を占有しているのかを、確認することができると思います。
下記サイトを参考に、完全メモリ ダンプとキーボード クラッシュを有効にする設定を行えば、ハングアップ現象発生時の完全メモリ ダンプを採取できると思います。
-------------------------------------------------
手動での完全メモリダンプ の取得方法（Windows 10 / 8.1 / 8 / 7）
https://support.kaspersky.co.jp/common/diagnostics/3055
-------------------------------------------------

Answer 12

少し進展がありました。 64bitプログラムのデバッグでハングみたいな話があったので、もしやと思い、、設定を変えていたところ、、

2台接続されているカメラの内、一台の接続を Offにしたところ、問題が発生しなくなりました。 二台とも IP接続なのですが、なぜか片方のみ。
IPアドレスを変更しても変わらないことから、カメラの問題(メーカは同じだが種類が違う)か、接続してるネットワークカード(別接続)の問題かは不明。

これ以上は、時間が取れないため、未確認ですが、参考情報として。

Answer 13

> 2台接続されているカメラの内、
> 一台の接続を Offにしたところ、
> 問題が発生しなくなりました。

基本的に PC のハングは、ほとんどの場合、カーネル モード側でのデッドロックに起因して発生します。
なのでカメラ関連のドライバ内で、一時的にデッドロック状態が発生しているためでは？
(だから現象発生時の完全メモリ ダンプを採取しての確認をお薦めした訳ですが。。。。)

Answer 14

お馬鹿さん、コメントありがとうございます。

64bitのデバッグの問題は、RPCとありました。今回が該当か不明ですが、ネットワーク関係のリセットで復帰。でもカメラが使えないので、設定を戻したら、再発でした。

> だから現象発生時の完全メモリ ダンプを採取しての確認

興味はあるのですが、確実に数日は掛かるので無理(と言うか、本来業務が止まる)

今回の結果から、特定のカメラだけなので、それを外せば、デバッグできるので、その状態で作業中となります。
(そのカメラ、あまり使わないとの、廃番予定なので次のシステムでは使わない、、、)

> カメラ関連のドライバ内で、一時的にデッドロック状態が発生しているため
メーカーでは問題無いとの事。(まあ、廃番予定をどれだけ検査してるか? もあるが)

------
20世紀には、Unixのカーネルデバッグもしたので、気にはなるのですが、、、。

あ、今、同じシステムで、時々、遅延が発生する問題の対応中。こっちで質問するかもですが、その時はよろしくお願いします。

Answer 15

> 今回の結果から、特定のカメラだけなので、
> それを外せば、デバッグできるので、
> その状態で作業中となります。

その「特定のカメラ」は、メーカからの専用ドライバを必要とするのでしょうか？
「特定のカメラ」をサポートするためのストリーミング用ドライバ スタックが、「OS 標準の Inbox のみの構成」あるいは「カスタム ドライバをを含む構成」いずれになっているかが、原因特定の重要なポイントだと思います。
(デバイス マネージャで確認してみては？)


> メーカーでは問題無いとの事。(まあ、廃番予定をどれだけ検査してるか? もあるが)

メーカでは当然自社製品に関連するソフトウェアの単体検証は行っていると思いますが、他社ソフトウェア モジュールとの共存環境での整合性に関しては、そんなにテストを行っていないんだと思います。
今回のケースでは "Sentech SDK" を使用しているとのことですが、例えばこの SDK が Kernel Streaming Service (ksthunk.sys) 対して干渉 (例えば Streaming Service に対して Filter Driver をかます) していて、Kernel Mode 側の Streaming 処理に対して独自機能を追加してる場合、そこで問題が起きる可能性も考えられると思います。

Answer 16

複数のカメラを一つのSDKで制御してます。 以前は別のドライバを使っていたのですが、カメラを更新する必要から、ドライバも更新。(共存できないので)

一応、汎用ドライバらしいですが、それ以上は不明。