【Windows Server入門 第7回】トラブルシューティングとイベントビューア。grepできないログをどう読むか

[PR]

  💡 サーバー構築やコマンドの練習には、VPSが圧倒的におすすめです。  

手元のパソコンや大切なメイン環境で検証を行うと、設定ミスでシステムを壊してしまったり、不要なパッケージが溜まって動作が不安定になるリスクがあります。

もしあなたが実務レベルのスキルを最短で身につけたいのであれば、月額ワンコインから使えて、失敗しても数分で初期状態にリセットできるVPS（仮想専用サーバー）を利用するのが、プロも実践する最も確実で安全な学習方法です。 「本記事は、10秒でサーバーが起動できる [ConoHa VPS]（PR） の環境を使用して検証しています。」

▼ プロも推奨するVPS環境はこちら ▼

「ログファイルが見当たらない！」grepできない恐怖に打ち勝て。

こんにちは！「LINUX工房」管理人の「リナックス先生」です。
前回は、WSUSを使ったWindows Updateの制御について解説しました。
これで「勝手に再起動される」というトラブルは防げるようになりました。

しかし、システム運用に障害は付きものです。
Linuxエンジニアなら、何かあったらまず tail -f /var/log/messages や grep error /var/log/nginx/error.log を叩きますよね？
テキスト形式のログは、私たちの共通言語であり、最強の武器です。

ところが、Windows Serverでログを探そうとエクスプローラーを開いても、/var/log に相当するフォルダは見当たりません。
あるのは「イベントビューア」という、重くて検索しにくいGUIツールだけ……。
「これじゃ調査できないよ！」と叫びたくなったことはありませんか？

先生、もう限界です……。
昨日ファイルサーバーが急に遅くなったんですけど、ログを見ようと思ってイベントビューアを開いたら、ログが数万件あって、スクロールしてるだけで日が暮れました。
しかも「エラー」でフィルタしようとしたら「応答なし」で固まるし。
Linuxなら grep 一発なのに、Windowsの管理者はどうやって障害対応してるんですか？ マゾなんですか？

コウ君、気持ちは分かるわ。
Windowsのログはバイナリ形式（.evtx）だから、テキストエディタで開いても文字化けするだけなの。
でもね、構造化されているということは、SQLのように「クエリ」で検索できるということよ。
正しいやり方さえ知っていれば、grepよりも遥かに正確に原因を特定できるの。
ウィンドウズ先生、プロのログ解析術を教えてあげて！

はい、ウィンドウズ先生です。
イベントビューアが重いのは、あなたが「全件取得してから表示」させているからです。
プロはGUIのフィルタ機能など使いません。
XMLクエリやPowerShellを使って、必要な情報だけをピンポイントで抽出します。
今回は、イベントログの高速検索テクニックと、パフォーマンスモニターによる負荷解析、さらにはブルースクリーン（BSOD）のダンプ解析まで、Windowsトラブルシューティングの奥義を伝授します。

本記事では、イベントログの構造と効率的なフィルタリング、PowerShellを使ったCUIでのログ調査、サーバー負荷の原因を特定するパフォーマンスモニターの使い方、そしてOSクラッシュ時の解析手法までを徹底解説します。

第1章：イベントログの構造。「ID」こそが全て

Linuxのログは自由なテキストですが、Windowsのイベントログは厳格なデータベース構造を持っています。
まずは敵（ログ）を知りましょう。

主要な3つのログ

C:\Windows\System32\winevt\Logs\ 配下に .evtx 形式で保存されています。

1. System (System.evtx): OSカーネル、ドライバ、サービスに関するログ。再起動、ディスクエラー、ネットワーク切断などはここに記録されます。（Linuxの /var/log/messages や dmesg に相当）
2. Application (Application.evtx): アプリケーション（SQL Server, IIS, ウイルス対策ソフトなど）が出力するログ。
3. Security (Security.evtx): ログイン成功/失敗、ファイルアクセス監査などのセキュリティログ。（Linuxの /var/log/secure や audit.log に相当）

イベントID (Event ID) を信じろ

Windowsログ解析のキモは「イベントID」です。
メッセージ本文は言語によって変わりますが、IDは世界共通です。
エラーメッセージでググるのではなく、「Event ID XXXX Source YYYY」でググるのが正解です。

覚えておくべき主要なID（Systemログ）:

• 1074: 正常なシャットダウン/再起動（誰が実施したかも記録される）
• 6008: 予期せぬシャットダウン（電源断やBSOD後の起動時に記録される）
• 6005 / 6006: Event Logサービスの開始/停止（OSの起動/停止時刻の目安になる）
• 41 (Kernel-Power): 「システムは正常にシャットダウンする前に再起動しました」。BSODや電源断の証拠。

第2章：イベントビューア高速化。「カスタムビュー」と「XMLフィルタ」

イベントビューアを開いて、右側の「現在のログをフィルター」をクリックし、GUIでポチポチ設定していませんか？
ログが数GBあると、その操作だけで数分待たされます。
プロは「XML」でクエリを書きます。

XMLフィルタの書き方

「現在のログをフィルター」→「XML」タブ → 「手動でクエリを編集する」にチェックを入れます。

例：過去24時間以内の「エラー(Level=2)」かつ「ソースがDisk」のログを抽出

<QueryList>
  <Query Id="0" Path="System">
    <Select Path="System">
      *[System[(Level=2) and Provider[@Name='disk'] and TimeCreated[timediff(@SystemTime) <= 86400000]]]
    </Select>
  </Query>
</QueryList>

GUIが裏で生成しているクエリを直接書くことで、無駄な読み込みをスキップし、爆速で結果を表示できます。
よく使うクエリは「カスタムビュー」として保存しておけば、次回からはワンクリックで呼び出せます。

第3章：PowerShellでgrepする。Get-WinEventの極意

GUIが重いなら、CUI（PowerShell）を使えばいいじゃない。
Linuxエンジニアなら、こちらの方が肌に合うはずです。

❌ 遅いコマンド：Get-EventLog

ネットで検索するとよく出てくる Get-EventLog は、古いコマンドレットです。
全件取得してからパイプでフィルタするため、ログが巨大だと死ぬほど遅いです。

# やってはいけない（遅い）
Get-EventLog -LogName System | Where-Object { $_.EntryType -eq "Error" }

⭕ 速いコマンド：Get-WinEvent -FilterHashTable

新しい Get-WinEvent を使い、「FilterHashTable」オプションで検索条件を渡します。
これなら、OS側の検索エンジンを使って抽出した結果だけを持ってくるので爆速です。

# 推奨（速い）
# 過去24時間(86400000ミリ秒)以内の、Systemログの、エラー(2)を取得
$filter = @{
    LogName = 'System'
    Level   = 2
    StartTime = (Get-Date).AddDays(-1)
}
Get-WinEvent -FilterHashTable $filter

grepのように文字列検索する

メッセージの中に特定の文字列（例：”disk”）が含まれるログを探したい場合。

# 先にIDやレベルで絞り込んでから、最後にテキスト検索するのがコツ
Get-WinEvent -FilterHashTable @{LogName='System'; Level=2} | Select-String -Pattern "disk"

Get-WinEvent -ComputerName Server01 -LogName System -MaxEvents 50

第4章：パフォーマンスモニター。「重い」の犯人を特定する

「サーバーが重い」と言われた時、Linuxなら top や vmstat を見ます。
Windowsではタスクマネージャーを見がちですが、詳細な解析には「パフォーマンスモニター（PerfMon）」を使います。

見るべきカウンター（Counter）

PerfMonには数千種類のカウンターがありますが、最初に見るべきは以下の4つです。

1. Processor / % Processor Time: CPU使用率。常に80%を超えているならCPUボトルネック。
2. Memory / Available MBytes: 空きメモリ量。ここが枯渇するとページングが発生し、激重になります。
3. PhysicalDisk / Avg. Disk Queue Length: ディスクの待ち行列。ここが「2」を超え続けているなら、I/Oボトルネック（ディスクが遅い）です。
4. Network Interface / Bytes Total/sec: ネットワーク転送量。帯域を使い切っていないか確認。

データコレクターセットの活用

「夜中の3時だけ重い」といった場合、ずっと画面を見ているわけにはいきません。
「データコレクターセット」を作成し、スケジュール実行でログ（.blgファイル）を採取します。
後からそのファイルを開けば、当時のグラフを再生できます。
（Linuxの sar コマンドに近い運用です）

第5章：ブルースクリーン（BSOD）の解析。死因を探る

Windowsサーバーが突然再起動し、イベントログに「ID 41 (Kernel-Power)」だけが残っている。
これは十中八九、ブルースクリーン（Blue Screen of Death）によるクラッシュです。
「何が原因で死んだか」は、現場に残された遺留品「メモリダンプ（Memory Dump）」を解析するしかありません。

事前準備：ダンプ設定

デフォルトでは「自動メモリダンプ」になっていますが、確実に記録するために設定を確認します。
「システムのプロパティ」→「詳細設定」→「起動と回復」
「カーネルメモリダンプ」を選択し、保存先（通常 %SystemRoot%\MEMORY.DMP）を確認します。

解析ツール：WinDbg Preview

ダンプファイルを解析するには、Microsoft Storeから「WinDbg Preview」をインストールします（無料）。

1. WinDbgを起動し、「File」→「Open Dump File」で MEMORY.DMP を読み込む。
2. シンボル（デバッグ情報）の読み込みが走るので待つ。
3. コマンド入力欄で !analyze -v と入力してEnter。

これだけで、AIのように自動解析が走り、「MODULE_NAME: mydriver.sys」のように、クラッシュの原因となったドライバやモジュールを特定してくれます。
「原因不明のハードウェア障害」として片付ける前に、一度ダンプを見てみましょう。

第6章：実践トラブルシューティング事例

最後に、現場でよく遭遇するトラブルと、その解決フローを紹介します。

事例1：アカウントが頻繁にロックされる

• 現象: 特定のユーザーが「パスワード間違い過ぎ」でADアカウントロックされる。本人は「まだ何も入力してないのに！」と言う。
• 調査: ドメインコントローラーのSecurityログを見る。
  • イベントID 4740 (A user account was locked out) を検索。
  • ログの中にある「Caller Computer Name（呼び出し元コンピュータ名）」を確認。
• 原因: ユーザーが以前使っていたスマホや、別PCに残っていた「古いパスワードを記憶した資格情報」が、バックグラウンドで認証試行を繰り返していた。

事例2：謎の勝手な再起動

• 現象: 朝起きたらサーバーが再起動していた。
• 調査: Systemログを見る。
  • イベントID 1074 を検索。「コメント」欄を見る。
  • 「レガシ API のシステム シャットダウン」云々とあれば、誰かがコマンドで再起動したか、アプリによる要求。
  • もし 1074 がなく、いきなり 6008 (予期せぬシャットダウン) があれば、電源断かBSOD。
  • BSODなら、C:\Windows\MEMORY.DMP の更新日時を確認。

事例3：IISが応答不能（503 Service Unavailable）

• 現象: Webサイトが見れない。503エラー。
• 調査:
  • Systemログで WAS (Windows Process Activation Service) のエラーを探す。
  • 「アプリケーションプール ‘AppPoolName’ は予期せず終了しました」が記録されている場合、アプリがクラッシュしている。
  • Applicationログを見て、.NET Runtimeのエラー (ID 1026) などを探す。

まとめ：ログは嘘をつかない。ツールを使いこなせ。

お疲れ様でした！
第7回は、Windows Serverのトラブルシューティングについて解説しました。

今回の重要ポイント：

• Windowsのログはバイナリ。grepではなくXMLフィルタかPowerShellで攻める。
• イベントID（1074, 6008, 4740など）をキーワードに調査する。
• 「重い」原因はタスクマネージャではなく、パフォーマンスモニターで特定する。
• BSODは「WinDbg」で !analyze -v を叩けば犯人が分かる。

コウ君、これで「エラーが出たから再起動して様子見」という素人運用から卒業できましたね。
Windowsはブラックボックスだと思われがちですが、実はLinux以上に詳細なログを吐き出しています。
正しいツールの使い方さえ知っていれば、原因特定は決して難しくありません。

さて、OSの管理、セキュリティ、トラブルシューティングと学んできました。
本講座もいよいよ次回で最終回です。
最後は、サーバー仮想化技術「Hyper-V」と、注目の「Windowsコンテナ」についてです。
DockerはLinuxだけのものじゃない。Windows上でWindowsアプリをコンテナ化する、最新のトレンドを学びましょう。

次回、第8回（最終回）は「Hyper-Vとコンテナ。WindowsコンテナとDockerの共存戦略」です。
仮想マシンの巣窟（入れ子）や、Docker for Windowsの裏側など、インフラエンジニアの好奇心を刺激する技術満載でお届けします。お楽しみに！