突然マウスの動きが悪くなる、時々オーディオが途切れる、アプリの動きが突然重くなる。デスクトップ用のアプリケーションを移植したら重すぎて想定通り動かない、メモリ不足になったなど、パフォーマンスの問題に遭遇した時、どのように対処していますか？


一般的に以下のような確認を行い原因を絞り込んでいきます。
・要所にデバッグシリアル出力を挿入し、プログラムの実行状態を確認する
・PBのリモートプロセスビューアで稼働中スレッドのプライオリティを確認し、該当スレッドの設定が適切か確認する
・PBのカーネルトラッカでスレッド状態遷移をモニタリングし、対象スレッドが適切に動作しているか確認する
・プロファイラ機能を使って関数呼び出しの状態を監視する。
・コンポーネント絞り込み、他のドライバの影響を受けていないか確認する


アプリ単体で現象が発生し、PBのデバッガを接続してアプリの単体デバッグが可能な状況であれば原因の究明は比較的容易です。しかし、デバッグビルドやPBとの接続などによりタイミングが変わると発生しなくなるような障害となると、原因究明は困難になります。また、シリアルメッセージを挿入したことによる遅延が、別の障害を生んでしまうこともあります。


共通した課題
これまでいくつかの事例を通してWindows CE環境でのデバッグ手法とその課題についてお話ししてきましたが、組込み製品特有の制限された環境では、共通した課題があると言えます。
・限られたリソース(ポート、メモリ、CPUパフォーマンス)での実装の難しさ。
・ターゲット環境により、デバッガと接続することができない場合がある
・デバッグビルドやPBとの接続、シリアルメッセージの挿入により、現象が発生しなくなることがある
・シリアルメッセージは強力な武器だが適切に活用するためにはデバッグスキルが求められる
・システム構成には、ソースコードを参照することができないモジュールが含まれていることがある


ツールの活用
これらの課題をクリアしながらデバッグしていくには、その時の状況に応じて最適なツールを適切に使用することが大切です。シリアル出力が有効なら、適切にシリアルメッセージを挿入することでプログラムの状態を確認することができるでしょう。Ethernetが使えるなら、デバッガやPBのツール、Application VerifierやKernel Tracker、CELogなどのツールが強力な助けになるでしょう。また、デバッガが使えないような環境下でも我々のようなツールベンダが提供しているデバッグツールを活用する事もできます。


Windows Embedded Compactは、今後も、マルチメディアやリッチなUIを実装し、どんどん高機能な組み込みOSとして発展していきます。その中で、今以上に開発納期の短縮、デバッグ手法の確立がより重要になります。
高信頼性が求められ、かつ高機能なこれからの組込機器を上手に開発する為、マイクロソフトから提供されるツールや、いろいろなサードベンダーから提供されるツール、最後には開発経験の多いベンダーのリソースも積極的に活用いただき、開発効率の向上をすすめていきましょう。