デバッガとは？

ソフトウェアの障害

ソフトウェアの障害は、自動車のトラブルなどとは明らかに性質が違います。

例えば、普通ならこんな話はあるでしょうか。考えてみてください。

「ある日、あなたは家族でドライブをしています。山道を登っていると、なぜか車が止まってしまいました。挙句にエンジンもかからない。困り果て、その日は電車で帰ることにし、車を修理に出すとしました。あくる日自動車整備会社から電話があり、トラブルの原因を知らされました。車が止まった原因はなんと、灰皿にタバコがいっぱいになっていたことでした。」

この話はもちろん作り話ですが、読者の感想は「まさかタバコの吸殻がたまったくらいでエンジンが壊れてたまるか。そんなことあるか」というものではないでしょうか。

さらに、もうひとつ作り話を。

「あなたは会社の事務を担当しています。大事なデータはバインダーにまとめ、毎日金庫に保管しています。金庫は鉄製で極めて重く、泥棒に持っていかれる心配もなく、耐火加工もしてあるので火事が起きても安心です。しかし、ある日、朝会社に来て金庫を開けると、あろうことかファイルしていたはずの書類の文字が皆消えてしまっていました。」

普通はこんな事は起きないといってよいでしょう。

はじめの例では、自動車のエンジンが故障した原因が、「灰皿」とか「ジュースホルダの缶コーヒー」であるわけがないのです。だから、そういうものははじめから原因にならないとわかっているので、原因調査の調査リストには入りません。

後者の例では、密閉された空間においてある文書の文字だけが一晩で消えてしまうことなど現実ではありえないのです。これらは極端な例ではありますが、恐ろしいことにソフトウェアの世界ではこれに似たような話が実際に起こりうるのです。

つまり、まったく関係がない、起こりえない、想像もできないと思えるようなことが原因となり、大事なシステムが故障したり突然データが消失したりするのです。

ソフトウェアのトラブル解決では、ある程度のあたりをつけることは大切ですが、さまざまな可能性を念頭に入れながら、データに基づき、冷静に、今何が起きているか判断する必要があります。

トラブル発生！さて、あなたは何をしますか？

適切なツールを使って適切な箇所を診断することで問題解決の最短経路を進むことが大切です。

しかしながら、通常特に対策が無い限り運用時のアプリケーションから取得できるもの、といったらせいぜいこんなデータしかありません。

イベントログ
パフォーマンスデータ
IIS アクセスログ
クラッシュダンプ (あるいは完全なメモリダンプ)
sysinternals や Windows SDK のツールによる診断
その他サードパーティ製アプリケーションが出力するログファイル

システムに障害が発生したときには、これらの情報を読み取って原因を突き止めシステムを復旧しなければなりません。

もちろんある程度切り分けが進み、「なるほどどうもデータベースに接続する際にエラーが発生するらしい」とわかれば SQL Server のプロファイラやネットワークトレースなども使えるでしょう。

しかし、はじめの第一歩はいつも大体同じでせいぜい上に挙げたデータから、次の一手を考えなければなりません。

そこで、システムの停止時に出力されるログから少しでも多くの情報を引き出すことを考えましょう。

上に挙げた中で特に、メモリダンプから多くの情報を引き出すことについて考えてみましょう。そこで登場するのが CDB や WinDbg などのデバッガです。

デバッガとは

ご存知の通りソフトウェアの不具合は バグ (bug) と呼ばれます。

バグとは "虫" の意味でソースコードの中に虫が食っているイメージです。バグはあるとき突然現れたり、突然障害がしなくなったりします。これはあたかも本物の虫のようです。

また、バグをとる、つまり不具合を修正する作業は デバッグ (debug) といいます。

デバッガ (debugger) とは、デバッグ作業を支援するためのツールのことです。

プログラム開発者は日常的に Visual Studio などの統合環境の中でコードを書き、テストし、そこで見つけたバグは直ちに修正をするという作業を繰り返しています。

現在、Windows プログラミング開発環境の主流は Visual Studio での開発といってよいでしょう。

VB や Visual C++ (VC), C# にしてもそれぞれデバッグ機能が充実しています。プログラムを実行しながらプログラム内で使用されている変数の値を確認するウォッチウィンドウやイミディエートウィンドウ、そしてメモリの表示、コールスタックの表示などの機能が豊富に用意されています。

VB や VC などのアプリケーション開発統合環境を利用することでアプリケーション開発の生産性は向上する場合が多いでしょう。

しかし、そもそも生産性を問題にする以前に統合開発環境でしかアプリケーションを扱えないと考えている開発者も少なくないのではないでしょうか。

統合開発環境でしかプログラムを操作できないと、ソースファイルがない状態、すなわち実行中の本番環境等でシステム (アプリケーション) の調査ができません。

本番環境で速やかに問題解決するには、統合開発環境ではないところでシステムの診断の知識が必要なのです。

デバッガを使うと実行中のアプリケーションの様子をチェックすることができます。

さらに、システム障害の時にクラッシュダンプと呼ばれるメモリダンプが出力される場合があります。

デバッガを用いるとクラッシュダンプの内容を確認することができます。常に成功するとは限りませんが、クラッシュダンプから障害を発生させた原因をある程度絞り込むことが可能になります。