Windowsにはイベントログと呼ばれる機能がある。これは、システムやアプリケーションなどが、発生したイベントを記録し、後でのメンテナンスなどに利用するものだ。管理ツールにあるイベントビューアーでも簡単には見ることができる。今回は、このあたりを解説する。

目的としては、Windows内で発生した複数のプログラムが関わる特定の作業の経過などを取り出し、その経過を追えるようにする。筆者は、Windowsの機能アップデートに関しての情報を収集したいと思って調べ始めた。

そもそもWindowsのイベントログとは

Windowsのイベントログは、現在では、EVTX形式のファイルに記録され、

C:\Windows\System32\winevt\Logs

というフォルダー以下に置かれている。イベントログ機能自体はWindows NTの頃からあり、当初はEVT形式でログを記録していた。その後Windows Vistaで形式が拡張されEVTX形式となった。

なお、Windowsにはもう1つ、イベントトレースログ（Event Trace Log。ETL）と呼ばれるものがある。イベントログがどちらかというと、作業をした後での記録であるのに対して、ETLは起動中のプログラムの経過を記録する場合に使われることが多く情報量も多い。

しかし一般的には、ログインしたとか、インストールしたとかのイベントの記録だけで十分なことが多く、イベントログを使った管理が行われるのが普通。これに対してETLは、たとえば、デバイスドライバーの挙動やWindows Updateのアップデート作業の経過などを記録するために使われている。このため、データ量が多く、日常的な記録には向いていない。なお、ETLは、

C:\Windows\Logs

以下に保存されていることが多い（これ以外の場所で見つかることもある）。

EVTX／ETLともにファイル形式自体は未公開だが、その変換や表示を可能にする手段が複数提供されており、これらを使うことで、Windowsの管理ができるが、それぞれ一長一短ある。

イベントビューアーを起動するとわかるが、Windowsのイベントログは多数ある。しかし、記録形式としてはEVTXのみなので、基本的にどのログも情報の形式としては同じである。ただ、後述するが、イベントビューアーで見える項目は、従来のEVT形式だったときのものと同じで、実際に記録されている情報とはちょっと違う。

イベントビューアーは、EVTX形式のファイルを解釈して人間が見やすい表示に変換している。たとえば、イベントビューアーでログをどれか開き、その中のレコードを選択すると、下の「全般」タブにメッセージが表示されているが、ログ自体には、こうしたテキスト情報は含まれていない。

これは、ログに記録された情報をイベントビューアーが解釈し、数値で表現されたログ内容をテキスト表現しているだけである。具体的な記録内容は不明だが、イベントビューアーの下のペインで「詳細」タブを開き、「XMLで表示」を選ぶと、記録されている情報に近いものが表示される。

ここに表示される情報は、おそらくEVTX形式の中に記録されているものに近いと考えられる。これを見ると、たとえば上のログのリストで「ソース」として表示されているのはXMLデータの中の“Provider Name”の一部を切り出したものだし、「日付と時刻」は、“TimeCreated”をローカル時間（XMLではGMTが指定されている）に変換したものである（このあたりあは次回、PowerShellでログを扱うときに別途詳しく解説する）。

また、ソースやイベントの種類により、後半の“<EventData>”の部分は異なっており、レコードは固定長ではなく、さまざまなデータを保持できるようになっているようだ。

ただし、EVTXは、XMLで表現できるが、ファイルの中を見ると、XML形式ではなくバイナリ形式になっている。おそらくは、ファイルスペースを節約するために圧縮などがなされているのだと思われる。とはいえマイクロソフト標準の16bit文字コードもあるようなので、XMLのタグをバイナリ表現したような形式ではないかと思われる。

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

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

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

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

前者を大きくすると、ファイルに記録できる期間を延ばせるがその分、ファイルも大きくなってしまう。デフォルトでは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の機能確定版が出そうな感じであり、掲載が遅れた場合はご容赦いただきたい。