⚠ CrashDecoder

Kernel-Power 41 The system has rebooted without cleanly shutting down first

This is the entry Windows writes when it notices, on startup, that the previous session ended badly. It is one of the most searched Windows errors and one of the most consistently misread, because the useful information is not in the message text - it is in the event's XML data, and the field everyone quotes is routinely interpreted backwards.

Updated 2026-07-28Critical - logged at the next boot, not at the failureAlso written: kernel power 41, Event ID 41, kernel-power event 41, critical kernel-power 41

What you are looking at

In Event Viewer the matching entries look like this:

Log Name:      System
Source:        Microsoft-Windows-Kernel-Power
Event ID:      41
Level:         Critical

The system has rebooted without cleanly shutting down first. This error could be caused if the system stopped responding, crashed, or lost power unexpectedly.
Log Name:      System
Source:        EventLog
Event ID:      6008
Level:         Error

The previous system shutdown at 3:42:11 AM on 27/07/2026 was unexpected.

What the error actually means

Windows maintains a flag saying whether the current session was shut down cleanly. On every startup the kernel power manager checks it, and if the last session ended without that flag being set properly, it writes Event 41.

Two consequences follow immediately, and both matter.

The timestamp is the boot, not the crash. Event 41 is written during the kernel phase of the next startup, so its recorded time tells you when the machine came back, not when it died. Event 6008 carries the approximate time of death inside its message body instead.

The message text is nearly useless on its own. It lists three possibilities - stopped responding, crashed, or lost power - and tells you nothing about which. The information that distinguishes them lives in the event's XML data, which Event Viewer shows only if you click the Details tab.

One thing to stop worrying about

Forum posts routinely quote "Task Category: 63" as though it were diagnostic. It is a constant. Every schema version of this event carries task 63, on every machine, for every cause. It tells you nothing.

Reading the parameters

Open the event in Event Viewer and switch to the Details tab, then Friendly View or XML View. These are the fields that carry information. Note that Windows has extended this event repeatedly - Windows 11 emits a version with twenty-one fields, where Windows 7 had eight - so you may not see all of these.

ParameterWhat it holds
BugcheckCodeThe stop code, if one was recorded. The single most important field. Read the caveat below before drawing conclusions from a zero.
BugcheckParameter1-4The four parameters of that stop code, matching what the blue screen would have shown.
PowerButtonTimestampNon-zero means the power button was held down. The value is a Windows FILETIME and decodes to the exact moment of the press. Zero does not prove the button was not used - Microsoft notes the value sometimes cannot be written before the machine dies.
SleepInProgressWhether the failure happened during a sleep transition. Microsoft shows examples but has never published what the values mean; 0, 4 and 6 all appear in real logs. Treat a non-zero value as "died around a power transition" and no more than that.
LongPowerButtonPressDetectedAdded in a later schema version and not documented by Microsoft. The name is self-explanatory, and it would in principle be more reliable than PowerButtonTimestamp for the same question - but that is inference, not documentation.
WHEABootErrorCountWindows 11 only, and undocumented. It appears to count hardware errors recorded by firmware at boot, which would make a non-zero value a strong hardware signal. Worth noting if you see it; not worth relying on, because nothing published confirms the meaning.
OthersCheckpoint, CheckpointStatus, BootAppStatus, LidState, ConnectedStandbyInProgress and several more exist in the schema and are undocumented. Anyone presenting a value table for these is guessing.

What actually triggers it

Two decimal-versus-hex traps

BugcheckCode is rendered in decimal, while the four parameters beside it are rendered in hex. Microsoft documents this and it still catches people constantly.

So a BugcheckCode of 159 is not stop code 0x159 - it is 0x9F, DRIVER_POWER_STATE_FAILURE. Likewise 209 is 0xD1 and 340 is 0x154. Convert before you look anything up.

What actually causes it, once you know which case you are in:

CauseHow oftenDetail
A blue screen you did not seeCommonIf automatic restart is enabled - the default - the machine reboots too fast to read the stop code. Event 41 captured it. This is the easiest case and the most common one.
Power supply or power deliveryCommonA failing supply, one that is underpowered for the hardware, or one that cannot hold up under transient load. Microsoft lists this, though its actual wording is that a zero bugcheck code might indicate a power supply problem - considerably weaker than the certainty most write-ups project.
Mains interruption or a loose connectionCommonA brief power cut, a switched-off extension lead, a plug not fully seated. On a laptop with a healthy battery this is largely excluded, which is itself a useful piece of reasoning.
OverheatingOccasionalThermal shutdown kills the machine without any chance to write a stop code. Windows has dedicated thermal channels in the event log - if those are empty, overheating becomes less likely.
A hard hangOccasionalThe machine locks up completely and you hold the power button. Event 41 records the reset, and PowerButtonTimestamp usually shows it. The reset is not the fault; whatever caused the hang is.
Memory faults or overclockingOccasionalMicrosoft names both. An unstable overclock or bad memory can take the machine down hard enough that nothing gets written.
Security software filter driversOccasionalMicrosoft's own guidance on the companion Event 6008 names misbehaving mini-filter drivers - which in practice means anti-virus - alongside failing hardware and firmware.
A deliberate hard resetOccasionalReset button, forced power-off, or a virtualization host resetting a guest. Entirely benign, and Event 41 has no way to tell it apart from a fault except through PowerButtonTimestamp.

Narrowing it down

Everything depends on one field. Read it first.

Read BugcheckCode, and convert it

Open the event, Details tab, and find BugcheckCode. Convert the decimal value to hex and pad to eight digits - 159 becomes 0x0000009F.

What it tells you

Non-zero: you had a blue screen and this is its stop code. Look it up and stop treating this as a power mystery - the Event 41 is just the aftermath. Zero: read the next step before concluding anything.

If BugcheckCode is zero, do not conclude "power supply"

This is where most guidance goes wrong. A zero means no stop code was successfully recorded - which is not the same as no crash having happened. Microsoft is explicit: a bugcheck can occur and the system still be unable to write the code or produce a dump.

So check for the thing that breaks recording. Look for volmgr Event ID 46, "Crash dump initialization failed!":

Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='volmgr'; Id=46} -MaxEvents 5 |
  Select-Object TimeCreated, Message | Format-List

Then check whether C:\Windows\Minidump contains anything.

What it tells you

Event 46 present: crash dump recording is broken, usually a page file problem. The zero is an artefact and proves nothing about power. Fix the page file first, then wait for the next occurrence to get real data.

No Event 46 and no dumps ever written: now the machine genuinely died before it could bugcheck, and power loss, thermal shutdown or a hard hardware fault move to the front.

Check PowerButtonTimestamp

A non-zero value is a Windows FILETIME. Decode it:

[datetime]::FromFileTime(131728546170882432)
What it tells you

Non-zero means somebody held the power button, and the decoded time tells you when. That reframes the event entirely - the machine did not fall over on its own, it was switched off, probably because it had already hung. A zero is weaker evidence: Microsoft notes the value sometimes cannot be written in time.

Look for what else is around it

Event 41 rarely appears alone, and the combination is more informative than the event itself.

What it tells you

See the table below. The single most useful companion is WHEA-Logger activity: a genuine mains cut produces silence, not a burst of hardware errors. Errors clustered around the outage point at the machine, not the wall socket.

Check whether Event 1074 is absent

Event 1074 from User32 records a software-initiated shutdown or restart - an update, an application, a user clicking Restart.

What it tells you

Microsoft notes that an unexpected reboot usually has no Event 1074. Its absence confirms nothing asked the machine to restart. Its presence means something did, and the Event 41 may be a knock-on rather than a fault.

Fixes, cheapest first

There is no fix for Event 41 itself - it is a record, not a fault. What you fix depends entirely on what the triage above told you.

  1. If BugcheckCode is non-zero: go and fix that stop code

    Effort: Varies · Risk: None

    Convert the decimal value to hex, then work the relevant page on this site. The Event 41 needs no separate attention - it will stop appearing when the crashes do.

    While you are there, turn off automatic restart so you can actually read the next one: System Properties, Advanced, Startup and Recovery, clear Automatically restart.

  2. Repair crash dump recording

    Effort: 15 minutes · Risk: Low

    Worth doing whenever BugcheckCode is zero, because without it you are diagnosing blind - and it is the direct fix if volmgr Event 46 is present.

    1. System Properties, Advanced, Startup and Recovery.
    2. Set Write debugging information to Automatic memory dump.
    3. Confirm the page file is on the system drive and system-managed - a page file that is absent or too small is the usual reason dump initialisation fails.
    4. Reboot, and wait for the next occurrence to produce real evidence.

  3. Rule out power delivery

    Effort: Varies · Risk: Low

    Appropriate once recording is confirmed working and a zero code persists. Use separate PCIe cables per connector rather than daisy-chaining, reseat the 24-pin and CPU power connectors, and if you can borrow a known-good supply with headroom, run on it for a week.

    Microsoft explicitly suggests a UPS where mains quality is suspect - which also settles the question, since a UPS-backed machine that still dies is not dying from mains.

  4. Check thermals

    Effort: 1 hour · Risk: Low

    Log temperatures under sustained load with HWiNFO64. Clear dust from heatsinks and filters, confirm every fan spins, and check the case exhausts rather than only drawing in.

    A thermal shutdown gives Windows no opportunity to write anything, which fits the zero-code case exactly.

  5. Investigate the hang, not the reset

    Effort: Varies · Risk: None

    If PowerButtonTimestamp is non-zero, you already know the machine was switched off by hand. The question is why it needed to be. Look at what the log shows in the minutes before that timestamp - display driver timeouts, storage errors, WHEA entries - and treat the hang as the fault.

When it is the hardware, not Windows

Signals that the machine is at fault rather than the mains or a one-off:

The WHEA correlation is the strongest single indicator available here, and it is the one almost nobody checks. Windows records hardware-reported errors independently of anything the crash path manages to write, so those entries survive exactly the failures that destroy other evidence. If the log falls silent with nothing before it, that is genuinely ambiguous - it looks identical whether the mains failed or the machine hard-hung. Be honest with yourself about that rather than forcing a conclusion.

Frequently asked

Does Event 41 mean my power supply is failing?

Not on its own, and this is the most repeated mistake about this event. Microsoft's actual wording is that a zero bugcheck code might indicate a power supply problem - and it names a completely different explanation in the same breath, namely that dump recording was broken so no code could be written. Check for volmgr Event 46 and check whether dumps have ever been written before you buy a power supply.

Why does the event timestamp not match when my PC crashed?

Because Event 41 is written during the next startup, not at the failure. The time you see is when the machine came back. For the approximate time of death, read the time inside the Event 6008 message body - Windows maintains a periodic heartbeat and that timestamp is the last one recorded. It is granular to the heartbeat interval, so treat it as approximate rather than exact.

Does turning off Fast Startup fix Event 41?

Probably not, and the claim is worth pushing back on. It appears constantly in commercial troubleshooting content with no source behind it, and the proposed mechanism does not hold up - Event 41 comes from the dirty-shutdown flag, not from the hybrid boot path.

There is a genuine first-party signal for fast startup problems: Kernel-Boot Event ID 29, "Windows failed fast startup with error status". If fast startup is actually failing on your machine, that is where it says so. Look for that rather than disabling things on spec.

I get Event 41 after every normal restart. Is that expected?

No. A clean shutdown or restart does not log Event 41 - a healthy machine records Event 1074, then Kernel-General 13, then 6009, and no 41 at all. If 41 appears after ordinary restarts, something is preventing the clean-shutdown flag being set. Check whether shutdown is actually completing or whether the machine is being cut off partway through, and look at Kernel-Boot Event 20, which reports LastShutdownGood directly.

What is the difference between Event 41, 6008 and 1001?

They come from three independent mechanisms, which is why the combination tells you more than any one of them. 41 is the kernel power manager's boot-time check. 6008 is the event log service's own dirty-shutdown flag. 1001 is the error reporting service recording that a bugcheck happened and a dump was written. See the table above for how to read the combinations.

There is no Event 1001 but BugcheckCode is non-zero. What does that mean?

A stop code was recorded but no dump was saved or processed. The crash was real - you have its code, so treat it as a genuine blue screen and diagnose from there - but the dump you would want for driver identification is missing. Check the Startup and Recovery settings and the page file, then check for volmgr Event 46.