Event ID 6008: Tracing an Unexpected Shutdown

A server rebooted overnight, nobody admits to touching it, and the only clue in the System log is a line saying the previous shutdown was unexpected. That line tells you when Windows lost control, not why. This guide shows how to read Event ID 6008 next to the events that travel with it, so you can tell a power cut from a crash from a held power button and fix the right thing.

What Event ID 6008 Means

Event ID 6008 is Windows noticing, on the next boot, that the last shutdown never finished. The message reads "The previous system shutdown at [time] on [date] was unexpected." It sits in the System log as an Error.

Microsoft's own description is short: 6008 "indicates an improper or dirty shutdown" and is logged when the most recent shutdown was unexpected. That's in the Event ID 41 troubleshooting guide, which Microsoft updated in February 2026.

So 6008 is a timestamp, not a diagnosis. It says the machine went down around a certain minute. It doesn't say whether the power dropped, a driver crashed the kernel, or someone held the button for five seconds.

Two times matter here. The event itself is created at boot, so its TimeCreated is when the machine came back. The time inside the message is when it went down. The gap between them is your outage, and the minutes just before the second time are where the cause usually hides.

The Events That Travel With 6008

A 6008 rarely arrives alone. The events around it do the explaining, and each one answers a different question.

The quickest read is sequence. A 1074 followed by 6006 is a planned restart that finished. A 1074 with no 6006 and a 6008 on the next boot is a planned restart that hung on the way down. A 41 and a 6008 with no 1074 at all means nothing asked for the shutdown.

Pull the whole set in one pass instead of scrolling Event Viewer:

powershell
Get-WinEvent -FilterHashtable @{
  LogName   = 'System'
  Id        = 41, 1074, 6006, 6008, 1001, 46
  StartTime = (Get-Date).AddDays(-30)
} | Select-Object TimeCreated, Id, ProviderName, Message |
  Format-Table -Wrap

The Id key takes an array, so one query covers every event in the table. If PowerShell is new territory, our list of useful PowerShell commands is sorted by the ticket you're on.

Read Event 41 to Split Crash From Power Cut

Event 41 is where 6008 gets its meaning. Open it, switch to the Details tab, and look at two fields: BugcheckCode and PowerButtonTimestamp. Microsoft's guide sorts every case into three scenarios based on them.

BugcheckCode is not zero. The machine crashed with a stop error. The code is stored in decimal, so convert it: 159 becomes 0x9F, which is DRIVER_POWER_STATE_FAILURE. Microsoft's stop code troubleshooting guide attributes 70% of crashes to third-party driver code and 10% to hardware.

From here it's a crash investigation, and our guide to the blue screen of death walks through reading the dump.

PowerButtonTimestamp is not zero. Someone held the power button. That's rarely the root cause. The real question is why the machine stopped responding badly enough that a person reached for the button.

Everything is zero. Windows had no time to write anything. Microsoft points to power first: a drained or removed laptop battery, an unplugged desktop, an outage, or a power supply that can't carry the load. If Event 46 from volmgr shows up on the same boot, the machine may have crashed but had no working dump file, so check the page file before you blame the power.

This script reads both fields from the last five Event 41 entries and converts the code to hex for you:

powershell
Get-WinEvent -FilterHashtable @{ LogName = 'System'; Id = 41 } -MaxEvents 5 |
  ForEach-Object {
    $d = ([xml]$_.ToXml()).Event.EventData.Data
    [pscustomobject]@{
      Time        = $_.TimeCreated
      Bugcheck    = '0x{0:X}' -f [int]($d | Where-Object Name -eq 'BugcheckCode').'#text'
      PowerButton = ($d | Where-Object Name -eq 'PowerButtonTimestamp').'#text'
    }
  }

That August 2026 thread is the all-zeros case in the wild: a machine that cuts out and then loops on power-on. The replies head straight for the power supply, CPU temperatures and a CMOS reset, which is the right order for a 41 with nothing in it.

Working the All-Zeros Case

A 6008 with an empty Event 41 is a hardware and power hunt. Work it cheapest first, and write down what you ruled out so the next tech doesn't repeat it.

Start with what was happening at the shutdown time. Microsoft's guide says to check both the System and Application logs for anything suspicious just before the time in 6008. A UPS alarm, a thermal warning or a driver reset in the minutes before is worth more than any stress test.

Then work through the list Microsoft gives for this scenario:

1. Turn off overclocking and test at stock speed. Memory profiles count, and our explainer on XMP in BIOS shows where that setting hides.
2. Test the RAM and confirm every stick runs at the same speed.
3. Check the power supply has the wattage for what's installed now, not what was installed at purchase.
4. Check temperatures under load.
5. Put the machine on a UPS if the power itself is the suspect.

Our guide to Windows Memory Diagnostic covers step 2, including what a clean result does and doesn't prove.

Servers and virtual machines add their own suspects. Microsoft lists Automatic Server Recovery software on physical servers, which restarts a box it thinks has hung. On Hyper-V, the heartbeat feature can restart a guest that stops answering. VMware heartbeat monitoring and third-party clusters can do the same. In each case the guest logs a 6008 for a restart that something else decided on.

That r/techsupport thread is where a lot of 6008 searches start: a PC that keeps going down, with 6008 as the only lead. The checklist above is the way through it.

When 6008 Is Not the Whole Story

Some 6008 entries follow a shutdown that was planned. Microsoft has documented a case where a forced shutdown triggered by a program was logged as unexpected because the Event Log service never got the notice. The published example dates from Windows 2000, but the lesson holds: if a 1074 shows who asked for the restart, the 6008 may only mean the shutdown didn't finish cleanly.

Time is the other trap. Microsoft notes that times in an exported .evtx file are shown in the viewer's time zone, so check the server's time zone before you line the log up with a UPS report or a building power log.

This short 2026 walkthrough covers Event ID 6008 on Windows 11:

Tracking 6008 Across a Fleet

One unexpected shutdown is noise. The pattern across machines is the signal, and it points at the cause faster than any single log.

Group the 6008 times by site, by model and by clock. Several machines at one site going down in the same minute is power. The same model failing across clients points at firmware or a power supply batch, and our guide to BIOS updates covers rolling out the fix. One device at random times is that box's hardware. The same time every week is something scheduled.

Get-WinEvent takes a -ComputerName parameter, but only one name at a time, and the event log service port has to be open. That works for a handful of servers. For more, forward the System log into central log management and alert on Event 41 and 6008 together. OpenFrame can also run the query as a script across a client's devices and collect the output in one place.

Keep an eye on uptime alongside it. A good infrastructure monitoring setup tells you a machine dropped before the user does.

Event ID 6008, in Short

Event ID 6008 tells you when Windows went down, never why. Read it with Event 41: a bug check code means a crash, a power button timestamp means someone forced it, and all zeros means power or hardware. Line up 1074 and 6006 to see whether anyone asked for the shutdown, check the logs just before the 6008 time, and look for patterns across machines before you start swapping parts.

If the code in Event 41 isn't zero, the next stop is our guide to the blue screen of death and reading the dump it left behind.