前回(「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ファイルから必要な情報を取り出すには、以下の表のプロパティのみを見れば良い。
この連載の記事
-
第459回
PC
WSL 2.4.4ではtar形式でのディストリビューションが配布でき、企業での利用が容易になってきた -
第458回
PC
Windows上でhostsファイルを活用する -
第457回
PC
IPv6アドレスは先頭を見ればどんな種類かわかる -
第456回
PC
あらためてIPv6基本のキ -
第455回
PC
Windowsで現在どのネットワークアダプタがインターネット接続に使われているかを調べる方法 -
第454回
PC
Windows 11 24H2では「デバイスの暗号化」の条件が変わり、より多くのPCでドライブが暗号化される -
第453回
PC
Windows 11 24H2の配布開始後もすぐにはやってこない Windows UpdateとSafeguard Holds -
第452回
PC
Windows 11 Ver.24H2が登場 Copilot+ PCとそうでないPCで実質Windowsが2つに分かれる -
第451回
PC
新しいWindowsサンドボックスではコマンドラインからの制御が可能に -
第450回
PC
ユニコードで文字数を数える方法 -
第449回
PC
WSLはプレビュー版でGUIでの設定が加わった! リリース2.3.xの新機能を見る - この連載の一覧へ