今回は、イベントログからWindows Updateによる再起動時間を計測するために必要な情報を集めることにして、イベントログシリーズの最後としたい。
シャットダウンと再起動に関しては、前回解説したように(「WindowsイベントログをPowerShellを用いて扱う」)、PowerShellのGet-WinEventで、カーネルからのメッセージを見ればよかった。しかし、これだけだと再起動の理由が不明だ。また、現在のWindows 10でもいきなり落ちてしまうことは年に数回ある。こうしたシャットダウンの原因を探さないと、Windows Updateによる再起動を区別できない。
そもそも、Windows Updateで再起動が要求されても、現在のWindows 10ではすぐに再起動が始まることはまれで、アクティブ時間を避ける、ユーザーに確認を取るといったことが行なわれたのちに開始される。このため、Windows Updateのタイミングとシャットダウンのタイミングが数日空いてしまうことも珍しくない。
User32のイベントログでシャットダウンの理由を調べる
まず、シャットダウンの理由だが、これは、User32がイベントログを残してくれる。Windows Serverを扱った人なら、手動によるシャットダウンに際して、Windowsが理由を尋ねるダイアログを出すことをご存じだろう。Windows 10にも同様の仕組みがあるが、いちいち確認はせず、User32が勝手に理由を推測してイベントログに記録する。
ただし調べてみると、User32のイベントログには、「シャットダウン開始」だけでなく「シャットダウンに失敗」というログもあることがわかった。とりあえず、以下のイベントを取り出せばよい。
ProviderName=User32
EventID=1074 #シャットダウンの理由と開始
EventID=1073 #シャットダウン失敗
具体的には、以下のコマンドでイベントを取り出せる。
Get-WinEvent -Path $mylog -FilterXPath "Event/System[ (EventID=1073 or EventID=1074) and Provider[@Name='User32']]"
なお、前回と同じく$mypathには、evtxイベントログファイルのパスを入れてある。
クラッシュの種類を判別する
ところがWindowsは、不具合によりいきなり落ちることもある。これは事前には、検出することはできないが、EventLogが再起動後に「予期せぬシャットダウン」というイベントログを残してくれる。これを見ることで、直前のシャットダウン(と再起動)がクラッシュによるものであることがわかる。そのためには、以下のイベントを取り出す。
ProviderName=EventLog
EventID=6008
このイベントを取り出すには、以下のコマンドを使う。
Get-WinEvent -Path $mylog -FilterXPath "Event/System[ EventID=6008 and Provider[@Name='EventLog']]"
Windows Updateのログから再起動しそうなアップデートを探す
WindowsUpdateは、アップデートのダウンロードやインストール開始などのイベントログを記録している。しかし、すべてのアップデートとMicrosoftストアからのソフトウェア更新が記録されるため、膨大な量になる。必要なイベントとしては、
ProviderName=Microsoft-Windows-WindowsUpdateClient
EventID=19:インストール成功
EventID=20:インストール失敗
EventID=43:インストール開始
EventID=44:ダウンロード開始
EventID=216:コミット成功(20H1以降)
EventID=218:コミット開始(同)
がある。アップデートの名称は、Propertiesの最初の要素(Properties.value[0])に入っている。とりあえず、イベントの取り出しは、
Get-WinEvent -Path $mylog -FilterXPath "Event/System[ (EventID=19 or EventID=43 or EventID=44) and Provider[@Name='Microsoft-Windows-WindowsUpdateClient']]"
とした。再起動に関係ありそうなアップデートには、「機能」アップデート、「累積」的なアップデート、Insider Preview、言語パックなどがある。
このうち、日本語版のWindowsでも、「累積的」として「Cumulative」が、「言語」として「Language」がアップデートパッケージ名に含まれることがある。また、英語版のWindowsでもログを集めることを考えると、「機能」は「Feature」の表記がありえる。これらをパッケージ名に含むイベントログを見付けるとき、XPathでフィルターを記述するのはちと面倒だ。そこでhere-Objectを使って、
Get-WinEvent -Path $mylog -FilterXPath "Event/System[ (EventID=19 or EventID=43 or EventID=44) and Provider[@Name='Microsoft-Windows-WindowsUpdateClient']]" -ErrorAction SilentlyContinue | Where-Object { $_.Properties.value[0] -match "機能|Insider|Feature|累積|Cumulative|Language" }
と記述することにした。
この連載の記事
-
第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 -
第441回
PC
WSL以前から40年以上続く、Windows(Microsoft)とUNIXとの関わり -
第440回
PC
そもそも「Copilot+ PC」とは何なのか? -
第439回
PC
今更more.comを使うのか!? Windowsでのページングを考える - この連載の一覧へ