先分辨计划内还是意外
机器在凌晨重启，最要紧的是先判断它属于计划内还是意外：计划内关机由某个进程或用户发起，事件日志里会留下明确的发起者信息；意外关机则表现为日志被突然中断，随后重新开始记录。判断清楚之后，处理方向完全不同——前者要找到是谁发起的、是否有变更窗口授权；后者要往前追硬件、电源或蓝屏线索。整个过程的核心是把几个关键事件按时间排列，拼出一条从关机到开机的完整时间线。
关键事件编号
| 1074 | 计划内的关机或重启，记录发起进程与用户；Windows 更新、管理员命令、备份软件都常见 |
|---|---|
| 6005 | 事件日志服务启动，表示系统开始记录；是开机时间线里的起点标记 |
| 6006 | 事件日志服务停止，表示干净关机；有记录说明关机过程正常完成 |
| 6008 | 上次关机不干净；只说明结论，原因要往前找 |
| 41 | 内核电源异常，系统未干净关闭；常见于断电、硬件故障或强制断电 |
| 41 之外的蓝屏记录 | 结合崩溃转储与故障检查信息；用于区分软件崩溃与电源问题 |
排查步骤
- 先从系统日志里取出上述编号的事件，按时间升序排列成时间线
- 看关机前是否有计划内关机记录，并确认发起进程与账户
- 若没有计划内记录，找断电级事件的记录点与之前的最后一条正常日志
- 核对是否有蓝屏或存储相关错误，判断是软件崩溃还是电源问题
- 虚拟机环境要把宿主平台的运维事件一并纳入核对
- 确认原因后再决定后续动作：变更授权、硬件巡检或驱动更新
常用示例
常用示例
# 取近三天与开关机相关的事件，按时间排列
Get-WinEvent -FilterHashtable @{LogName='System'; Id=1074,6005,6006,6008,41; StartTime=(Get-Date).AddDays(-3)} |
Sort-Object TimeCreated |
Format-Table TimeCreated, Id, ProviderName, @{n='摘要';e={($_.Message -split "`n")[0]}} -AutoSize
# 只看计划内关机，确认发起者
Get-WinEvent -FilterHashtable @{LogName='System'; Id=1074} -MaxEvents 5 | Select-Object TimeCreated, Message
# 查看意外关机与内核电源事件
Get-WinEvent -FilterHashtable @{LogName='System'; Id=6008,41} -MaxEvents 10 | Select-Object TimeCreated, Id, Message结论与下一步
| 时间线表现 | 结论 | 下一步 |
|---|---|---|
| 关机前有 1074 记录 | 计划内重启 | 核对发起进程与是否有授权变更 |
| 有 6006 且有 1074 | 流程完整，属正常重启 | 无需进一步处理 |
| 只有 6008 与 41 | 意外关机 | 查电源、硬件与崩溃转储记录 |
| 41 之前有蓝屏相关记录 | 系统崩溃导致重启 | 分析转储文件并核对驱动变更 |
| 虚拟机且宿主有维护记录 | 宿主侧操作引起 | 结合宿主平台事件确认 |
计划内关机事件里会写明发起进程和用户，先看这一项再下结论：更新程序、管理员命令与备份软件都可能触发重启，性质与故障完全不同。
意外关机事件只说明上一次关机不干净，本身不是原因。判断根因要往前找内核电源事件、蓝屏记录或硬件告警，必要时结合崩溃转储文件与硬件日志。