Auditing sleep resume with 40 event-log entries and 60 WER records - a failed boot-time check

I retrieved 40 Kernel-Power 507 events and 60 records from Windows Error Reporting, but the boot-time Event ID 100 query failed immediately with rc=1.

The main subject this time is not the numbers I obtained but the log I could not obtain. I initially planned to collect boot time from Microsoft-Windows-Diagnostics-Performance/Operational by looking for Event ID 100. Instead, boot_perf took 2.1 seconds and returned rc=1, while shutdown_perf took 0.57 seconds and also returned rc=1. Both stdout and stderr were empty. The lack of even an error message was the hardest part to handle. From the script's perspective, it looked like "there was nothing."

I assumed that Windows boot time would be in Diagnostics-Performance, so this empty result was unexpected. In my environment it may be disabled by default, or it may not be visible in this Windows 11 Pro 10.0.26200 build. The original goal of measuring boot time was lost on the first command.

Sleep resume and WER data did work. Between 2026-07-13 05:43:44 and 2026-07-14 06:49:21, there were 40 Kernel-Power 507 events. The log span was 25 hours 05 minutes 37 seconds, which gives a simple average of one resume event every 38.6 minutes. The distribution was not uniform, however. Sixteen events were clustered in the 05:00 hour and another 16 in the 06:00 hour on July 13, and Input Mouse accounted for 31. Rather than closing the laptop and leaving it alone, the log suggests that it was entering sleep and returning because of mouse input. That pattern also somewhat matches my experience.

What Get-WinEvent returned

I used only Get-WinEvent -FilterHashtable. First I filtered by log name and event ID, then exported only the required fields to JSON. I intended to inspect Application IDs 1000 and 1001 and System Kernel-Power IDs 42, 107, and 507. Looking back, the most careless part was not checking the log names existed first.

Get-WinEvent -FilterHashtable @{
    LogName      = 'System'
    ProviderName = 'Microsoft-Windows-Kernel-Power'
    Id           = 42, 107, 507
} -MaxEvents 80 | Select-Object TimeCreated, Id, Message

WER uses the Application log. Event ID 1001 often has Event Name: at the beginning of its message. For ID 1000, I wanted the faulting module line, so I did a small amount of message processing.

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)
    }
}

To turn EventData back into a dictionary, I went through ToXml(). This is close to the form I actually tried. Event logs use different field names for different providers, so converting them to named dictionaries before serializing to JSON makes later reading easier.

$xml = [xml]$_.ToXml()
$eventData = @{}
foreach ($d in $xml.Event.EventData.Data) {
    $eventData[$d.Name] = $d.'#text'
}

Empty queries and successful retrievals

When I counted the JSON as returned, the split between failure and success was clear. That split is the record of this attempt.

sleep_events contained only ID 507. The 42 and 107 events I intended to capture were not in this JSON. Deferring log enablement checks was the failure. By reason, there were 31 Input Mouse., 6 16777220., 2 Input Keyboard., and 1 Power Button. entry. For exits from Modern Standby, the reasons look strongly related to human input.

There were 60 wer_crashes entries. The strings in the App field were Event Name: LiveKernelEvent 32 times, Event Name: BlueScreen 19 times, Event Name: AppTermFailureEvent 7 times, Event Name: APPCRASH once, and Faulting module name: coreclr.dll, version: 10.0.626.17701, time stamp: 0x69c4edcd once. Few can be read as ordinary app names. Application ID 1001 is returning WER event types rather than telling us which executable crashed. I had started to treat the WER App field as an app name, which was wrong.

How to read uptime

uptime contained 2026-07-14T06:51:56. Subtracting it from the measurement time, 2026-07-14 20:56:47, gives 14 hours 04 minutes 51 seconds of continuous uptime. This is what I could retrieve through another path in place of Event ID 100: the time of the last boot.

That value alone cannot describe boot speed. It tells us only how long the system has been running without crashing. It does not tell us how many seconds boot took, where shutdown stalled, or how long driver initialization used. Those details were unavailable once Diagnostics-Performance returned an empty result. I should have stopped earlier when I saw empty stderr.

Even so, combining the resume data with uptime reveals something about usage. There were four resumes in the 00:00 hour, two in the 03:00 hour, and two in the 06:00 hour on July 14. That differs from the 32-event concentration the previous morning; the next day, the machine resumed every few hours. I could follow the pattern of leaving the laptop overnight and waking it with the keyboard in the morning.

What the failure taught me

The mistake was treating event logs as if they were guaranteed to exist. I built on the loose assumption that writing a log name and calling Get-WinEvent would return something. In practice, rc=1 produced zero entries, with neither stdout nor stderr. The command alone cannot distinguish a missing log from a disabled log or a permissions problem. If I had checked Diagnostics-Performance first, I would have found the failure point sooner.

The other trap was the WER App field. Event Name: LiveKernelEvent and Event Name: BlueScreen are not application names. Event Name: APPCRASH also does not identify the crashed executable by itself. The one ID 1000 entry exposed coreclr.dll as a faulting module, but that is a module name, not the application itself. The safe choice is not to inflate this into an app-name claim.

I marked the verdict as conditional. The data is sufficient for a rough view of sleep-resume counts and WER categories. The 40 Kernel-Power 507 events and 60 WER events show everyday behavior on this Surface Pro 11th Edition in a fairly mechanical way.

As a boot-time audit, however, this does not work as-is. The first step should have been Get-WinEvent -ListLog * to verify the log exists and to check whether Microsoft-Windows-Diagnostics-Performance/Operational is enabled. For the next audit, I will add log-existence checks, explicit handling for rc=1, and handling for empty stdout before trusting event logs as measurement data. The silent empty result remained troubling long after the run.