Kernel-Power 41 in Windows 11: Diagnose an Unexpected Restart

Your Windows 11 PC suddenly restarts while gaming, rendering a video or sitting idle. You open Event Viewer and find a critical Kernel-Power, Event ID 41 entry. It is tempting to blame a faulty power supply immediately, but that entry does not identify the failed component.

Event 41 means Windows detected that the previous shutdown was not completed cleanly. It is recorded when Windows starts again. Power loss, a system hang that forced you to hold the power button, and a Windows Stop error can all produce it. Microsoft's Event ID 41 troubleshooting guidance explicitly treats the entry as a starting clue, not a root-cause verdict.

This guide is for Windows 11 home-PC users and desktop troubleshooters who can sign in after an unexpected restart. You will learn to distinguish a recorded crash from a power interruption, interpret the event's most useful fields, and choose a proportionate next check. The commands are read-only. They are based on Microsoft documentation and have not been executed on an affected Windows PC for this article.

What Event 41 can—and cannot—tell you

The entry's source is Microsoft-Windows-Kernel-Power, its log is System, and its event ID is 41. The message says the machine restarted without first shutting down cleanly. That is the condition Windows observed, regardless of which device, driver or external event triggered it.

The order matters. Imagine that your monitor goes black at 8:14 pm and the computer starts again at 8:15 pm. A Kernel-Power 41 entry around 8:15 pm is usually Windows reporting the preceding unclean shutdown on the following boot, not proof that something called Kernel-Power failed at 8:15 pm. Look for other events and the actual symptom around the original failure.

A critical level indicates that the operating system considers the event significant. It does not automatically make the event's text a diagnosis. In particular, Event 41 does not, by itself, prove that the PSU is faulty, the GPU is overheating or Windows Update caused the reboot. Microsoft lists power interruption and Stop errors among possible causes.

Read the nearby events as a timeline, not a list of red icons

Event IDs are only meaningful together with their source, date and message. Microsoft's unexpected-reboot event-log reference describes these related records. That reference is written for Windows Server, but it documents the same common Windows event sources; the Windows-client Event 41 article governs the diagnosis here.

For example, a relevant 1001 bug-check report beside Event 41 points toward Stop-error investigation. An 1074 entry may explain an orderly software-requested restart instead. A 6008 entry confirms unexpected shutdown history, but repeating 41 and 6008 does not add two independent explanations of the cause.

First, record what you actually saw

Before touching drivers, firmware or power settings, write down what happened in ordinary terms. Was there a visible Stop-code screen? Did the PC immediately lose power and turn on again? Did audio freeze while the screen stayed lit? Did you hold the power button after the keyboard stopped responding? Did the problem begin after a specific hardware, driver or BIOS change?

Also note the approximate local time, whether the machine was under load or idle, and whether the same problem has happened more than once. Do not intentionally reproduce a suspected power fault by repeatedly stressing an unstable computer, especially if you notice unusual heat, an electrical smell or physical damage. Back up important files before further troubleshooting when the machine is stable enough.

These observations matter because a sudden loss of power can leave Windows unable to write diagnostic data. A missing Stop-code report or a zero bug-check field is not a clean bill of health.

Find the exact Event 41 entry in Event Viewer

1. Press Windows + R, type eventvwr.msc, then press Enter.
2. Expand Windows Logs and select System.
3. In the right-hand Actions pane, choose Filter Current Log. Enter the event IDs 41,6008,1001,1074,46 to make the sequence easier to inspect.
4. Find the time near the unexpected restart. Open the 41 event and confirm the source is Microsoft-Windows-Kernel-Power.
5. Open the event's Details tab, then XML View. Copy the BugcheckCode, PowerButtonTimestamp and relevant parameter values into a private troubleshooting note. Inspect the surrounding event sources rather than relying on ID numbers alone.

The precise presentation of Event Viewer can vary between Windows builds and log configurations. If the filter finds nothing, return to the unfiltered System log and check the date range and time zone; missing entries can reflect log retention, incomplete recording or a different failure, not necessarily a healthy system.

Optional: collect the same recent events with PowerShell

If you prefer a sortable history, run the following in PowerShell on the affected Windows PC. This query asks Windows for the last seven days of matching System events and does not change the log. It uses Microsoft's documented Get-WinEvent FilterHashtable interface.

$start = (Get-Date).AddDays(-7)
Get-WinEvent -FilterHashtable @{
    LogName   = 'System'
    Id        = 41, 46, 1001, 1074, 6008
    StartTime = $start
} |
    Sort-Object TimeCreated |
    Select-Object TimeCreated, Id, ProviderName, Message |
    Format-List

This intentionally captures several event IDs. Read the ProviderName and Message before treating a hit as crash evidence. If PowerShell reports that no matching events were found, do not manufacture a diagnosis. You may need to inspect a wider date range or check whether the log was overwritten. Some log queries can also require an elevated PowerShell session, depending on access permissions.

For the most recent Kernel-Power 41 record only, you can inspect the named XML fields without relying on the display language of the formatted message:

$event = Get-WinEvent -FilterHashtable @{
    LogName      = 'System'
    ProviderName = 'Microsoft-Windows-Kernel-Power'
    Id           = 41
} -MaxEvents 1

[xml]$xml = $event.ToXml()
$xml.Event.EventData.Data |
    ForEach-Object {
        [pscustomobject]@{
            Field = $_.Name
            Value = $_.InnerText
        }
    }

This is an illustrative inspection command, not evidence that the current PC produced those fields. If there is no matching event, $event will not contain a valid record and the XML part cannot run; stop at the first error. Log messages can include computer names, user names and paths, so remove unrelated personal information before sharing output in public forums.

The three useful Event 41 branches

The Microsoft Windows-client procedure separates Event 41 into three scenarios. Follow the evidence you have, rather than choosing the most expensive repair.

1. BugcheckCode is non-zero: investigate the Stop error

A non-zero BugcheckCode means Windows captured a Stop-error code. In Event 41, Microsoft documents that field as decimal, whereas bug-check references usually display hexadecimal. Converting it correctly avoids chasing an unrelated error.

For example, Microsoft's own sample uses decimal 159, which is hexadecimal 0x0000009F. You can perform the conversion in PowerShell:

$decimalCode = 159  # illustrative value from Microsoft's sample
'0x{0:X8}' -f $decimalCode

The expected formatted value for this example is 0x0000009F. Microsoft's bug-check 0x9F reference identifies that code as DRIVER_POWER_STATE_FAILURE, involving a driver and a power-state transition. That is a useful direction for investigation, not proof of exactly which driver or device is responsible.

Record the complete code, any other parameters, and the corresponding Event 1001 bug-check report when present. If Windows saved a memory dump, keep it for authorised support analysis. Do not randomly uninstall drivers or disable security software to make the critical entry disappear.

2. PowerButtonTimestamp is non-zero: account for a forced power-off

Microsoft documents a non-zero PowerButtonTimestamp in its scenario involving a held power button. If you did hold the button after the PC froze, the recorded unclean shutdown may reflect that necessary intervention.

The important question remains why the machine froze first. A power-button record does not prove the button caused the original hang. Compare the time and your observation before deciding what to investigate.

3. Both values are zero: do not declare the PSU guilty

If BugcheckCode and PowerButtonTimestamp are zero, Windows may have lost power or become unresponsive too abruptly to save a code. Microsoft explicitly includes failed or unavailable dump initialisation as another possibility. Look for volmgr Event 46 and check dump/page-file configuration only if the relevant record and symptoms justify it.

Possible branches include an external power interruption, an unstable or underpowered PSU, overheating, memory instability, a hard hang or a failure that could not be recorded. A zero code cannot distinguish these on its own. It also does not justify disabling every power-saving feature or replacing the PSU immediately.

Worked example: the same Event 41, two different next actions

Suppose an illustrative home PC reboots while waking from sleep. You find Kernel-Power 41 and a matching bug-check report. Event 41 shows BugcheckCode = 159. Converting that decimal value to 0x0000009F points you toward a driver power-state failure. You would preserve the bug-check details, check any recent device-driver changes and work from the documented 0x9F branch. It would be premature to conclude that the PSU is faulty.

Now consider a different illustrative PC that goes completely dark during a game. After reboot, the Event 41 fields are both zero and there is no relevant bug-check record. That does not establish a PSU failure either. It makes a power-path and hardware-stability check more appropriate: note whether the machine loses power outright, inspect external connections safely, review temperatures if the system can run normally, and check whether the problem began with a hardware or firmware change. You still need evidence before selecting a replacement part.

Neither example is a benchmark or a claimed reproduction on Jitsumi hardware. The different next actions follow from the documented event fields and the symptoms supplied in the scenarios.

What to check next without making recovery harder

When a Stop error or device change is implicated, use the exact stop code and the model of the affected device. Microsoft's Windows 11 unexpected-restart guidance recommends considering newly added hardware, Safe Mode when necessary and device-driver checks. If a specific driver changed immediately before the issue, record its version and consult the manufacturer before attempting a targeted rollback. Multiple unrelated driver changes make it harder to know what helped.

When the machine suddenly powers off, start outside the case: check that the AC adapter or desktop power cable is firmly seated, whether other devices lost power, and whether an external UPS reported an interruption. Observe fan behaviour and temperatures using trusted system or manufacturer tools when the PC is stable. Do not open a PSU enclosure; internal capacitors can retain dangerous charge even when disconnected. A suspected electrical fault or physical damage is a reason to stop using the device and arrange competent service.

When memory instability is plausible, especially after enabling XMP/EXPO or adding RAM, record the exact change and check vendor-supported default settings. A memory test can add evidence, but a passing test does not rule out every intermittent fault. Jitsumi's published guide to running Windows Memory Diagnostic and interpreting its result is a useful follow-up if you need that specific check.

Do not treat sfc /scannow, a registry cleaner, a blanket driver updater or a Windows reinstall as the automatic cure for Event 41. Those tools address other questions. Their use is justified only if the other evidence points toward a fault they can actually investigate.

Check whether the fix really helped

Change one plausible factor at a time, then observe the PC through ordinary work rather than repeatedly provoking an unsafe fault. Record the change date, whether the same unexpected restart returns, and whether a new matching bug-check or event appears. A week without a restart may be reassuring, but it does not prove which change resolved an intermittent fault.

If the machine continues to restart, gather the event timestamps, exact bug-check code if present, hardware model, recent driver/BIOS changes, and the circumstances of each failure. Give those details to the PC manufacturer, a trusted technician or your organisation's IT team. They are much more actionable than a screenshot of the words Critical — Kernel-Power 41.

The practical rule is simple: Event 41 tells you that Windows did not shut down cleanly; the surrounding evidence determines what you should inspect next.