There is no single reboot event ID. A normal Windows restart writes six events across two logs, in a fixed order, and each one answers a different question.
The one worth going to first is 1074, because it names the process that started the shutdown, the account it ran as, the reason and whether it was planned.
The one everybody finds first is 41, because it appears in red after a machine has died, and Microsoft says in its own troubleshooting article that by itself it might not contain enough information to explain what happened. If the shutdown was not clean, 6008 is the event that tells you when the machine actually stopped, which is not the same as when the event was written.
- A clean restart writes six events, and 1074 is the only one that names who started it
- 41 means the machine did not shut down cleanly, and on its own says very little
- 6008 carries the time the machine died, which 41 does not
- The BugcheckCode inside 41 is decimal, and every bug check reference is hexadecimal
- All zeros inside 41 usually points at power, not at software
On this page
The sequenceThe six events of a clean reboot, in order
People look for a reboot event ID, or a Windows restart event ID, as if the System log kept one. It keeps a sequence.
This is a real sequence from a Windows 11 machine, in the order the events were written. Nothing here is reconstructed; it is what the System log contains after an ordinary update restart.
| Time | Event ID | Source | What it says |
|---|---|---|---|
| 02:29:19 | 1074 | User32 | MoUsoCoreWorker.exe has initiated the restart, and why |
| 02:32:51 | 6006 | EventLog | The Event log service was stopped |
| 02:32:52 | 13 | Kernel-General | The operating system is shutting down at system time |
| 02:33:13 | 12 | Kernel-General | The operating system started at system time |
| 02:34:20 | 6009 | EventLog | The Windows version banner, written at boot |
| 02:34:20 | 6005 | EventLog | The Event log service was started |
Read the gaps rather than the entries. The restart was requested at 02:29:19 and the operating system did not begin shutting down until 02:32:52, so more than three minutes passed while Windows closed applications and stopped services. The machine was actually down from 02:32:52 to 02:33:13, twenty-one seconds, and the Event log service did not come back until 02:34:20.
If somebody asks how long the reboot took, all three of those answers are defensible and the largest is fourteen times the smallest. Say which one you are quoting.
Event 1074Event ID 1074, the one that names who did it
When the question is who rebooted the server, event ID 1074 is the answer. It is the shutdown event ID people are usually looking for and rarely find.
The reason is that searching for a reboot event turns up 41 first. Event 1074 comes from User32, and it is the only one that records intent.
Here is a real 1074 in full:
> The process C:\WINDOWS\servicing\TrustedInstaller.exe (DESKTOP-S0RNV51) has initiated the restart of computer DESKTOP-S0RNV51 on behalf of user NT AUTHORITY\SYSTEM for the following reason: Operating System: Upgrade (Planned) > Reason Code: 0x80020003 > Shutdown Type: restart > Comment:
Five things in one entry: the binary that asked, the account it ran as, a decoded reason, a reason code, and whether it was a restart or a shutdown.
The computer name appears twice, which matters when logs from many servers are collected in one place. The Comment field is what somebody typed if they used a tool that prompts for one.
The initiating process is the part that answers the question. Three real examples from the same machine, all of them routine and all meaning something different:
| Process in the 1074 | What actually happened |
|---|---|
| C:\WINDOWS\servicing\TrustedInstaller.exe | Windows servicing finished an update and restarted |
| C:\WINDOWS\uus\AMD64\MoUsoCoreWorker.exe | The Windows Update orchestrator restarted the machine |
| StartMenuExperienceHost | A person clicked Restart in the Start menu |
On a server, that column is where you find the monitoring agent, the application that called for a restart, the patching tool, or the account of whoever was logged in at the time. It is the difference between an outage somebody caused and an outage nobody did.
1074 is not written when the machine crashes. Nothing had the chance to announce an intention, so an unexpected shutdown leaves no 1074 at all. Its absence is itself evidence.
The dirty pairEvent 41 and Event 6008, the unexpected pair
When a computer does not shut down cleanly, there is no single unexpected shutdown event. Two events appear on the next boot and they always come in the same order, a few minutes apart.
41, from Kernel-Power, verbatim: *The system has rebooted without cleanly shutting down first. This error could be caused if the system stopped responding, crashed, or lost power unexpectedly.* It is written early, during the kernel phase of startup, and it carries the diagnostic data.
6008, from EventLog, verbatim: *The previous system shutdown at 8:17:46 AM on 7/15/2026 was unexpected.* It is written when the Event log service starts, and it carries the one thing 41 does not: the time the machine actually died.
That distinction between event ID 41 and event ID 6008 is worth more than it looks.
On the machine above, 41 was written at 09:06:50 and 6008 at 09:10:07, and 6008 reports the shutdown at 08:17:46. The machine had been down for roughly fifty minutes, and only 6008 says so. If you are writing an incident timeline from event 41, your outage starts at the wrong time.
Reading 41Reading Event 41 without guessing
Microsoft's own article is blunt about the limits: *by itself, Event ID 41 might not contain sufficient information to explicitly define what occurred.* Three fields inside the event decide which of three situations you are in.
| What you find inside 41 | What it means |
|---|---|
| BugcheckCode is not zero | A Stop error. The code identifies which one |
| PowerButtonTimestamp is not zero | Somebody pressed and held the power button |
| Everything is zero, or no 41 at all | Power was interrupted, or the machine hung before it could write anything |
The third row is the common one and the least satisfying, and Microsoft names the likely cause: if the power to a computer is interrupted it can shut down without generating a Stop error, so the next start logs nothing useful. Check the power supply, the battery and the circuit before rebuilding a driver stack.
There is a trap in the first row that costs people an afternoon. The BugcheckCode in Event 41 is written in decimal, and every bug check reference is written in hexadecimal.
A code of 159 in the event is 0x0000009F in the documentation. Convert before searching, and pad to eight digits, because 0x9F and 0x0000009F are the same code written two ways.
One more thing worth knowing if the article does not match what you see. On current Windows, event 41 carries considerably more data than the troubleshooting article lists: the article describes eight fields, and a real 41 on Windows 11 build 26200 contains twenty-one, including LongPowerButtonPressDetected, BugcheckInfoFromEFI, LidState and WHEABootErrorCount.
The documented fields still mean what the documentation says. There are simply more of them now.
Querying itFinding them without clicking through Event Viewer
One command returns every reboot related event in one list, newest first:
Get-WinEvent -FilterHashtable @{LogName='System'; Id=41,1074,6005,6006,6008,6009,12,13}
Add -MaxEvents 20 to keep it short, and StartTime=(Get-Date).AddDays(-30) inside the hashtable to bound it by date. Filtering in the hashtable rather than piping to Where-Object matters on a busy server, because the filter runs inside the log service instead of pulling every record into memory first.
To read the fields inside a 41 rather than the message text, cast the event to XML and walk the EventData, which is where BugcheckCode and PowerButtonTimestamp live. The message on screen does not show them.
The same search in Event Viewer
Event Viewer does the same job without a command. Open it with eventvwr.msc, expand Windows Logs, select System, and choose Filter Current Log. In the event ID box, type 41,1074,6005,6006,6008,6009,12,13 and the log shows only shutdowns and reboots.
One caution applies to both methods. An event ID is only unique within its source, and low numbers are reused. UserModePowerService, for example, writes its own event 12 to the System log. Check the Source column for Kernel-General before reading a 12 or a 13 as a start or a shutdown.
Event ID 6005 and event ID 6006 from EventLog have no such collision.
PitfallsWhere people go wrong
Searching for one reboot event ID. There are six on a clean restart and two more on a dirty one. Which one you want depends on the question, and the question is usually who did it, which is 1074.
Treating event 41 as a cause. It is a statement that the previous shutdown was not clean. On its own it is a symptom, and Microsoft says so.
Taking the timestamp on 41 as the outage start. It is written on the next boot. The time the machine stopped is inside 6008.
Searching a decimal bug check code. 159 finds nothing useful. 0x0000009F finds the documentation.
Assuming a missing 1074 means nothing happened. It means nothing announced itself, which points at a crash or a power loss rather than at a person or a tool.
Filtering only the System log. Event 4608 is in Security, and on a domain controller the account that triggered a restart may only be visible in Security auditing.
Reading the message and stopping. The interesting content of event 41 is in the EventData, and the message text does not display it.
ComparisonThe reboot events, side by side
| Question | Event | Source | Log |
|---|---|---|---|
| Who or what started this restart | 1074 | User32 | System |
| Was it planned | 1074, in the reason text | User32 | System |
| Did the machine crash or lose power | 41 | Kernel-Power | System |
| Exactly when did it stop | 6008 | EventLog | System |
| When did shutdown begin and boot finish | 13 and 12 | Kernel-General | System |
| Which Windows version booted | 6009 | EventLog | System |
| Did Windows start at all | 4608 | Security | Security |
The last row is the one people forget. Event 4608, *Windows is starting up*, lives in the Security log rather than the System log, under the Audit Security State Change subcategory, so a query filtered to the System log will never find it.
FAQFrequently asked questions
What is the reboot event ID in Windows?
There is no single one. A clean restart writes 1074, 6006, 13, 12, 6009 and 6005 in that order. An unexpected shutdown writes 41 and 6008 on the next boot. The one that names who started the restart is 1074.
Which event ID shows who restarted the server?
Event ID 1074, from User32, in the System log. It names the process that initiated the shutdown, the user account on whose behalf it ran, a decoded reason, a reason code and whether it was a restart or a shutdown.
What does event ID 41 mean?
That the system rebooted without cleanly shutting down first, which Kernel-Power logs on the next start. Microsoft states that by itself it might not contain enough information to explain what occurred, so read the BugcheckCode and PowerButtonTimestamp fields inside it before drawing a conclusion.
What does event ID 6008 mean?
That the previous shutdown was unexpected, and it carries the time that shutdown happened. It is written by the Event log service on the next boot, so the event timestamp and the shutdown timestamp are different and the second one is the one you want.
What is the difference between event 41 and event 6008?
They describe the same unexpected shutdown from two places. Event 41 is written earlier, during the kernel phase, and carries the diagnostic fields. Event 6008 is written when the Event log service starts and carries the time the machine actually stopped. Expect both, a few minutes apart.
Why is there no event 1074 for my reboot?
Because nothing announced an intention to restart. Event 1074 records a request, so a crash, a power cut or a hard reset produces no 1074 at all. Its absence is a useful signal rather than a gap in the log.
What are event IDs 6005 and 6006?
6005 is the Event log service starting and 6006 is it stopping. They are the oldest and simplest markers of a boot and a clean shutdown, they predate the kernel events, and they still work, which is why scripts written twenty years ago still use them.
What is event ID 6009?
The Windows version banner, written during boot by the Event log service. It records the operating system version of the instance that just started, which is useful when you are trying to establish whether a machine came back on the build you expected.
What do events 12 and 13 mean?
Kernel-General writes 12 when the operating system starts and 13 when it begins shutting down, both with a system timestamp. They bracket the actual downtime more tightly than 6005 and 6006 do, because the Event log service stops before the kernel does and starts after it.
How do I find the last reboot with PowerShell?
Query the System log filtered to the relevant IDs in one call: Get-WinEvent with a FilterHashtable containing LogName System and Id 41, 1074, 6005, 6006, 6008, 6009, 12 and 13. Filter inside the hashtable rather than piping to Where-Object, because the filter then runs in the log service rather than pulling every record into memory.
Why does the bug check code in event 41 not match the documentation?
Because the event records it in decimal and the documentation uses hexadecimal. Convert the number and pad it to eight digits after the 0x. A BugcheckCode of 159 in the event is the stop code documented as 0x0000009F.
Event 41 has fields the Microsoft article does not list. Which is right?
Both. The article documents eight fields and current Windows writes more, twenty-one on a Windows 11 build 26200 machine, including LidState, WHEABootErrorCount and BugcheckInfoFromEFI. The documented fields still mean what the documentation says; the product has simply added to them.
Where do I look if the machine will not boot at all?
Nowhere in the System log of that machine, because nothing is being written. Take the disk or mount it offline and read the log from another system, and start with 6008, which records when the last shutdown happened, and any 41 from earlier boots.
How do I find out who rebooted the server?
Filter the System log for event ID 1074. It records the user account, the process and the reason given for a restart or shutdown, which is the answer to who rebooted the server. If there is no 1074 before the restart, nobody asked for it, and event 6008 or 41 will show an unexpected shutdown.
What do event ID 6005 and the Windows shutdown event IDs mean?
Event ID 6005 means the event log service started, which marks a boot. Event 6006 means it stopped, which marks a clean shutdown. The other Windows shutdown event IDs are 1074 for a planned restart, 6008 for an unexpected shutdown, and 41 from Kernel-Power for a restart without a clean stop.
Keep readingRelated concepts
Read next · Operations The Blue Screen Is a Decision, and It Leaves Evidence What a Stop error actually is, and where the code in event 41 comes from when the machine crashed rather than lost power. Open this next13 min- Operations · 13 min Patch Management, and Why the Hard Part Is Not the Patching Why the process in event 1074 is so often a patching component, and how the reboot ring gets decided.
- Operations · 9 min Windows Server End of Life, Version by Version The other reason a Windows machine restarts on a schedule you did not choose, and what happens when the updates stop.