IntelliTrace

IntelliTrace によるアプリケーションのデバッグ

Justin Marks

コード サンプルのダウンロード

**バグはどのように修正しますか。**いくつかブレークポイントを設定して、デバッガーの下でプログラムを実行し、少しばかりシングル ステップ実行したら、難なく問題が見つかって他の作業に移ることができるように祈るというのが定石です。

ENIAC が発明された頃から、デバッグのスタイルは変わっていません。この面倒で時間のかかるデバッグ方法は役には立ってきましたが、そろそろもっと簡単にデバッグできるようになるべきです。Visual Studio 2010 Ultimate のリリースでは、新しい IntelliTrace 機能によって、アプリケーションの実行状態についてより詳細な情報が得られるようになり、21 世紀にふさわしいデバッグの手法が実現されます。

Windows Sysinternals の Process Monitor など、他の監視ツールやトレース ツールと同様、Visual Studio 2010 でも、エラーの診断に役立つよう、アプリケーションの実行中にそのアプリケーションについてのデータが収集されます。こうして収集したデータを、IntelliTrace イベントと呼びます。これらのイベントは既定のデバッグ機能の一環として収集されるだけでなく、何より、このイベントを利用することで、デバッガーを再起動しなくても、アプリケーションの少し前の処理を確認できるようになります。

この記事では IntelliTrace を紹介し、日常の開発作業に IntelliTrace がどのように役立つかを説明します。IntelliTrace ではどのようにしてアプリケーションの実行中に発生したイベントを時系列に表示するか、また、開発者はどのようにしてこれらのイベントをデバッグに利用できるかを説明します。次に、アプリケーションについてのさらに詳しい情報を収集して、すべての実行履歴を得るために、開発者が変更できる設定について説明します。最後に、アプリケーションを実行してエラーを再現しなくても、前に記録された、別のユーザー (テスター) によって作成されている IntelliTrace ファイルを使用してアプリケーションをデバックする方法を説明します。

Visual Studio 診断チームでは Visual Studio 2010 の計画に着手した時点で、アプリケーションの問題をどのように診断しているかについて、時間をかけてお客様に伺いました。それぞれ異なるパターンやお気に入りのツールがありましたが、きわめて明確なことが 1 つありました。それは、アプリケーションの問題を診断する従来の方法は難しく、時間とコストがかかるということです。開発者が受け取るバグ レポートは、必ずといえるほど問題を再現する手順が記載されておらずく、内容は「プログラムを使っていたらクラッシュした」というように表現されているのがほとんどです。まれにある程度の再現手順が含まれていることがありますが、特定の環境で発生するバグに直面することがあり、そうなると解決しなければならないのはまったく別の問題になります。また、フレームワークや他のコードの動作が正しく理解されていないために、バグが起きていることもよくあります。

このような問題点を踏まえて、問題が発生した時点で適切な情報が収集される新しいデバッガー機能の作成に取り掛かりました。目標は、診断能力を劇的に向上できるよう、開発者に正確な再現手順とシステムの環境設定を提供することと、使用されているフレームワークとコードの動作を明らかにすることです。Visual Studio 2010 Ultimate のリリースに伴い、IntelliTrace が提供され、アプリケーションとフレームワークの動作についてより詳細な情報が得られるほか、テスターが収集した IntelliTrace ファイルを開けば "現象再現せず" シナリオに対応できるため、デバッグ機能が大幅に向上します。

IntelliTrace の概要

コードの実行状態をより詳しく理解する必要がある場合に、IntelliTrace では、アプリケーションの完全な実行履歴を収集できるように設定を調整することができます。

これを説明するため、ここでは Tailspin Toys デモ アプリケーションを使用して、IntelliTrace によって収集できる情報の種類を紹介します。まず、Visual Studio でこのソリューションを開き、デバッグを開始します。Web サイトが開き、"About us" ページにアクセスしたところ、サーバーからエラーが返されました。この問題はどのように診断するでしょうか。私と同じような方なら、web.config ファイルを構成して、カスタム エラーを非表示にし、デバッガーを再起動することが、最初に思い浮かぶでしょう。しかし、問題が断続的に発生するとしたらどうでしょう。エラーが発生したら、その時点でプロセスに割り込み、アプリケーションのイベントの履歴を Visual Studio で参照できれば便利だと思いませんか。

デバッグ中に、IntelliTrace はバックグラウンドでマネージ アプリケーションについてのデータを収集します。これには、ADO.NET、ASP.NET、System.XML など、さまざまなフレームワーク コンポーネントの情報が含まれます。これらの IntelliTrace イベントから、実行中にそれまでに何が起きているかを把握でき、なんといっても、デバッガーを再起動することなく、"時間をさかのぼって" アプリケーションの以前の状態を把握できます。デバッガーに割り込むと、直ちに、収集された IntelliTrace イベントが発生順に一覧されます (図 1 参照)。

図 1 IntelliTrace によって収集された診断情報

図 1 からわかるように、IntelliTrace イベントの一覧には、プロセス モニターに表示されるようなファイルやレジストリ アクセスよりもはるかに多くの情報が含まれています。Visual Studio 2010 では 150 近くの IntelliTrace イベントを定義しています。また、時間をかけてイベントを追加していき、この一覧を拡充する予定です。図 2 に、IntelliTrace によって収集されるイベントのカテゴリの一部を紹介します。

図 2 Microsoft .NET Framework のすべての要素をカバーする IntelliTrace イベント

カテゴリ	説明と収集データ
ADO.NET	SQL に対するクエリ実行関連のイベント。実行コマンドと接続文字列。
ASP.NET	ASP.NET パイプライン、および要求の処理とリダイレクト関連のイベント。
コンソール	コンソール出力。
データ バインド	Windows フォームのデータ バインド。
環境変数	プロセスの環境変数の評価と取得。
ファイル	ファイルの作成、削除、およびアクセス。
ジェスチャ	Web フォーム、Windows フォーム、および WPF からコモン コントロールに対して実行されたユーザー操作。コントロールとの相互作用についてのデータを収集するだけでなく、これらのイベントの 1 つをクリックすると、自動的に適切なイベント ハンドラーにリダイレクトされます。
遅延初期化	遅延読み込みされた変数の初期化。
レジストリ	レジストリ情報の作成、削除、および照会。
サービス モデル	WCF からの Web サービス呼び出し。
スレッド	ユーザーの作業項目と並列コンピューティング タスクのキュー。
トレース	デバッガーのトレース出力とアサーション。
ユーザー プロンプト	Windows フォームおよび WPF メッセージ ボックスの表示と、ダイアログの結果の表示。
ワークフロー	アクティビティのインスタンス化と完了。
XML	XML ファイルの読み込み。

IntelliTrace ウィンドウでは、カテゴリ (図 2 に表示されているカテゴリ) またはスレッドを基に収集されたイベントの一覧にフィルターを適用することができます。また、テキスト ベースの検索を実行して、重要なイベントを見つけ、すばやくそのイベントに移動することもできます。IntelliTrace では例外も収集されるため、"例外" をキーワードに検索を実行すれば、一覧が絞り込まれて、ASP.NET エラー ページの原因になった例外について、例外がスローされた場所とキャッチされた場所の両方が表示されます。この例の場合は、エラーは 10 行目の位置 53 のエンティティを解析中に発生した XMLException が原因でした (図 3 参照)。スローされた例外イベントをクリックすると、呼び出し履歴ウィンドウやウォッチ ウィンドウなど、他のデバッガー ウィンドウに、そのイベント自体に関連するデータが表示されるので、例外がスローされた瞬間をデバッグしているのと同じです。また、呼び出し履歴をたどるように、適切なソース ファイルが開かれて、イベントに対応するコードの行が、IntelliTrace を表すオレンジ色で強調表示されます。

図 3 行10、位置 53 のエンティティの解析中にスローされた XMLException

IntelliTrace は、この問題を診断するうえで非常に有益な情報を提供しています。つまり、XML ファイルが読み込まれ、この XML 内の特定の文字が、予期しないまたは正しくない文字でした。しかし、それでも、どのファイルにアクセスされたかはわかりません。この場合も、IntelliTrace によって必要な情報 (具体的には、ファイル アクセス) が収集されていました。

図 3 の IntelliTrace ウィンドウを再び確認すると、例外のすぐ前のイベントが "Content\Xml\Ads.xml" に対する XML ファイル読み込みイベントであることがわかります。これがエラーの原因となったファイルに違いありません。このファイルは簡単に Visual Studio で開くことができます。10 行目の位置 53 を見ると、このファイルに実際にエラーがあることがわかります。具体的には、"&b=1" は NavigateUrl XML 要素としては無効です。これらの無効な文字を削除すれば、Web サイトは正しく読み込まれるようになります。

ここで、従来のデバッグ手法を使用して最近デバッグしたハンドルされていない例外について思い出してみてください。この例のような例外の場合、例外の発生場所は確認できても、正確な理由や無効な文字は間違いなく確認できないと思います。これが、IntelliTrace のポイントです。IntelliTrace では、問題を診断するためのより有用な情報をよりすばやく、簡単に取得できます。開発者には情報を求めて時間を無駄にするよりも、他に重要なやるべきことがあります。

IntelliTrace を使用してデバッガー イベントを追跡する

IntelliTrace がアプリケーションの実行中に発生した例外 (ハンドルされている例外とハンドルされていない例外の両方) を収集する方法と、フレームワーク全体をカバーする IntelliTrace イベントから、アプリケーションの内部でどのようなことが発生しているかをどのようにして読み取ることができるかについて説明しました。ただし、それだけではありません。IntelliTrace では、デバッガーによって発生したイベント、つまり、ブレークポイント、トレースポイント、およびステップ イベントも収集されます。

最も一般的なデバッグ手法の 1 つは、問題が存在すると思われる付近にブレークポイントを設定して、コードをステップ スルーし、変数の変化を観察する方法です。これは、ループをデバッグして、変数が特定の値に変わるのを観察する場合に特に便利です。残念ながら、ほとんどの開発者は、せっかちで F10 キーを連打してコードを手早くステップ スルーしますが、結局先に進み過ぎてしまいます。そうなると、デバッグ セッションを最初からやり直さなければなりません。IntelliTrace があれば、すべてのブレークポイントとステップ イベントが、そのときどきのデータと併せて記録されるので、以前停止した場所にすばやく移動できます。

これらのデバッガー イベントの 1 つをクリックすると、ローカル ウィンドウ、ウォッチ ウィンドウ、および自動変数ウィンドウのほか、クイック ウォッチやデータヒントで評価した値を含め、以前参照したすべてのデータがウォッチ ウィンドウに表示されます。

以前に開発したコードや配置済みのコードには、問題が発生した場合にデバッグに利用できる、必要なトレースが組み込まれていないことがよくあります。ブレークポイントを使用すると、アプリケーション内部で発生している処理を詳しく確認できます。ただし、ほとんどの場合、開発者はブレークポイントで停止する必要はなく、データを収集し実行を続行します。これは、特に、内部ループで繰り返しのたびに停止することなく、反復子の値を記録する場合などが該当します。このようなシナリオでは、トレースポイントを代わりに使用すると便利です。トレースポイントを使用すると、デバッガーによってカスタム動作を実行できます。つまり、実行を中断するのではなく、マクロを実行したり、トレース メッセージを出力したりできます。IntelliTrace では、トレースポイントの出力を収集し、IntelliTrace イベントと同じインターフェイスで確認できます (図 4 参照)。

図 4 トレースポイントによりトレース出力をコードに動的に追加

設定を調整する

既定では、IntelliTrace は IntelliTrace イベントのみを収集するように構成されています。これは、オーバーヘッドの少ないソリューションですが、アプリケーションの完全な実行履歴は得られません。より詳細な情報が必要な場合は、IntelliTrace を構成してより多くのデータを収集できます。他のデバッガー設定と同様に、IntelliTrace も [ツール] メニューからアクセスできる [オプション] ダイアログ ボックスで構成できます (図 5 参照)。

図 5 IntelliTrace 設定は [オプション] ダイアログ ボックスから変更可能

[IntelliTrace イベントと呼び出し情報] チェック ボックスをオンにすると、IntelliTrace によって IntelliTrace イベントだけでなく、メソッドの開始、終了、呼び出しサイトごとの呼び出し情報 (各時点でのパラメーターや戻り値など) も収集されます。残念ながら、このモードを有効にすると、デバッグ中はエディット コンティニュが無効になります。明らかに、より詳細な情報を収集するということは、アプリケーションのオーバーヘッドが大きくなります。有用な情報とパフォーマンスとのバランスを取るべく苦慮しましたが、ユーザーが完全に制御できるようにしています。

デバッグ セッションごとに、IntelliTrace ファイルが作成されてディスク保存されます。このファイルは、Visual Studio の終了時に自動的にクリーンアップされます。[オプション] ダイアログ ボックスから表示できる IntelliTrace の [Advanced] (詳細設定) ペインでは、デバッグ中に作成されるファイルの格納先と、ファイルの最大サイズを構成できます。ファイルの最大サイズに達すると、循環バッファーを利用して IntelliTrace ログに格納されている情報の圧縮と切り捨てが図られ、ログ ファイルのディスク上のサイズを削減します。[Advanced] (詳細設定) ペインの残り 2 つの設定は、ナビゲーション余白を非表示にできる設定と、Team Foundation Server (TFS) による利用可能なシンボルのルックアップを無効にできる設定です。

パフォーマンスを考慮し、既定では、収集が有効になっているのは定義済みの IntelliTrace イベントの一部のみです。有効にするかどうかの検討が必要なイベントとしては、コンソール出力、ファイル アクセス、遅延初期化、レジストリ アクセス、スレッド イベントがあります。[オプション] ダイアログ ボックスの [IntelliTrace イベント] ペインから、あるイベントのカテゴリ全体を有効または無効にすることも、個々のイベントを有効または無効にすることもできます。

最後の IntelliTrace の [オプション] ダイアログのペインでは、IntelliTrace がデータを収集する対象のモジュールを制御できます。既定では、Microsoft .NET Framework および Visual Studio の一部としてマイクロソフトから提供されているモジュール以外のすべてのモジュールが、収集対象になります。この方法では膨大なデータが収集される可能性があるため、このリストを信頼のリストにして、必要なモジュールのみを指定するのも一案です。反対に、サードパーティの共通ライブラリを使用している場合は、これらを制御することはできないので、除外するとよいでしょう。

ユーザー コード エラーを調査する

デモ アプリケーションの "About us" ページが正常に機能することを確認できたので、ショッピング カートも問題がないか確認してみましょう。紙製の飛行機を購入するためにカートに追加すると、実際に正しくカートに追加されています。ただし、この操作を繰り返して同じ商品の 2 つ目のインスタンスをカートに追加しても、個数は 2 にならず 1 のままです。デバッガーを使用して、再起動せずに、この問題を解決したいのですが、このシナリオでは IntelliTrace イベントの一覧はおそらく役に立ちません (この作業のすべては、.NET Framework ではなく私が作成したコードで処理されているため)。このようなときに、IntelliTrace の "IntelliTrace イベントと呼び出し情報" モードによって、アプリケーションの実行履歴を確認できます。デバッガーに割り込み、この問題の解決に使用できる IntelliTrace のその他の機能を確認してみましょう。

ここでは、"Add Item to Cart" ロジックに問題があると仮定してデバッグを始めます。これは、モデル-ビュー-コントローラー (MVC) アプリケーションであるため、ボタン クリック用のイベント ハンドラーはありませんが、POST メッセージが MVC によって送信および処理されます。この POST メッセージは、IntelliTrace イベントとして記録されます。このイベント自体は役に立ちませんが、これを調査の起点に使用します。この IntelliTrace イベントをクリックすると、デバッグ セッションの "Add Item" ロジックが開始する場所に移動できます。IntelliTrace ウィンドウで "POST" をキーワードに検索することで、これらの POST メッセージを簡単に見つけることができます。この操作はユーザーによって 2 回実行されているため、予想どおり、この検索では 2 件の結果が返されます。2 つ目のイベントを選択して検索フィールドを閉じると、収集されたすべてのイベントと併せて、発生タイミングがわかる形で 2 つ目のイベントが表示されます (図 6 参照)。

図 6 IntelliTrace イベント ビューを基に調査を開始

アプリケーションのタイムラインで、どの段階にあるかを確認できたので、さらに先に進み、実行されたメソッド呼び出しについて把握したいと思います。イベント ビューから切り替えて実行履歴を確認できます。ウィンドウ上部にある [[呼び出し] ビューに切り替え] リンクをクリックすると、呼び出しビューに移動し、アプリケーションの完全な実行履歴を確認できます (図 7 参照)。[[IntelliTrace イベント] ビューに切り替え] リンクをクリックすることで、いつでもイベント ビューに戻ることができます。

図 7 IntelliTrace の呼び出しビューに表示されたアプリケーションの実行履歴

実行履歴内を移動するメカニズムの 1 つは、呼び出しビューを使用して、調査する呼び出しの詳細を参照する方法です。呼び出し履歴で履歴をさかのぼってライブ デバッグを実行する場合と同様に、呼び出しビューの下半分で呼び出しをダブルクリックするたびに、その呼び出しがビューの上半分の下部に表示され、コード エディター内で命令ポインターと呼び出しのメソッド エントリ ポイントが同期します。この方法で、IntelliTrace の履歴によって収集されたデータ内を移動し、前後に進むことができます。呼び出しビュー内を移動することで、実行履歴の概要をすばやく把握でき、コード ベース内を自在に移動できます。

呼び出しビューを使用する方法は、ナビゲーションの方法の 1 つにすぎません。コードをステップ実行することでも、ナビゲーションが可能です。ソース コード ウィンドウの余白に、従来のデバック セッションと同じようにコードをステップ実行できる DVR 型のコントロールのセットが追加されています (図 8 参照)。ここでは IntelliTrace のデバッグ モードであるため、ステップ実行は、呼び出しサイトごとに発生する記録対象のイベント (関数の開始と終了) を基準に実行されます。キーボードから操作する場合は、もちろん、F10 および F11 キーを期待どおりに使用できます。

図 8 新しいナビゲーション バーにあるアプリケーションのステップ実行を可能にする DVR 型のコントロール

上記の 2 種類のナビゲーション方法は、調査には非常に便利ですが、ブレークポイントを設定している場所が正確にわかっていることもあります。このアプリケーションの場合、商品がカートに追加される関数の名前 Kona.Model.ShoppingCart::AddItem がわかっています。本当に目的としていることは、この関数が 2 回目に呼び出された時点に移動し、関数に渡された値と関数から返される値を調べることです。より具体的には、"AdjustQuantity" 関数が呼び出されたコード行をシークすることです。もちろん、IntelliTrace ではこのようなナビゲーション手法もサポートしています。

エディターで、シークする行を右クリックし、コンテキスト メニューの [この行を IntelliTrace で検索] をクリックします (図 9 参照)。検索が開始され、結果がエディター ウィンドウ上部にある検索バーに表示され、そこで検索結果間を移動できます。2 番目の検索結果に同期すると、求めている箇所に命令ポインターが置かれ、他のデバッガー ウィンドウを使用して呼び出しを調べることができます (図 10 参照)。

図 9 検索機能を利用して、特定の関数呼び出しにジャンプ可能

図 10 エディター ウィンドウの上部の検索結果バーに表示された検索結果

この時点でローカル ウィンドウを見ると、カート内の商品の新しい個数が 1 になるように、カートが調整されているのがわかります。これはバグです。調整後の個数は 2 になる必要があります。問題のコード行を見ると、新しい個数のパラメーターは、"item.Quantity" だけでなく、関数呼び出しに渡される "quantity"変数も考慮する必要があります。修正するには、この関数呼び出しを次のように変更します。

AdjustQuantity(product, item.Quantity + quantity);

いまわしい "現象再現せず" シナリオをなくす

テスターが不具合を登録しても、「こちらのコンピューターでは再現できなかった」というコメントで解決されるという、"現象再現せず" の押し問答がテスターと開発者間で発生することがあまりに多くあります。開発者もテスターもこのような押し問答は望んでいませんが、問題が発生した時点で何が起きたかについて伝達するための適切なツールがないのです。デバッグ セッション中に開発者が IntelliTrace から得られる診断情報と同じものを、Microsoft Test Manager (MTM) から手動でテストを実行している間に収集できるようにシステムを設計したのはこのためです。

"About us" ページを適切に表示できないという、この記事でデバッグした最初のシナリオに戻ってみましょう。テスターがこのバグを登録するときは、おそらく「情報ページの表示時のアプリケーション エラー」のようなタイトルを付け、開発者の運がよければ、エラーのスクリーンショットが添付されているかもしれません。では、このようなバグが登録された場合、現状ではどのようにデバッグするでしょう。最もよく行われるのは、アプリケーションのソリューションをソース管理から読み込み、開発コンピューター上で問題を再現する方法です。この場合、問題をデバッグし、エラーを解決できますが、このために費やす時間を考えてみてください。または、問題が開発者のコンピューターとテスターのコンピューター間の構成の違いが原因であった場合どうなるでしょう。再現環境を設定しないで問題をデバッグできれば、開発者の生産性は格段に上がります。

Visual Studio 2010 では、MTM を使用することで、テスターは手動テストと自動テストの両方を便利に作成、管理、および実行できます。ただし、それだけではありません。MTM では、テストの実行中に、バックグラウンドで診断データ アダプターにより情報を収集することができます。たとえば、テストの実行中に自動的にビデオを録画し、テスターが確認した現象そのものを開発者が確認できるようにすることができます。その他のコレクターでは、テストを実行しているコンピューターのシステム情報とイベント ログを収集できます。

バックグラウンドで IntelliTrace ファイルを自動的に収集する IntelliTrace 診断データ アダプターを追加しています。テスターがテスト ステップを通過できず、バグを登録することにした場合、収集された IntelliTrace ファイルが自動的に TFS にアップロードされ、バグにリンクされます。このため、開発者は、単なる再現手順よりもはるかに豊富なデバッグ情報が得られます。開発者がバグにリンクされている IntelliTrace ファイルを開くと、ミニダンプのデバッグと同様の操作を実行できます。ただし、この場合は、アプリケーションがクラッシュした時点だけではなく、アプリケーションのタイムライン全体が対象です。IntelliTrace データの場合、IIS の下で実行中の ASP.NET アプリケーションなど、ローカルまたはリモートのテスト エージェント上のどのマネージ アプリケーションのデータでも収集できます。

この例では、TFS バグを開くと、MTM によって自動的に、テスターが記述した手動のテスト ステップを基に再現手順が追加されています。さらに便利なことに、バグの [すべてのリンク] タブを見ると (図 11 参照)、IntelliTrace ファイルも収集されています。このファイルをダブルクリックすると、IntelliTrace ファイルの概要ページ ビューに移動します (図 12 参照)。

図 11 収集された IntelliTrace ファイルには [すべてのリンク] タブからアクセス可能

図 12 IntelliTrace の概要ビューから収集されたデータを確認可能

概要ページでは、IntelliTrace ファイルの内容について、さまざまな情報を確認できます。ページ上部には、アプリケーションのスレッドのタイムラインが表示されています。概要ページの [スレッド一覧] のセクションを展開すると、これと同じデータが表形式で表示されます。任意のスレッドをダブルクリックすると、IntelliTrace ファイルからデバッグ セッションが開始され、命令ポインターがそのスレッドの先頭に置かれます。

また、この IntelliTrace ファイルでは、収集されたすべての例外の一覧も確認できます。任意の例外を選択すると、スレッドのタイムラインにオレンジ色の縦線が表示され、例外が発生した時点が示されます。例外をダブルクリックすると、IntelliTrace デバッグ セッションが開始され、該当する例外イベントが IntelliTrace のイベント ビューで選択されます。さらに概要ページの下の部分には、手動の再現手順に対応しているすべてのテスト イベントの一覧が表示されます。各手順の結果も表示されます。これらのイベントの 1 つをクリックしても、スレッドのタイムラインに縦線が表示され、イベントをダブルクリックすると IntelliTrace デバッグ セッションが開始し、最も近いと思われるイベントが選択されます。概要ページの下部には、テスト対象のアプリケーションが実行されていたコンピューターについて、収集されたシステム情報の一覧が表示され、その下には、プロセスに読み込まれたモジュールとそのパスの一覧が表示されます。

これはリリース ビルドにも使えるかどうか、疑問に思われているかもしれません。もちろん使えます。また、IntelliTrace データの収集または表示時に、シンボルにアクセスする必要はありません。シンボルが必要なのは、デバッグ セッションを開きやすくするために、収集されたデータをソース ファイルにリンクする場合のみです。

Visual Studio 2010 および TFS では、シンボルとソース サーバーのサポートが追加されているため、TFS ビルド システムの一部としてアプリケーションがビルドされている場合、IntelliTrace で必要であれば、正しいバージョンのシンボルとソース コードが自動的に TFS からダウンロードされます。シンボル サーバーのパスを把握しておく必要さえありません。

概要ページからデバッグ セッションを開始すると、デバッガーはライブ デバッグ セッションと同様に動作します (図 13 参照)。ほとんどのデバッガー ウィンドウを利用でき、IntelliTrace が収集したどのデータでも参照できます。

図 13 概要ページからデバッグを開始すると、Visual Studio はライブ デバッグ セッションと同様に機能

まとめ

この記事では、IntelliTrace によって、日常の開発作業の効率だけでなく、アプリケーションの再起動や "中断-ステップ実行-調査" という従来の手法でデバッグをせずに、問題をすばやく簡単に診断できる能力が大幅に向上することを説明しました。また、テスト中に IntelliTrace データを収集し、開発者が実機で問題を再現しなくてもオフラインで問題をデバッグできるようにすることで、"現象再現せず" バグの数を削減できることも説明しました。この記事は IntelliTrace の機能を簡単に紹介したものにすぎず、IntelliTrace の機能についての知識が深まるにつれて、デバッグの方法が変わり始めるでしょう。

Justin Marks は、MIT でコンピューター サイエンスおよびエンジニアリングの理学士号を取得した後、2002 年にマイクロソフトに入社しました。MSN.com のシステム エンジニア、および Windows のテストのソフトウェア デザイン エンジニアを経て、現在は Visual Studio のプログラム マネージャーを務めています。診断チームの PM として、次期リリースの Visual Studio 2010 の IntelliTrace 機能の開発に取り組んでいます。

この記事のレビューに協力してくれた技術スタッフの Bill Boris、David Gray、Habib Heydarian、および John Robbins に心より感謝いたします。