イベントログ40件とWER60件でスリープ復帰を追った失敗
この記事の見出し
Kernel-Power の 507 が40件、Windows Error Reporting 側が60件取れたが、起動時間のイベント ID 100 は rc=1 で最初から失敗した。
今回の主役は取れた数値ではなく、取れなかったログのほうにある。最初は Microsoft-Windows-Diagnostics-Performance/Operational から起動時間を拾うつもりで、イベント ID 100 を探した。ところが boot_perf は2.1秒で rc=1、shutdown_perf も0.57秒で rc=1。stdout も stderr も空だった（エラー文すら返らないのが、いちばん扱いに困る）。スクリプト側から見ると「何もなかった」としか扱えない。
Windows の起動時間なら Diagnostics-Performance にあると思い込んでいたので、この空振りは予想と違った。私の環境では既定で無効なのか、Windows 11 Pro 10.0.26200 のこのビルドには見えていないらしい。起動時間を測るという当初の目的は、最初のコマンドで潰れてしまった。ここで詰まることになる。
一方で、スリープ復帰と WER は取れた。2026年7月13日05:43:44 から2026年7月14日06:49:21 までに、Kernel-Power の 507 が40件ある（Diagnostics-Performance 側を先に疑っていなかった）。ログの範囲は25時間05分37秒で、単純平均なら38.6分に1回の復帰イベントになる（復帰理由の偏りを見てから読み方が変わった）。ただし分布は均一ではない。2026年7月13日05時台と06時台にそれぞれ16件ずつ固まっており、Input Mouse が31件を占める。ノート PC を閉じて放置したというより、スリープに入りかけてはマウス入力で戻る、という使われ方がログに出ている（この挙動は、体感とも少し合う）。
Get-WinEvent で拾ったもの
使ったのは Get-WinEvent -FilterHashtable だけ。まずログ名とイベント ID で絞り、必要なフィールドだけ JSON に落とす（次はログ一覧から見直してみるつもりだ）。Application ログは ID 1000 と 1001、System ログは Kernel-Power の 42、107、507 を見るつもりだった。なぜ先にログ名の存在確認をしなかったのか、今見るとそこがいちばん雑なところ。
Get-WinEvent -FilterHashtable @{
LogName = 'System'
ProviderName = 'Microsoft-Windows-Kernel-Power'
Id = 42, 107, 507
} -MaxEvents 80 | Select-Object TimeCreated, Id, Message
WER 側は Application ログから拾った。イベント ID 1001 は本文の先頭に Event Name: が入ることが多い。ID 1000 は faulting module の行を見たかったので、メッセージを少しだけ加工している。
Get-WinEvent -FilterHashtable @{
LogName = 'Application'
Id = 1000, 1001
} -MaxEvents 80 | ForEach-Object {
[pscustomobject]@{
TimeCreated = $_.TimeCreated
Id = $_.Id
App = ($_.Message -split "`r?`n" | Where-Object { $_ -match 'Event Name:|Faulting module name:' } | Select-Object -First 1)
}
}
EventData を辞書に戻すときは、ToXml() を経由した。これは実際に試した形に近い。イベントログは Provider ごとにフィールド名がばらばらなので、名前つきの辞書にしてから JSON 化したほうが後で読みやすいはず（WER の App 列をアプリ名として読みかけていた）。
$xml = [xml]$_.ToXml()
$eventData = @{}
foreach ($d in $xml.Event.EventData.Data) {
$eventData[$d.Name] = $d.'#text'
}
空振りと取得成功の内訳
取れた JSON をそのまま集計すると、失敗と成功がかなりはっきり分かれる（この分かれ方が今回の記録そのもの）。
| 取得名 | rc | 件数 | 読み取れた内容 |
|---|---|---|---|
| boot_perf | 1 | 0件 | stdout なし、stderr なし |
| shutdown_perf | 1 | 0件 | stdout なし、stderr なし |
| uptime | 0 | 1件 | 2026-07-14T06:51:56 |
| sleep_events | 0 | 40件 | すべて ID 507 |
| wer_crashes | 0 | 60件 | ID 1001 が59件、ID 1000 が1件 |
sleep_events は ID 507 だけだった。狙っていた 42 と107 は、この JSON には入っていない（ログの有効化状態を後回しにしたのが失敗だった）。理由別に見ると、Input Mouse. が31件、16777220. が6件、Input Keyboard. が2件、Power Button. が1件。Modern Standby から抜けた理由としては、かなり人間の操作に寄っているように見える。
wer_crashes は60件ある。App 列に入っていた文字列は、Event Name: LiveKernelEvent が32件、Event Name: BlueScreen が19件、Event Name: AppTermFailureEvent が7件、Event Name: APPCRASH が1件、Faulting module name: coreclr.dll, version: 10.0.626.17701, time stamp: 0x69c4edcd が1件だった。アプリ名として普通に読めるものは少なく、Application ログの 1001 は「どの exe が落ちたか」よりも WER のイベント種別を返している、という話。
稼働時間の読み方
uptime には 2026-07-14T06:51:56 が入っていた。計測時点の2026年7月14日20:56:47 から引くと、連続稼働は14時間04分51秒になる（空の stderr を見た時点で止まるべきだった）。ここはイベント ID 100 が取れなかった代わりに、最後の起動日時だけを別経路で拾えた形だ（rc=1 の扱いを甘く見ていた）。
この数値だけで起動の速さは語れない。分かるのは「いつから落ちずに動いているか」までで、起動処理に何秒かかったか、シャットダウンでどこに詰まったか、ドライバー初期化に何秒使ったかは別の話になる（復帰理由の偏りを見てから読み方が変わった）。そういう内訳は Diagnostics-Performance が空振りした時点で取れていない（WER の App 列をアプリ名として読みかけていた）。
それでも、スリープ復帰のログと合わせると使い方は見えてきた。2026年7月14日00時台に4件、03時台に2件、06時台に2件の復帰が並ぶ。前日の朝に32件も集中しているのとは違い、翌日は数時間おきに戻る動きだった。ノート PC を一晩置いて、朝にキーボードで起こした流れまでは追えた。
失敗から分かったこと
今回の勘違いは、イベントログを「あるもの」として扱った点だ。ログ名を書いて Get-WinEvent を投げれば返るはず、という雑な前提で組んだ。実際には rc=1 で0件になり、stdout も stderr も空（rc=1 の扱いを甘く見ていた）。存在しないのか、無効なのか、権限なのかは、そのコマンドだけでは切り分けにくい（Diagnostics-Performance 側を先に疑っていなかった）。
もう1つの落とし穴は、WER の App 列だった。Event Name: LiveKernelEvent や Event Name: BlueScreen はアプリ名ではない。Event Name: APPCRASH も、単体では落ちた実行ファイル名まで届かない。ID 1000 の1件だけは coreclr.dll という faulting module が見えたが、これもアプリ本体ではなくモジュール名だ。記事にするときは、ここをアプリ名として盛らないほうが安全になる。
個人的には、条件つきで使える、という結論にした。スリープ復帰の回数や WER の種類をざっくり見るには十分だろう。40件の Kernel-Power 507 と60件の WER は、Surface Pro 11th Edition の日常的な挙動をかなり機械的に見せてくれる。
ただし、起動時間の監査としてはこのままでは動かない（なぜ空振りが無音だったのか、後で引っかかった）。最初にやるべきだったのは Get-WinEvent -ListLog * でログの存在を確認し、Microsoft-Windows-Diagnostics-Performance/Operational が有効かどうかを見ることだった。次に同じ監査を作るなら、ログ名の存在確認、rc=1 の扱い、空 stdout の扱いを先に入れる（ログの有効化状態を後回しにしたのが失敗だった）。そこまで入れて初めて、イベントログを測定データとして信じられる。