トラブルシューティングと修復: 電力消費量を削減し処理速度を向上させる
アプリケーションの読み込みが効率的に実行されるようにすると、インフラストラクチャ操作にかかる時間とコストを節約することができます。
Wes Miller
この世界には、未解決の疑問が非常にたくさんあります。脳のしくみは実際どうなっているのでしょうか。だれがどのようにしてピラミッドを建設したのでしょうか。カモノハシはどうなっているのでしょうか。私のコンピューターはなぜこんなに処理速度が遅いのでしょうか。脳、ピラミッド、カモノハシについての疑問は未解決のままかもしれませんが、コンピューターの処理速度がなぜこんなに遅いのかという疑問について考えてみましょう。
非効率的なソフトウェアがインストールされたコンピューターにはコストがかかります。こうしたコストは、ユーザーの生産性の低下、電力消費量の増大、バッテリ寿命の低下、熱的消耗、ディスク エラーなどによって発生します。問題のあるソフトウェアを無視しても、うまくいくことはなく、多くの場合、コストと時間の面ではるかに大きな問題につながります。
マイクロソフトは、Windows XP を世に出すとき、(多くのユーザーが "トレイ" と呼ぶ) Windows 通知領域の UI が扱いやすいものになるようにするためにかなりの時間を費やしました。残念ながら、非常に多くのソフトウェア開発者がこれを乱用したため、ログオン時に 10 個を超えるアイコンが通知領域に表示される新しいコンピューターなどは珍しくありませんでした。
すべてのものにはコストがかかります。また、通知領域に表示されるこうしたアプリケーションそれぞれのコストは、デスクトップの領域だけではありません。それぞれが少なくとも 1 つの実行中のアプリケーションを表します。また、Windows は、バージョンを追うごとに以前のバージョンよりもサービスが増えていきます。要するに、コンピューターが OEM から入手されたものである場合でも、標準的な企業デスクトップ イメージを基にしている場合でも、また、自分で Windows をインストールした場合でも、コンピューターでは数多くのものが実行されています。
速度の向上
「なぜ Windows が起動しないのか」の他に私がよく聞かれる質問の 1 つは、「なぜこのコンピューターはこんなに処理速度が遅いのか。また、これを解決するにはどうすればよいか。」というものです。
同じイメージを基にした 2 つのコンピューターがある場合 (特に、そのうちの 1 つだけで現象が発生している場合)、2 つのシステムを比較してその違いを特定することは常に興味深い出発点となります。この後で紹介するツールを実行すると、多くの場合、問題のあるプロセスをはるかに簡単に見つけることができます。
コンピューター上のリソースについて考えた場合、簡単に言うと、全体的な処理遂行能力に影響を与えるリソースには次の 4 種類があります。
1. メモリ (RAM)
2. CPU
3. ディスク I/O
4. ネットワーク I/O
これから、皆さんがこの作業を行うのを手助けするうえで、私は Sysinternals Suite をかなり活用するつもりです。Sysinternals Suite を既にお持ちの場合は、作業に取り掛かりましょう。お持ちでない場合は、Windows Sysinternals ダウンロード ページから入手してください。
作業に取り掛かる前に、コンピューターで実行されているものについての基礎知識を得ましょう。Sysinternals ツールでは 2 つの選択肢があります。情報をどのような形で確認したいか、および診断する必要があるコンピューターと診断者との位置関係によって、どちらを使用するかが決まります。
プロセス別
1 つ目の選択肢は Process Explorer (Procexp.exe) です。Process Explorer はもう 1 つの選択肢よりはるかに強力ですが、ローカルでしか実行できません (この後すぐに説明しますが、2 つ目のツールは違います)。Process Explorer は、Windows タスク マネージャーに替わる強力なツールと考えていただければ一番わかりやすいでしょう。Process Explorer を使用すると、自分自身のプロセスであれ、ログオンしている別のユーザーのプロセスであれ (ユーザーの簡易切り替えやターミナル サービス/リモート デスクトップを使用している場合)、システム上で実行されているすべてのプロセスをひとめで非常に詳細に確認することができます。
作業に取り掛かる前に、すべてのプロセスが表示される状態で Procexp を実行していることを確認してください。これには、[File] メニューの [Show Details for all Processes] を使用して Procexp を再起動します (UAC を有効にして Windows を実行している場合は、この操作を行うと確認のメッセージが表示されます)。
Process 列を並べ替えると、プロセスを昇順または降順で表示するか、あるいは、各プロセスを起動したアプリケーションに基づいてプロセス ツリーで表示するかを指定することができます。プロセスは、開始し、別のアプリケーションを起動し、終了して、どのプロセスが実際に子を起動したのかについて誤った印象を与える場合があることを覚えておいてください。
最も多くの CPU 時間を使用しているプロセスを確認する最も簡単な方法は、CPU グラフをポイントすることです。ポイントすると、このようなプロセスを確認することができます。その後、Ctrl キーを押しながら F キーを押してそのプロセスを検索することができます。
私がよく聞かれる質問には、「System Idle Process とは何ですか。また、System Idle Process はなぜコンピューター上のすべての CPU を使用しているのですか。」というものもあります。System Idle Process はコンピューター上のすべての CPU を使用しているわけではありません。このプロセスは、使用されていない CPU 時間のプレースホルダーと考えていただければ一番わかりやすいでしょう。実は、これは実際のプロセスですらありません。『Windows Internals』(Microsoft Press、2009 年) をお読みになったことがない場合は、Windows の内部に関する強固な基礎知識を得るためにこの書籍をお読みになることをお勧めします。
次の 2 つの方法を使用できます。
- [View] メニューの [Update Speed] からは、Procexp の UI がデータの変化に応じて更新される頻度を変更できます (更新頻度の選択肢として提供される更新間隔は、比較的短い時間です)。
- CPU 使用率が高いプロセスが最上部まで急上昇するのを確認したら、Space キーを押します。Procexp の UI の更新が完全に停止され、疑わしいプロセスを確認することができます。
大量のメモリを消費するプロセスも、この方法で非常に簡単に突き止めることができます。プロセスの名前を見てもそれが何を指すのか特定できない場合は (プロセスがマルウェアの場合など)、プロセスを選択して [Process] をクリックし、[Window] をポイントすると、アプリケーションを特定することができます (そのアプリケーションに、公開される UI がある場合)。サービスには UI がありません。また、アプリケーションも、UI を持たないようにすることができます (本来ならサービスであるべき一部のレガシ アプリケーションは UI を持たない傾向にあります)。
サービス提供と保護を行う
この診断プロセスはユーザー コンテキストで実行されているアプリケーションには適していますが、サービスやドライバーの場合はどうでしょうか。サービスは、分離した場合の問題がより大きい可能性があります。リソースを節約しセキュリティを強化するためにサービスを "共有プロセス" で実行する傾向が強まっているためです。
Windows には、これを行うための組み込みの方法が用意されています。これには、svchost.exe というサービスが使用されます (Windows XP およびそれ以降の Windows システムでは、このサービスをかなり多く目にするでしょう)。これらの多くは組み込みの Windows サービスですが、サードパーティもこのインフラストラクチャを使用できます。実際、マルウェアが svchost をホストとして使用する傾向が強まっています。
ですが、CPU 使用率や RAM 使用率が高くなる原因となっている svchost のインスタンスを特定することは可能です。各インスタンスをダブルクリックし、[Services] タブをクリックすると、その共有プロセスで実行されている DLL を確認することができ、実際にリソースを消費している DLL を確認することができます。
では、ドライバーの場合はどうでしょうか。ドライバーも、システム パフォーマンス低下の原因になりうるものとして無視できません。ドライバーは、Windows の最も下位のタスクを実行します。ドライバーが問題の原因となることはよくあります。
ドライバーには、他のプロセス (マルウェア対策ソフトウェアなど) の監視、またはファイル通知やディレクトリ通知 (マルウェア対策ソフトウェアやレプリケーション/同期など) の監視の役割が割り当てられていることがよくあります。不適切な動作をするドライバー、または、別のドライバーが存在する場合にだけ不適切な動作をするドライバーは、非常に簡単に作成されてしまいます。後者の方が、診断が困難なので、より大きな問題となります。
では、ドライバーはどこで実行されるのでしょうか。svchost.exe でホストされるサービスと同様に、ドライバーも共有プロセスで実行されます。System プロセスをダブルクリックして [Threads] タブをクリックすると、System プロセスによって読み込まれたスレッド スタックを確認することができます。多くのドライバー (*.sys ファイル) が読み込まれているのをここで確認できます。
個々のプロセスのビューと同様に、CPU 時間に基づいてドライバーを並べ替えることができます。並べ替えると、特定のドライバーによって実行されており、たくさんの CPU 時間を使用しているスレッドが明らかになります。その後、システムを検索してそのドライバーを探したり、インターネットを検索したり、ベンダーに問い合わせてベンダーが問題に気付いているかどうかや新しいバージョンのドライバー ソフトウェアがあるかどうかを確認したりすることができます。
診断するコンピューターにリモートから接続している場合は、ネットワーク経由では接続できますが、TS/リモート デスクトップを使用して接続することはできません。こんなときこそ PsTools の出番です。ここでは PsList が役に立つでしょう。名前からわかるように、PsList は、ローカル コンピューターまたはリモート コンピューターで実行されているすべてのプロセスを一覧表示するコマンド ライン PsTool です (Sysinternals Suite に含まれています)。
他のすべての PsTool と同様に、PsList は、ファイルとプリンターの共有を通じてリモートから実行できます (ファイルとプリンターの共有が有効になっていて、実行するユーザーがローカル Administrators グループのメンバーである場合)。Procexp の場合と同様に、PsList の実行時に実行されていたプロセスの一覧を確認することができます。PsTools が提供する情報はより限られていますが、このような (問題のあるプロセスを診断するなどの) 場合、一般に、作業を完了するには十分です。
ローカル コンピューターに対して PsList を実行するには、単に PsList.exe を実行します。–t スイッチを指定すると、Procexp に似たツリー ビューで表示することができます。–s (秒単位の間隔) を追加すると、定義した間隔で自動ポーリングが行われます。これは、更新頻度を既定値よりも低くすることができる Procexp とは逆です。すべての PsTool はリモートで使用する方法が似ており、使い方は次のとおりです。
PsTool.exe \\systemname -u username –p password
Procexp を使用してローカル コンピューター上のプロセスを強制終了することはできますが (ただし、プロセスを手当たりしだいに強制終了すると、システムの破損やソフトウェア障害が発生することがあるので、注意してください)、PsList を使用してローカル コンピューター上のプロセスを強制終了することはできません。PsKill を使用して、プロセス ID (PID) または名前に基づいてプロセスを強制終了することもできます (名前に基づく場合は、同じ名前を持つすべてのプロセスが強制終了されます)。リモートからこれを行うことも可能です。
ディスク I/O の問題 (特に、システムがハード ディスク上のデータを絶えずシークする原因となっているアプリケーション) を診断するのは複雑であり、場合によっては、十分に診断するのは難しいこともあります。ですが、Process Monitor (Procmon.exe) を実行すると、多くの場合、ハード ディスクへの読み取りや書き込みの頻度が高すぎるサービスやアプリケーションがすぐに明らかになります。ローカル検索ユーティリティなど、多くのアプリケーションには、ディスク I/O を消費する正当な理由があるかもしれませんが、実際のところ、多くのディスク I/O は、より良い方法で処理できる可能性のある反復的なタスクに無駄遣いされています。
読み取りや書き込みの頻度が高すぎるように思われるプロセスを特定したら、Procmon の実行を停止し、Procexp に切り替え、Ctrl キーを押しながら F キーを押してそのプロセスを検索することができます。名前に基づいて検索する場合は、プロセスの PID が同じであることを確認するようにしてください。一部のプロセス (explorer.exe や svchost.exe など) は、複数のインスタンスを持ちます。プロセスを消費するディスク I/O を特定したら、ベンダーに問い合わせて新しいバージョンがあるかどうかを確認することができます。
ネットワーク通信に関しては、TCPView という別の Sysinternals ツールを使用して、ネットワークに接続しているプロセス (入力方向または出力方向) を特定することができます (ポート情報を含む)。Procmon でもネットワーク接続を確認できるので、Procmon を使用することもできます。最も重要なのは、頻度の高いネットワーク通信を発生時にリアルタイムで確認できることです。ディスク I/O の場合と同様に、Procexp に切り替えると、より詳細な診断を実行することができ、ネットワーク処理も (各プロセスの [TCP/IP] タブで) 確認できます。
対象のコンピューターと接続できない場合
これらの方法は、なんらかの方法でシステムに接続できることを前提としていますが、接続できない場合はどうすればよいのでしょうか。問題となっているのが皆さんのご姉妹のシステムで、そのご姉妹が何千マイルも離れた場所に住んでいる場合はどうすればよいのでしょうか。実際のところ、皆さんが思っているよりも簡単です。まず、遠く離れた場所にいる相手に、Sysinternals ツールをダウンロードしてもらいます。Sysinternals ツールはどれも使いやすく、特に、今回ご紹介する使い方は簡単です。
ご姉妹がツールをダウンロードしたら、Autoruns を実行してもらいます。これにより、ご姉妹は、自動起動のリモート分析を行うことができるように、システム上で実行されているすべての実行可能ファイルのスナップショットを *.arn ファイル (Mark Russinovich がこのタスクを明確に対象として開発したファイル形式) の形で皆さんに提供することができるようになります。
ご姉妹に管理者としてログオンしてもらい、[File] メニューの [Save] をクリックして ARN ファイルを生成してもらいます。なぜ ARN ファイルを保存したのでしょうか。これが、プロセスを開始しているものを特定する最善の方法だからです。
ローカルで接続しているかリモートから接続しているかにかかわらず、具体的に何が各アプリケーションを起動しているか、およびコンピューター上で実行されているサービスや他の自動起動プログラム (知らないものが含まれる可能性があります) を確認することができます。Autoruns では、自動起動される項目が多数のカテゴリに分けられています。今回の課題にとって最も興味深いのは、おそらくログオン、サービス、およびドライバーの項目でしょう。
Autoruns の UI のデータ表示が完了したら、[Options] メニューの [Hide Microsoft and Windows Entries] をクリックします。F5 キーを押すと、マイクロソフト以外のエントリが表示されます。多くの場合、この方法は疑わしいサービスやアプリケーションをリモート システムから診断するのに適しています。
次に、ご姉妹に Procexp を実行してもらいます。これも管理者として実行し、[File] メニューの [Save As] をクリックして詳細なツリー ビューをテキスト ファイルとして保存します。
続いて、Procmon を一定時間 (システムで現象が発生している間) 実行してもらいます。現実的には、ここで診断のために調査する時間は 5 分未満でしょう。
最後に、ARN、プロセス ツリー、および Procmon ログ ファイルを送ってもらいます。Procmon ファイルは明らかに電子メールで送るにはサイズが大きすぎるので、Dropbox などの共有ファイル転送ツールを使用します。
ファイルを受け取ったら、ローカルのパフォーマンス低下を診断するのに使用したものと同じ情報のほとんどが手に入ります。Procmon のログ (最も多くの情報を提供するのはこのログで、できるだけ簡単な方法で情報がフィルター処理されます)、および Procexp のプロセス ツリーを使用すると、多くの場合、リモート シナリオでもローカルの場合と同じくらい簡単に問題の原因を特定することができます。
Windows で問題のあるアプリケーションを診断することは不可能ではありません。Sysinternals ツールと Windows 用デバッグ ツールを使用し、ある程度練習を積めば、すぐに Windows 内部の深いところにある問題を診断できるようになります。時間や労力を節約でき、場合によっては正気を保つことができるようになります。
.jpg)
Wes Miller は、テキサス州オースティンにある CoreTrace 社 (CoreTrace.com (英語)) の製品管理責任者です。以前は Winternals Software 社に勤務し、その後はマイクロソフトでプログラム マネージャーとして働いていました。連絡先は wm@getwired.com (英語のみ) です。