イベントログ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件ある。ログの範囲は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 化したほうが後で読みやすい。

$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 のイベント種別を返している、という話だ。WER の App 列をアプリ名として読みかけていたのだが、それは間違いだった。

稼働時間の読み方

uptime には 2026-07-14T06:51:56 が入っていた。計測時点の2026年7月14日20:56:47 から引くと、連続稼働は14時間04分51秒になる。ここはイベント ID 100 が取れなかった代わりに、最後の起動日時だけを別経路で拾えた形だ。

この数値だけで起動の速さは語れない。分かるのは「いつから落ちずに動いているか」までで、起動処理に何秒かかったか、シャットダウンでどこに詰まったか、ドライバー初期化に何秒使ったかは別の話になる。そういう内訳は Diagnostics-Performance が空振りした時点で取れていない。空の stderr を見た時点で、もう少し早く立ち止まるべきだったと後から思った。

それでも、スリープ復帰のログと合わせると使い方は見えてきた。2026年7月14日00時台に4件、03時台に2件、06時台に2件の復帰が並ぶ。前日の朝に32件も集中しているのとは違い、翌日は数時間おきに戻る動きだった。ノート PC を一晩置いて、朝にキーボードで起こした流れまでは追えた。

失敗から分かったこと

今回の勘違いは、イベントログを「あるもの」として扱った点だ。ログ名を書いて Get-WinEvent を投げれば返るはず、という雑な前提で組んだ。実際には rc=1 で0件になり、stdout も stderr も空。存在しないのか、無効なのか、権限なのかは、そのコマンドだけでは切り分けにくい。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 の扱いを先に入れる。そこまで入れて初めて、イベントログを測定データとして信じられる。なぜ空振りが無音だったのか、後でずっと引っかかった。