前回(「Windowsで発生したことを確認できるWindowsイベントログを解説する」)、Windows Terminalの機能確定版が出た場合はそちらを紹介予定と記したが、12月17日にWindows Terminalの1912版が出るかと思いきや、17日になって12月31日に延期された。クリスマス休暇に入っちゃったのかと思ったが、いまだに開発は進行しているようである。まあ開発には計画変更が付きものなので、ゆっくりと待つことにしよう。今年はまだ1週間以上残されている。
さて、今回は前回の続きで、Windowsのイベントログを扱う。PowerShellを使って、実際に記録されているログから必要なものを取り出す方法を解説する。筆者としては、Widnows Updateで再起動が行われたときのオフライン(Windowsが起動していない状態)でのインストール作業の時間を測定したいと考えている。このため、いくつかのログを取り出し、その経過をログ上で再現してシャットダウンから起動するまでの時間を測定したい。
PowerShellでイベントログを処理する
前回も解説したように、イベントログを扱うにはいくつかの方法があるのだが、一番細かく制御できるのがPowerShellだ。さすがにマイクロソフトがシステム管理用に作っただけのことはある。
しかし、PowerShellにはイベントログを扱うコマンドが2つあり、同じイベントログを対象としているのにも関わらず、対象の扱い方やプロパティ名などに違いがある。こういうのはやめてほしいと思うのだが、片方はイベントビュアーに似たやり方やプロパティ名でイベントログを扱う。イベントログはWindowsでずっと使われてきたツールで、過去には現在とは違うログ形式を扱っていたため、プロパティ名などは過去のままになっている。おそらくevt形式からevtx形式への移行時に、見た目が変わらないようにしたのだと思われる。
実際のPowerShellコマンドとしては「Get-EventLog」と「Get-WinEvent」の2つがある。前者がイベントビュアーに似た方式で、後者がevtx形式に則したコマンドである。またGet-EventLogは、イベントビューアーで見ることができる現時点のログファイルのみを扱い、バックアップされたログファイルを扱わない。その分、コマンドのオプションで、ログ内のレコードの絞り込みや抽出が簡単にできる。
それに対して、Get-WinEventは、直接evtxファイルを開いて中身を扱うことができる。このため、現在のログファイルもバックアップされたログファイルも扱える(ただし、そのために管理者権限が必要)。ログ内のレコードの絞り込みなども不可能ではないが、-Pathオプションを使ってevtxファイルから読み込む場合には、XPathを使う「-FilterXPath」オプションを使わねばならない。
こっちは、ちょっとオプション指定が面倒だが、ログを全部出力させて、あとからWhere-Objectを使ってレコードを抽出するのに比べるとかなり速い、ざっと見たところ数~10倍程度の差が出る。ただし、柔軟な文字列比較などは、文字列比較はできないようなので、Where-Objectを適時併用するといいだろう。
evtx形式のログの構造
Get-WinEvent/Get-EventLogコマンドやイベントビューアーでイベントログを扱うとおぼろげながら、イベントログオブジェクトの構造が見えてくる。まず、すべてのイベントは、ログの登録元となるProviderName(イベントビューアーのソースに相当)とIdプロパティ(イベントビュアーではEventId)で区別されているようだ。つまり、ProviderNameごとにIdで何が起こったのかを区別できる。
イベントビューアーを見ると、さまざまな情報がテキストで表示されているが、これらの多くは、イベントレコード内の情報を元に、メッセージファイルなどからテキストを取り出して表示させているようだ。このため、Get-EventLog/Get-WinEventでは、ログの概略を示す「message」プロパティの中身が情報が見つからないというエラーメッセージになっていることがある。また、関数の中などで使うとエラーが発生することがある。
messageプロパティは、オブジェクトのように見えるが、実際にはevtxの中には記録されておらず、Idをキーにしてどこかにあるメッセージデータベースから入手したテキストとEventDataプロパティに含まれている情報を組みあわせて合成される文字列である。人間には、わかりやすいものの、たとえば、Windows 10のバージョンが違うと、メッセージデータベースが違うため、messageプロパティを作ることができなくなる。
また、イベントログは、記録された時刻を表す「TimeCreated」プロパティ(イベントビューアーの日付と時刻に相当)と別に記録された順番を示すRecordIdを持っている。時刻はミリ秒単位まで記録されているものの、複数の「ソース」が同時にログを記録しようとしているため、時間がずれる可能性がある。
このとき、RecordIdは、evtxファイルへの記録順を示すため、ソートするときに利用が可能だ。ただし、RecordIdはevtxファイルごとになるため、複数のevtxファイルを通して見る場合には注意が必要だ。
Windowsの機能アップデートやInsider Previewのインストールでは、旧バージョンのWindowsフォルダーは、C:\Windows.oldフォルダー以下に置かれるが、再起動前のログは、こっちにある。このため、2つのevtxファイルを合わせないとシャットダウンと起動のタイミングを調べることができない。このときRecordIdはそれぞれのevtxファイルで割り振られるため、つなげるときに注意が必要だ。
結局、evtxファイルから必要な情報を取り出すには、以下の表のプロパティのみを見れば良い。

この連載の記事
- 第258回 LinuxのGUIアプリケーションに対応するWSL2
- 第257回 Windows 10の最新ビルドを用い、WSL2で仮想マシン環境を使う
- 第256回 ARM版Windows 10のプレビュー版でx64プログラムの動作に対応したので試した
- 第255回 Windowsのディスプレイとモニター いまだ96DPIが基準
- 第254回 Preview版でv1.5まで進化したWindows Terminalの新機能を確認
- 第253回 Windows 10でJSONを扱う
- 第252回 ソフトウェア開発者以外にも便利なツールが含まれるWindows SDK/WDKをインストールする
- 第251回 WindowsサーチのIndexerで使われるIFilterを調べる
- 第250回 キーボードのキー入れ替えにおける、仮想キーコードとキーボードスキャンコード
- 第249回 Windows 10で秋の大型アップデートが始まったのに、春のアップデートも落ちてこないマシンがあるのはなぜ?
- 第248回 Windows 10にはコンテナーがいっぱい
- この連載の一覧へ