このページの本文へ

前へ 1 2 次へ

Windows Info 第202回

Windowsで発生したことを確認できるWindowsイベントログを解説する

2019年12月15日 10時00分更新

文● 塩田紳二 編集● ASCII

  • この記事をはてなブックマークに追加
  • 本文印刷

イベントログの保存期間の設定をあらかじめしておく

 Windowsが記録する対象は多く、イベントログは複数のカテゴリに分かれてEVTXファイル化されているものの、無制限に記録し続けるとストレージを大きく専有してしまう。このため、標準ではEVTXファイルが一定サイズ以下になるように古いものから消されていく。ただし、設定で過去のイベントログを残すことも可能である。

 設定は、イベントビューアーから可能。イベントビューアーを起動し、左側のツリーから保存期間を変更したいログ(紙のノートのようなアイコン)を右クリックしてプロパティを開く。

イベントログの記録方法を変更するには、イベントビューアーのツリー領域で対象項目を右クリックしてプロパティを開く

 表示されたダイアログボックスの「全般」タブに「最大ログサイズ」と「イベントログサイズが最大値に達したとき」という項目がある。

「全般」タブに「最大ログサイズ」「イベントログが最大値に達したとき」の2つの設定項目があるので必要に応じて変更する

 前者を大きくすると、ファイルに記録できる期間を延ばせるがその分、ファイルも大きくなってしまう。デフォルトでは20MBが指定されている。

 「イベントログサイズが最大値に達したとき」は、デフォルトで「必要に応じてイベントを上書きする」になっているので、これを「イベントを上書きしないでログをアーカイブする」に変更しておく。

 すると、EVTXファイルが最大値に到達すると、新規にファイルが作られ、古いログは日付などを付けたファイル名に変更されて保存される(保存先はイベントログと同じ)。システムログなどは、20MBだと、数ヵ月程度しか記録できないので、必要に応じてバックアップ方法を選択する。

 なお、Windowsの機能アップデートが実施されると、アップデート以前のWindowsフォルダーは、Windows.oldフォルダーに変更されて保存される。このとき、イベントログファイルがすべて新規のファイルに置き換わる点には注意されたい。逆に言えば、機能アップデートの直前までのイベントログは、Windows.oldフォルダー側に残っていて、機能アップデートの再起動後のイベントログがWindowsフォルダー以下に残る。

イベントログを扱う方法は5種類

 イベントログを扱う方法にはいくつかある。それぞれに一長一短あり、使い分ける必要がある。方法としては

1. イベントビューアー(GUI)
2. wevtutil.exe(コマンドライン)
3. WMIC.EXE(コマンドライン)
4. PowerShellコマンドレット
5. Win32APIや.NET Frameworkによるソフトウェア開発

がある。

 筆者は、機能アップデートに関する情報を収集するためにこれらを検討してみた。以下の評価は、そのときの評価をベースにしているため、必ずしもすべての使い方に対しての評価ではないことをお断りしておく。

 「イベントビューアー」は、GUIアプリケーション(実際には管理コンソールのeventvwr.msc)で一番簡単な方法である。項目を指定しての並べ替えと、条件を指定してのフィルター機能があり、ログを確認するという用途ではこれでだいたい行える。ただ、指定できるフィルター条件が単純なものだけなので、複数のソースからの情報を関連させて見るといった用途には向かない。

 たとえば、Windowsの機能アップデートに関連するログは、WindowsUpdate(ダウンロードやインストールの開始、成功など)、User32(再起動の原因)、Kernel-General(再起動、起動の記録)をまとめてみる必要があるが、こうした条件はイベントビューアーでは指定できないため、個別にフィルターして保存し、あとでまとめて見る必要がある。また、元のデータを解釈して表示させている関係で、イベントビューアーでは、リストには表示されず、詳細表示させないと見ることができない情報がある。

 「wevtutil.exe」は、コマンドラインからイベントログファイルを扱うためのもの。完全なコマンドラインのツールであるため、スクリプトなどから利用しやすい。また、前述のログファイルが最大値に達したときの設定などもこのコマンドでできる。このため、多くのイベントログの設定を変更するような場合やスクリプトなどから制御する場合に利用可能だ。ただし、出力は、テキストかXMLのどちらかである。

 「WMIC.EXE」も同様にコマンドラインツールだが、こちらは、WMI(Windows Management Instrumentation)経由でのアクセスで、他のシステム情報などと同一のコマンドで扱うことができるため、すでにWMIに慣れた人向けだ。WMI自体、ちゃんとWindows 10にも残っているが、推奨される方法ではなく、WMICコマンドは機能が膨大でいまからその使い方を覚えるメリットはあまりないかもしれない。ただし、Wevtutil.exeに比べると検索条件や出力指定が柔軟だ。

 PowerShellには、イベントログを扱うためのコマンドレットが複数ある。PowerShellは、.NET FrameworkのイベントログAPIを利用しており、比較的簡単にイベントログを扱える。ただ、ちょっと使った人ならばわかるが、言語としては非常に癖が強く、PowerShell自体に慣れないと、利用に苦労することがある。もっとも、他人が紹介しているコマンドをコピー&ペーストで試す程度であれば、一番簡単な方法と思われる。

 最後の「ソフトウェア開発」は究極のログ管理だが、よほど複雑な条件でも指定しない限り、ここまで必要になることはないと思われる。ただ、Win32APIや.NET Frameworkが自由に呼び出せる言語に堪能なら、PowerShellでスクリプトを組むよりは理解しやすいだろう。

 ただ、イベントログ関係では、ユーザーに理解できる形式に変換するためには、APIで得られる情報だけでなく、XMLを解釈したり、コードをメッセージなどに変換する必要があり、言語システムにイベントログのクラスライブラリなどが提供されているのであればいいが、これを自力で実装するのはかなり難しい。

 そういうわけで、とりあえず、PowerShellイベントログを処理することにした。全部をPowerShellで処理するのも面倒なので、必要な情報を入れたファイルを出力し、これをExcelで処理できるようにした。

 たとえば、日付によるソートなどはExcel側で処理するようにする。というわけで、次回は、PowerShellによるイベントログの処理について解説したいが、そろそろWindowsTerminalの機能確定版が出そうな感じであり、掲載が遅れた場合はご容赦いただきたい。

前へ 1 2 次へ

カテゴリートップへ

この連載の記事

注目ニュース

ASCII倶楽部

プレミアムPC試用レポート

ピックアップ

ASCII.jp RSS2.0 配信中

ASCII.jpメール デジタルMac/iPodマガジン