VS2015でデバッグが開始できない（ Windows Embedded Standard 7 環境）

Question

お世話になります。

Windows Embedded Standard 7に、

VisualStudio2015 update3をインストールして使用しています。

C#でWindowsフォームアプリケーションを作成していますが、

デバッグの開始を実行（F5）しても全く反応しないことが多々あります。

原因調査のため、簡単なアプリを作成して現象を確認しました。

1.　Windowsフォームアプリケーションプロジェクトを作成

2. フォームに、System.Windows.Forms.Timerを、３個ほど貼り付ける

これだけの実装で、アプリを実行します。

アプリを終了した後、再びデバッグの開始を実行しても反応しません。

この時の状況を確認してみると、アプリを終了後、devenv.exeの

CPUの使用率が跳ね上がることが確認できました。

どうも、devenv.exeがCPUの使用率を上げている間に、再びデバックを開始すると

無反応となるようです。必ずCPUの使用率が長時間上がるわけでもなく、

早いときは数秒、長い時は１分程度上がっているようです。

この現象は、他OSでは確認できず、WES7環境でのみ発生するようです。

何か、対策手段は無いでしょうか？

Answer 1

レスがつかない状況なので回答ではありませんがコメントしておきます。

VS2015 は WES7 で動かすことを保証されいないかと思われます。
https://stackoverflow.com/questions/39768842/visualstudio-2015-on-embedded-win-7

どうしてもその道を追求したいのであれば、有償サポート（場合によってはプレミアサポートを要求されるかもしれない…）に問い合わせてみるぐらいしかご提案できないかと思います…。
（WES7 を使っている人の母数はそれほど多くないので、情報を集めづらい）

Answer 2

こちらも回答ではありませんが、

問題の発生しているPCのスペックはどの程度でしょうか?
他OSでは確認できないという事ですが、同程度のPCでしょうか?

今、Windows7(CPU: Celeron) で作業していますが、似た現象に出会っています。
もっともアプリ終了直後にデバックという事はまれなので、同じかどうかは分かりません。
頻度的には、デバッグ終了時に、VisualStudio2015がハングする事が多いです。
(とは言っても、多くて日に1,2回ですが)
近いうちに、Embeddedに移行したい言われているので、ちょっと気になりました。

同じ問題かは分かりませんが、参考として。

Answer 3

どうも似たような質問もあるようなので、本質的な点について確認しておきます。
ご存知の通り、

1.Embedded開発とは対象システムに対して適合する「対象OS」と「対象アプリケーション」をビルドする

事ですね。
当たり前ですが、システムに最適化してビルドしたOS上ではVS等の開発環境は動きません。
つまり最終的なEmbedded OS上でVS等の開発環境を動作させる試みは
失敗することが自明であると考えられるわけです。
デバッグできない点は、セキュリティ上も重要な要素でもあるわけですね。
重ねて、かりにこれに成功しても、

2.それが、製品としてのシステム上の動作保障しているわけではない。
 　(異なるOS上でデバッグ用アプリを動かしてみたにすぎない)

点に注意が必要です。つまりあんまり意味がないわけです。
Embedded開発の順番としては

3.通常の(Embeddedでない)OS上でリリースビルドしたアプリが動かないうちは、
 　Embedded OSの出番はありません(特別な外部I/Oがある場合はその動作試験等はできますが)。

この段階が済んで、初めて、アプリケーションのDLL等依存関係に基づきOSがビルドできるわけですね。
そして、ビルドしたOSとアプリケーションの結合を行いますが、もしビルドしたOS上で対象システムの不具合が出るようなら、
デバッグ用のOSをビルドして、OS(主にドライバ)の不具合のデバッグをすることになるかもしれません。
Embedded開発は本質的にはクロス開発であるという点に注意する必要があります。

Answer 4

VS2015 が WES7 上での動作保証をしていないというのは、確かにその通りだと思いますが、だからといってそれで「使えない」という結論になるのは疑問が残ります。
あくまでも私見ですが、VS 製品が WES7 等の Embedded 製品上での動作保証をしていないのは、その性質上 Platform に組み込まれるコンポーネントに差異があることが前提となるため、その細かな差異部分まで面倒見きれないので、動作保証外としているだけだと思っています。
逆に考えれば (動作保証する/しないは別として)、デスクトップ版 Windows 7 と同等のコンポーネント構成にした WES7 で VS 製品が動かないのであれば、それはそれで問題なのでは？

質問内容を読む限り、問題は「デバッグの開始を実行（F5）しても全く反応しない」の一点のみで、VS のインストールおよびアプリのビルド、さらにはそのアプリの初回時デバッグ実行には支障が無いように読み取れます。
(私が勝手にそう思い込んでいるだけかもしれませんが。)
だとすると、「最終的なEmbedded OS上でVS等の開発環境を動作させる試みは失敗することが自明」とうのは、ちょっと違うような気がします。

もし該当環境でそれ (2回目以降のデバッグ実行ができない現象) 以外の問題が起きていない、つまりアプリのビルドや通常実行等で問題が起きていないのであれば、本件は「VS2015 が WES7 上での動作保証外」というのが問題なのではなく、VS からデバッグ対象プロセスへのアタッチ/デタッチ処理に問題が発生しているだけ。。。即ち VS からの DebugActiveProcess() あるいは DebugSetProcessKillOnExit() での処理を阻害する「何か」が本質的な問題なのでは。。。と思っています。
そのあたり (DebugActiveProcess / DebugSetProcessKillOnExit) の挙動を確認するのはそれなりに面倒ですが、VS でのデバッグに固執するのであれば、その面倒な調査を行うだけの価値があるか、それとも「動作保証外」ということであきらめるかの、二者択一になるかと思います。
VS でのデバッグにこだわらないのであれば、WinDBG で代用できるのでは？

Answer 5

ご指摘ありがとうございます。　自分の発言では、
「Embedded OS上での、VSを使用したデバッグ行為自体が無用かつ無意味ではないか。」
という趣旨で申し上げました。つまりそれ自体が論外との見解です。
わかりづらくて申し訳ありません。

また、確かに動く可能性はゼロではありませんが、Embedded特有かつほぼ必須のEWF等を導入してしまえば
PCとOS自体が開発環境として成り立ちません。アプリケーションのシェル指定は言うまでもありません。
そういった意味から無為な時間を過ごすことなく、早急にEmbedded OS上でのデバッグから手を引くべきだという意見です。

最後に、WinDBGのアドバイスありがとうございます。
XP Embeddedの時に自分も使っていたのをすっかり忘れていました。

Answer 6

> また、確かに動く可能性はゼロではありませんが、
> Embedded特有かつほぼ必須のEWF等を導入してしまえば
> PCとOS自体が開発環境として成り立ちません。
> アプリケーションのシェル指定は言うまでもありません。

EWF の影響は私も真っ先に考えましたが、VS のインストールや対象アプリの初回時デバッグ実行には支障が無いようなので、今回のケースに関しては無関係だと考えています。
(シェルに関しても同様。)
そもそも EWF やシェルの影響であるならば、今回の質問 (というか問題) 自体が発生しないと思っています。

Embedded に限った話ではありませんが、特定の環境 (特にお客様環境) でしか問題現象が再現できない。。。ということは多々ありますし、そういった場合にデバッガを利用することは正しい選択だと思います。
Embedded OS 環境上での VS の使用に関しては私も否定的な考えですが、アプリケーション開発に伴うユーザー モード デバッグの主流が VS 環境である現状では、(私は使いませんけど) 使いたくなる気持ちはわかります。
この MSDN フォーラムを見わたしても、WinDBG を使ったデバッグ解析はちょーマイナーな分野 (某 MVP 様曰く「趣味の回答」に該当するらしい) のようですので、今回のような VS のニーズは多少なりとも存在するんだと思います。
先の返信でも触れましたが、今回の問題は「VS からデバッグ対象プロセスへのアタッチ/デタッチ処理に問題が発生しているだけ」と考えているので、動作保証外だから動かないのは当然。。。というのは、ちょっと論点が違うと思った次第です。
(もちろん Embedded 環境での VS の使用を推奨するわけではありませんし、使うのであれば自己責任であることには変わりありませんが。)

Answer 7

本現象は、

メニューより「プロジェクト」→「プロパティ」→「デバッグ」設定より

「Visual Studio ホスティングプロセスを有効にする」チェックを外すことで

現象を抑えることが出来ました。

しくみは理解できていないのですが、

この方法で問題は回避できるようになりましたので、

これで対応したいと考えています。

この現象から推測できることがあれば、フォロー頂けると幸いです。

色々とご意見頂きありがとうございました。

Answer 8

[ホスト プロセスを無効にする] の説明には、下記一文があります。
-----------------------------------------------------
方法 : ホスト プロセスを無効にする
https://docs.microsoft.com/ja-jp/visualstudio/ide/how-to-disable-the-hosting-process

ホスト プロセスが有効になっていると、
特定の API の呼び出しに影響する場合があります。
影響がある場合は、
正しい結果が返るようにホスト プロセスを無効にする必要があります。
-----------------------------------------------------

私が実際に確認した訳ではないのであくまでも推測ですが、Host Process が有効になっていると、デバッグ対象のターゲット プロセスからの API コールで問題が発生し、結果として正常終了できずゾンビ プロセス等の状態で残ってしまい、それにより VS デバッガからのデタッチ処理が行われず問題の現象が発生する。。。。というシナリオも考えられるかと。