前回(「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ファイルから必要な情報を取り出すには、以下の表のプロパティのみを見れば良い。
この連載の記事
-
第452回
PC
Windows 11 Ver.24H2が登場 Copilot+ PCとそうでないPCで実質Windowsが2つに分かれる -
第451回
PC
新しいWindowsサンドボックスではコマンドラインからの制御が可能に -
第450回
PC
ユニコードで文字数を数える方法 -
第449回
PC
WSLはプレビュー版でGUIでの設定が加わった! リリース2.3.xの新機能を見る -
第448回
PC
PowerShellで面倒なオブジェクトはPSCustomObjectに変換するのが早道 -
第447回
PC
この秋登場のWindows 11の新バージョン、Ver.24H2の状況を見る -
第446回
PC
Windows 11のフォトアプリがUWPからWin32アプリになったことで今更わかるUWPの問題点 -
第445回
PC
次期Windows 11ではAndroidのファイルをエクスプローラーからアクセス可能になる -
第444回
PC
外部ファイルをExcelに読み込む際の作業を効率化するPower Queryの活用 -
第443回
PC
Windows Terminalで採用されたCascadia Codeフォントを使うとプログラムを書くとき断然見やすい -
第442回
PC
Copilot+ PCで実現されるローカル推論で「対クラウド企業」を指向するMicrosoft - この連載の一覧へ