バグレポートにどう対処するか?
ある一つのWindows 7 のバグ レポートのため、チームの何人かはこの 2 日、忙しく過ごしました。この問題についての詳細はそれほど重要ではなさそうなので、その内容そのものよりも今回はその例を使用して、私たちがこの種の状況にどのように対処するか、その背景とプロセスについて説明したいと思います。
今週、あるブログで Windows 7 でクラッシュする問題が報告されました。クラッシュを再現する手順はとても簡単で、(1) システム ドライブ以外のドライブで chkdsk /r を実行すると、その後システム メモリが消費されてクラッシュが発生するというものでした。「再現」が容易だったので、この件は急速に広がりました。それに続く投稿やコメントは、この問題が他のユーザーによっても再現されることを示していました。このレポートには 2 つの特徴があり、(a) 多くのメモリを消費して、(b) クラッシュする、ということでした。
すぐに、私はこのレポートに関する多くのメールを個人的に受け取とるようになりました。多くのみなさんと同様、私が最初にしたことは、それを試してみることでした。そして、ご想像のとおり、私はどちらの問題も再現できませんでした。が、メモリの使用は確認しました。別のコンピューターでもやってみて、同じことを確認しました。どちらの場合も、コンピューターは chkdsk 中も chkdsk 後も正常に機能しました。いつものように、私は受信したほとんどのメールに返信し、クラッシュの再現手順の説明と、システム ダンプ ファイルの共有をお願いしました。メモリの使用については、クラッシュほど心配ではありませんでした。興味深いメールのやりとりをかなりの数しましたが、再現ケースに関する手がかりや対処すべきクラッシュ ダンプを得るには至りませんでした。
もちろん、Microsoft 社内で最初にこれを知ったのは私ではありません。ファイル システムのチームは、直ちに問題を調査し始めていました。彼らもまた、クラッシュを再現することができませんでした。彼らの分析によると、このメモリ使用は計画的なもので、このシナリオに対する Windows 7 特有の変更点でした。(/r フラグは、排他的ロックを使用してディスクを修復します。したがって、私たちの仮定は、コンピューター上で何かを行う前に、ユーザーはディスクが修復されて欲しいと考えているということです。これは、このトピックに関するその後の複数の第三者によるブログ投稿によって立証された仮説でもあります)。私たちはさらに調査を進め、クラッシュ ダンプとレポートを探し続けました。下記に述べるように、私たちは自由に使えるかなり多くのツールがあります。
調査を続けている間、私が受け取るメールの雰囲気はエスカレートし、さらに重要なことに、私が返信したうちの 1 人が、ブログの投稿で私たちのメール交換について言及しました。そのため、電子メールでふつうに対話しようとしていましたが、それは話し合いの途中で終了せざるを得ませんでした。Windows 7 の開発中、きわめて慣例的に行ってきたように、私は元のブログ (および、この特定のメル友がコメントしているブログ) にコメントを追加し、私たちが行っている手順やその時点でわかっている情報を説明しました。面白いことに (残念なことではありません)、コメントを投稿するだけで、取り上げられたこの問題にさらに多くの注意が向けられました。個人的に、私は広いコミュニティのメンバーであるのが大好きなので、多少混乱を引き起こすような場合でさえ、当事者になることを楽しんでいます。
クラッシュの問題に関するレポートを受け取ったときの内部プロセスは、まさに説明する価値があります。数年前まで、私たちは次の 2 つの対応のうち、どちらか 1 つを行っていました。バグを見つけられそうにないので降参する、あるいは、すべてを後回しにして、再現可能なケースを見つけられるかもしれないという希望を抱いて、ターミナル デバッガーを持って飛行機に乗る、です。このどちらも特別に効果的であるということはなく、後者は非常に英雄的に聞こえますが、努力にみあった結果を生み出しません。最も重要なことは、クラッシュの可能性があったとして、それがただ 1 つの事例なのか、それとも多くのユーザーが遭遇している、または遭遇しうるクラッシュなのか、私たちには分からないということです。私たちは判断の材料となるデータなしで作業していました。
今では、インターネットと製品 (Windows 7 だけではありません) に組み込まれた遠隔測定によって、私たちはソフトウェアの全体的な状態に関して、はるかに明瞭に観察できるようになりました。したがって、初めてクラッシュの報告を受けると、私たちは、そのクラッシュがほかの何百万台ものコンピューター上で発生しているかどうかを確かめます。これは全体的には役立ちますが、クラッシュが 1 つの特定の構成である場合は、もちろん役に立ちません。ただし、統計的に妥当なコンピューターのサンプリングがなされれば、1 つの特定の構成上のクラッシュでも明らかにできます。一定のユーザー ベースの大きさがあれば、これが、そのケースであることはほとんど確実です。たとえば、私たちは報告されたすべてのクラッシュの呼び出しスタックを照会して、特定のプログラムがそのスタック上にあるかどうかを確かめられます。
遠隔測定でクラッシュを見つけたとき、私たちには自由に使えるツールがいくつもあります。もしかすると、みなさんは、クラッシュしたときにこれらが動いているのを見たことがあるかもしれません。送信してもらうデータの量を (同意により) 増やすことができます。クラッシュへの対応として、サポート技術情報を掲載できます (Windows 7 では Action Center で通知されます)。「電話してください」と言うことすらできます。正気でないように聞こえるかもしれませんが、時には役立ちます。出荷済みの製品で突然クラッシュの問題が発生した場合は、事情は多少異なります。おそらく新しいハードウェア デバイス、新しいデバイス ドライバー、あるいは他のソフトウェアが、以前よりも頻繁にクラッシュを生じさせる原因です。しばしば、単に変更したものを確認するだけで、問題の診断に役立ちます。私がこのことを学んだ初めての機会の 1 つが、ある日突然 Word でクラッシュが起こり始めた時です。私たちは何も変更していませんでしたが、人気のあるアドインの新しいバージョンがリリースされ、そのアドインでクラッシュが発生していることが分かりました。しかし、もちろん、エンド ユーザーには Word がクラッシュしているとしか見えません。私たちは、修正プログラムを送り出すためにソフトウェア メーカーと協力する一方、アドインを削除する手順を急いで提供しました。この、変化する状況を見て、診断し、問題に対応する能力は、製品の問題についてどのように考えるかを根本的に変えました。
私たちは絶えず、新しい問題と頻繁に生じる問題 (クラッシュ、ハング、デバイスが見つからない、セットアップの失敗、潜在的なセキュリティの問題点など) を調査しています。実際、企業や OEM の顧客 (そして、つまり、ハードウェア パートナーやソフトウェア メーカーなど) と協力しながら、月に何百もの問題点を調査します。しばしば、コアの Windows コード以外のコード (ドライバー、ファームウェア、ソフトウェア メーカーのコードなど) の変更によって問題が解決することを発見しました。これは、責任逃れをしようということではなく、根本的な原因において修正を行う手助けをするということです。また、毎月の更新プログラム、修正プログラム、および Service Pack で見られるように、Windows の多くのコード変更を行います。修正のほとんどは広範囲に適用可能ではなく、そのため緊急にはリリースされません。広く適用可能な場合は、広くリリースすることをお知らせします。私たちが、広く送り出そうとする変更の量のバランスを取りつつ、広範囲のユーザーに影響を与える重大な問題がないようにする責務をいかに真剣に受けとめているか、みなさんに理解していただくとこはとても重要です。
Chkdsk ユーティリティの調査について、私たちがこの 2 日間どのように仕事に没頭していたかを具体的にお伝えしましょう。私たちはまず、クラッシュの遠隔測定 (ユーザー レベルと「ブルー スクリーン」レベルの両方) に目を通しましたが、chkdsk に関して報告されたクラッシュは見つかりませんでした。もちろん、Windows 7 の開発中に見つかった既存の問題のレポートにも目を通しましたが、何もわかりませんでした。報告された既存のクラッシュ (報告当初からのすべての種類) の呼び出しスタックを照会しましたが、クラッシュの際に chkdsk.exe が実行されているものは見つけられませんでした。そこで、私たちはたくさんのコンピューター上で自動テストを実行し始めました。これらを夜通し実行し、2 日間続行しました。さらに、特定のハードウェア構成に関連づけられたレポートを見て、そのチップ セット、ドライバーおよびファームウェアの異なる組み合わせに基づいた 40 台以上のコンピューターをセットアップし、テストを実行しました。それでも、クラッシュは発生しませんでした (前述のように、メモリ使用については既に理解していました)。コンピューターが応答しないと言う人がいたので、手動テストでそれも確認しましたが、何も見つかりませんでした。さらに、世界中の Microsoft 社員にこの問題を伝え、試してみるよう依頼し (世界中すべての Microsoft の職場を考えると、相当数の固有の構成があります)、数百のテストを実行していました。私たちは、ページ ファイルがない状態で実行すると、クラッシュが発生するという報告を得ました。それは事実かもしれませんが、このユーティリティの問題とは言えないでしょう。なぜなら、物理的に使用可能なメモリよりたくさんのメモリを要求するプログラムでは、物事がひっくり返ってしまう可能性があり、このような構成は汎用的な使用には推奨されません (これは、少数の再現不可能なクラッシュに関する一般的なスレッドのようでした)。興味のある方は、一般的なページ ファイルのトピックに関する Mark のブログを参照してください。注目すべきものが何も見つけられず、問題の可能性は無視できませんでしたが、この時点で、広範囲にわたる問題である可能性は非常に少なくなりました。
一方、私たちは再現が可能なケースを調べるために、外部のブログ、フォーラム、およびの他のクラッシュに関するレポートに目を通し続けました。すべての人にはコンタクトしませんが、フォーラムやレポートがよい成果を導きそうな場合は問い合わせます。公平に見て、火元を見つけようとしているときに多くの「煙」が上がっていると、手助けになりません。私たちは山と積み上げられた多くの「致命的な問題」のコメントを受け取りましたが、追加情報は多くなく、再現可能なケースやクラッシュ ダンプが不足していました。
体系的にクラッシュを排除した、またはクラッシュが発生する状況が定義できたと私たちが納得できるまで、この種の作業は続行されます。これはハードウェア/ソフトウェアに関連する問題なので、このトピックに関して、さまざまなハードウェア メーカーの皆様からの情報を歓迎します。このケースでは、ディスクと関係があったので、ディスクが実際に壊れているか壊れそうになっていて、/r による修復中のディスクの過度の使用が問題を引き起こしているという可能性を排除することができません。また、(ご想像のとおり) コードはこのような障害を処理するように設計されていますが、特定の障害が適切に処理されない可能性があります。実際、テストラボで(数日間テストを継続的に実行していて)、これに関連する障害に 1 回遭遇しました。そのクラッシュは、ディスク用のコントローラーのファームウェア上で発生しました。言うまでもなく、私たちは引き続きこの特定の問題を調査します。
私たちがどれほど真剣にこれらの問題に対処しているかをみなさんに知っていただきたいと思いました。ブログやコメントは時々とてもエキサイトしています。「致命的な問題」のようなものを見ると、誰も注意が引かれます。しかし、それらは建設的かつ合理的な調査を行う助けにはなりません。大規模なソフトウェア プロジェクトは、本質的に極めて複雑です。環境や構成に依存する問題がしばしばあります。既にご存知のように、ソフトウェアはそれが当然だと思われていますが、問題を再現できないことがあります。レポートを調査する方法についてはとても明瞭なプロセスがあり、Windows が、変化する状況に直面してさえ、確実に正常な状態を保つことに重点を置いています。私はこの投稿でいくつかの問題の見方をお伝えしようと思いました。
ソフトウェアのバグを見つけることは常に素晴らしいことです。それが ATM であろうと、映画チケット販売機であろうと、Windows であろうと、そう機能すべきだと思われるように機能していないものを見つけ出すことに、私たちは皆ある誇りを感じています。Windows は多くの人々の製品であって、単に Microsoft の人たちのものではありません。何かが意図されたようになっていない場合、問題に対して効果的に対処できるようにするため、さまざまなパートナーと協力しています。私たちは皆、これからも問題を調べ続け、Windows に期待している品質レベルを維持するためにコードを変更しなければならないような問題が将来発生するであろうことを承知しています。それと同様に、私たちがこの責務をどれほど真剣に受けとめているかをみなさんにわかっていただければ幸いです。
--Steven