Event ID 41 Kernel-Power After an Unexpected Restart and How to Find the Cause
Event ID 41 from Microsoft-Windows-Kernel-Power is a Critical event in the System log. The message reads "The system has rebooted without cleanly shutting down first. This error could be caused if the system stopped responding, crashed, or lost power unexpectedly." Windows logs it at the next startup after a shutdown that didn't finish cleanly.
What it means
Event 41 records that the last shutdown wasn't clean. It doesn't record why on its own. When Windows saved a Stop error before the restart, the event carries the bug check code. When someone held the power button to force the restart, it carries a nonzero PowerButtonTimestamp. When the power was cut or the machine hung hard, the values can all be zero, or the event can be missing.
How to find the cause
List the restart events in the System log from an elevated PowerShell prompt. Event 1074 means an application or a user started the shutdown or restart. Event 6008 means the previous shutdown was unexpected.
Get-WinEvent -FilterHashtable @{
LogName = 'System'
Id = 41, 1074, 6008
} -MaxEvents 20 | Select-Object TimeCreated, Id, Message
The 1074 message names the user account, so blur it before posting the output anywhere.
Read the event data of the newest event 41.
Get-WinEvent -FilterHashtable @{
LogName = 'System'
ProviderName = 'Microsoft-Windows-Kernel-Power'
Id = 41
} -MaxEvents 1 | ForEach-Object { $_.ToXml() }
Find BugcheckCode and PowerButtonTimestamp in the EventData section of the output. BugcheckCode is in decimal, and Microsoft's bug check reference lists codes in hexadecimal. A BugcheckCode of 159 converts to 0x0000009F, which is DRIVER_POWER_STATE_FAILURE.
When BugcheckCode is nonzero, open the dump from that crash. Small memory dumps are in %SystemRoot%\Minidump, and kernel and complete dumps are at %SystemRoot%\MEMORY.DMP. Install Debugging Tools for Windows from the Windows SDK, set the WinDbg symbol path to https://msdl.microsoft.com/download/symbols, open the dump, run !analyze -v, then read the module named in the STACK_TEXT section.
When BugcheckCode and PowerButtonTimestamp are both zero, check whether Windows could write a dump at all. Event 46 from volmgr reads "Crash dump initialization failed!" when the computer started without a configured dump file.
Get-WinEvent -FilterHashtable @{
LogName = 'System'
ProviderName = 'volmgr'
Id = 46
} -MaxEvents 5 | Select-Object TimeCreated, Message
Then read the System and Application logs for the half hour before the time in event 6008. Replace the two times with a window that ends at that time.
Get-WinEvent -FilterHashtable @{
LogName = 'System', 'Application'
StartTime = (Get-Date '2026-10-27 22:30')
EndTime = (Get-Date '2026-10-27 23:00')
} | Select-Object TimeCreated, ProviderName, Id, LevelDisplayName
Fixes
When the bug check analysis names a driver, update that driver from the hardware vendor or roll it back to the version it was before the restarts started. Also update the BIOS and firmware.
When PowerButtonTimestamp is nonzero, the restart was forced with the power button. Find what made Windows stop responding before that, and hold the power button only when the machine doesn't respond.
When the values are zero, check the hardware. Disable overclocking, run a memory test and confirm every memory module runs at the same speed, confirm the power supply has enough wattage for the installed devices, and check component temperatures. Put the machine on a UPS when the restarts follow power cuts.
When event 46 from volmgr is present, fix the pagefile configuration so the next crash writes a dump. The default dump file is the pagefile.
On a physical server, check for Automatic Server Recovery (ASR) software, which restarts a machine it detects as unresponsive. On a Hyper-V virtual machine outside a cluster, the heartbeat feature restarts the VM when the host stops receiving its heartbeat. On VMware, check the VMware heartbeat feature and any third-party cluster software.
Related events and errors
- Event 6008, logged at startup when the previous shutdown was unexpected.
- Event 1074, logged when an application or a user starts a shutdown or restart.
- Event 6006, a clean shutdown.
- Event 46 from volmgr, "Crash dump initialization failed!".
- Bug check 0x9F, DRIVER_POWER_STATE_FAILURE, the code in Microsoft's event 41 example.
Where ET Ducky shows it
I build ET Ducky, and its agent reads the kernel event stream on each Windows and Linux endpoint. ET Ducky has custom behavior detection by reading kernel logs and can be configured to look for things like this. Every alert gets an automatic root-cause analysis with the cause, impact, mitigation, prevention, and a confidence level. You can also open a Live Session shell from the browser without the need for a VPN and run the Get-WinEvent queries above on the machine that restarted.
Sources
- Microsoft Learn, Event ID 41 The system has rebooted without cleanly shutting down first, read 2026-10-28.
- Microsoft Learn, Advanced troubleshooting for stop code errors, read 2026-10-28.
- Microsoft Learn, Bug check code reference, read 2026-10-28.
- Microsoft Learn, Get-WinEvent, read 2026-10-28.
- Microsoft Learn, EventRecord.ToXml, read 2026-10-28.
Alerts with a root-cause analysis attached
Read how ET Ducky alert rules are built and how each alert gets an AI root-cause analysis with recommendations.
Read the alerts docs