Skip to main content
評価してください: 

私のところに寄せられる事例の中で最も興味深いのは、ユニークなトラブルシューティング技法を使った事例や興味深い根本原因を明らかにする事例です。今回ご紹介するのは最近寄せられた事例で、この両方の特徴を備えています。問題が発覚したのは、システム管理者が、コンピューターで印刷を行うことができないという報告をユーザーから受けたときです。印刷ダイアログやメニュー項目をクリックしても、目に見える反応はありませんでした。通常は、この操作を行うと、ドキュメントがプリンターに送信されたという内容のダイアログと、アクティブな印刷キューを表すトレイ アイコンが表示されていました。

管理者は、まず、この問題を報告してきたユーザーのコンピューターのイベント ログを調べて、印刷関連のイベントを探しました。そしてすぐに、このユーザーが最後に試みた印刷に関連する次の 2 つのイベントを見つけました。

図 1

図 1

図 2

図 2

ユーザーが印刷しようとしたときにスプーラー サービスが開始されましたが、約 1 分後にどうやら例外によって (予期せず) 終了したようです。一体なぜでしょうか。

管理者は、 Sysinternals の ProcDump (英語) を使用することにしました。ProcDump は、指定したトリガーが発生した場合にプロセスのクラッシュ ダンプ ファイルを生成するユーティリティです。実装されているトリガーは、CPU 使用率、仮想メモリ使用量、ハンドルされない例外、プロセスの終了などです。たとえば、CPU 使用率というトリガーを使用して、プロセスが短期間の CPU バーストに達したときのプロセスの状態をキャプチャすることができ、スパイクの理由を確認するためにプロセスを調査することができます。管理者は、終了するスレッドのスタック トレースが手掛かりとなるのではないかと推測しました。

スプーラー サービスが開始してから ProcDump を実行する時間があることがわかっていたので、管理者はメモ帳を起動し、印刷を試みてから、ダンプ ファイルへの書き込みを行う前にスプーラー サービスが終了するまで ProcDump が待機するように、–e オプションとスプーラー サービス プロセスの名前 (Spoolsv) を指定して ProcDump を実行しました。数秒後に、ProcDump による処理が完了しダンプ ファイルが保存されたことを示すメッセージが表示されました (下図参照)。

図 3

図 3

管理者はダンプ ファイルを Windbg で開き、"k" コマンドを実行しました。Windbg でこのコマンドを実行すると、クラッシュの原因となったスレッドのスタックがダンプされます。このスタック トレース (基本的に、クラッシュ前に実行された関数呼び出しの記録を示します) から、いくつかの Ldr 関数 (LdrpLoadDll など) を含む一連の呼び出しでプロセスが終了していることがわかりました (下図参照)。

図 4

図 4

Web を検索したところ、 LdrpLoadDll (英語) はシステムの DLL ローダーに関連する関数であることがわかりました。プロセスが終了したのは、探していた DLL を見つけることができなかったから、または不適切な DLL を読み込んでいたからではないかと考えた管理者は、 Process Monitor を使用することにしました。このツールを使用すると、プロセスの、DLL 関連のファイル システム アクティビティを確認することができます。管理者は Process Monitor を起動し、再び印刷を試みてから、キャプチャを中止しました。そして、根本原因の手掛かりを求めて、トレースの最後から最初に向かって順に見ていきました。管理者は、Spoolsvc が終了する少し前に、Spoolsvc がシステムのさまざまなディレクトリで Localspl.dll を検索していることに気付きました (下図参照)。

図 5

図 5

管理者は、この DLL は本来そこになければならないのだろうと考えました。ネットワーク上にある、まったく同じ構成の別の Windows XP システムを確認したところ、\Windows\System32 ディレクトリに Localspl.dll がありました (下図参照)。

図 6

図 6

ファイルの説明で、この DLL はローカル スプーラー DLL であることが示されていました。これで、スプーラーが印刷操作をサポートできない理由がわかりました。正常に機能するシステムからこのファイルをコピーすると、正常に印刷できるようになりました。

ユーザーに関しては、問題は解決され、ユーザーは仕事に戻ることができました。しかし、管理者には、元の DLL はどうなったのかという疑問が残されていました。再び Web を検索したところ、同じ問題に遭遇した他のユーザーによる、フォーラムの投稿が見つかりました。特に、ある投稿では、イベント ログ エントリを含め、今回のケースとまったく同じ現象について述べられており、別のシステムから Localspl.dll をコピーするという同じ解決策が提案されていました。この投稿によると、Localspl.dll が誤って削除されてしまうのは、サード パーティ製の印刷や FAX のソフトウェアのアンインストーラーが原因とのことでした (下図参照)。

図 7

図 7

エンド ユーザーは印刷や FAX のソフトウェアをアンインストールしたかどうか覚えていなかったので、管理者は、これが今回問題となったシステムにも当てはまると断言することはできませんでした。ですが、この投稿によって、少なくとも、説得力のある仮説が提供され、管理者は、ファイルがシステムから削除されたが原因がわからないという困惑から解放されました。こうして、管理者は、ProcDump と Process Monitor を活用することで、この件に決着を付けることができました。

Sysinternals のツールを使用して興味深い問題を解決した方は、私がこのブログやプレゼンテーションで他の方々にご紹介できるように、ぜひスクリーンショット (できれば .PNG 形式) とログ ファイルをお送りください。

公開: 2010 年 4 月 12 日月曜日 6:18 PM 投稿者: markrussinovich (英語)

トップへ戻る

共有


ブログにコピー: ([Ctrl] + [C] でコピーしてください)

Mark's ブログ: 一覧

Mark Russinovichマーク・ルシノビッチ (Mark Russinovich)

マーク・ルシノビッチ氏は、マイクロソフトの Windows Azure チームのテクニカル フェローで、『 Windows Internals』、『 Windows Sysinternals Administrator’s Reference』、およびサイバー サスペンスの『 Zero Day: A Novel』の著者でもあります。連絡先は、 markruss@microsoft.com (英語のみ) です。

Mark's ブログ 日本語版は、 Mark's blog (英語) を翻訳したものです。