导读:本期聚焦于小伙伴创作的《事件 ID 1074 系统关机或重启记录代表什么?如何查看和分析?》,敬请观看详情。Windows 事件查看器里的 1074 事件常常让运维人员困惑,它究竟由谁触发、是否代表异常断电。该事件属于 User32 源,记录由进程或用户发起的正常关机与重启,包含原因代码与调用者信息。通过筛选系统日志可快速定位每次关机的精确时间、执行账户与注释内容。理解 1074 与 6006、6008 的差异,能避免将计划维护误判为故障。本文梳理查询命令、字段含义及自动化审计思路,帮助管理员建立关机行为基线。

在 Windows 操作系统的事件日志体系中,事件 ID 1074 是记录系统关机或重启行为的重要条目。它归属于系统日志,事件来源通常为 User32。与意外断电造成的记录不同,1074 明确表示关机或重启是由某个具备权限的进程、服务或用户主动发起的,系统按正常流程执行了关闭操作。理解这条记录的产生机制,是排查系统运维问题的基础。

事件 ID 1074 系统关机或重启记录代表什么?如何查看和分析?

事件 ID 1074 的底层原理与字段结构

当 Windows 收到来自 Win32 API 的关机请求(例如调用 ExitWindowsExInitiateSystemShutdown)时,会话管理器会通知 User32 组件生成一条系统事件。该事件被写入「Windows 日志-系统」通道,事件 ID 固定为 1074。它本质上是一种“受控关闭”的证明,说明系统并非遭遇蓝屏、掉电或硬件故障。

一条典型的 1074 事件包含多个关键字段。其中“进程信息”会列出发起关机的可执行文件完整路径与 PID;“用户”字段显示触发该操作的账户名;“原因代码”以十六进制形式表示关机原因,例如 0x80070000 常对应“其他(计划内)”;“注释”则可能由脚本或安装程序填入。通过分析这些字段,管理员能还原出“谁、在什么时间、以什么理由”关闭了机器。

需要注意,1074 与事件 6006(事件日志服务停止,代表干净关机)以及 6008(上次系统关闭意外)有本质区别。如果只看到 1074 而没有 6008,基本可排除突然断电;若 1074 频繁出现在非维护时段,则可能是某个计划任务或监控代理误触发了重启。

如何快速查看与筛选 1074 关机记录

最直观的方式是打开事件查看器,依次展开「Windows 日志-系统」,在右侧筛选当前日志,输入事件 ID 等于 1074。但对于批量服务器,手动操作效率极低。此时可使用 PowerShell 命令远程收集,示例如下:

# 获取本地系统日志中所有的 1074 事件
$events = Get-WinEvent -FilterHashtable @{
    LogName = 'System'
    Id = 1074
    ProviderName = 'User32'
}

# 提取关键属性并输出
foreach ($e in $events) {
    $xml = [xml]$e.ToXml()
    $user = $xml.Event.EventData.Data | Where-Object { $_.Name -eq 'SubjectUserName' } | Select-Object -ExpandProperty '#text'
    $proc = $xml.Event.EventData.Data | Where-Object { $_.Name -eq 'ProcessName' } | Select-Object -ExpandProperty '#text'
    Write-Output "时间: $($e.TimeCreated) 用户: $user 进程: $proc"
}

上述脚本利用 Get-WinEvent 直接按哈希表过滤,避免遍历全部日志。在域环境中,可将 -ComputerName 参数加入,实现集中巡检。对于历史归档的 .evtx 文件,只需把 LogName 换成文件路径即可。

如果习惯命令行,wevtutil 也是轻量选择:wevtutil qe System "/q:*[System[(EventID=1074)]]" /f:text 能导出纯文本。但注意命令中的双引号在 CMD 下需按 shell 规则处理,建议封装为批处理时写好转义,防止解析失败。

基于 1074 记录的运维分析与避坑实践

很多团队在审计关机时发现 1074 注释为空,便怀疑遭到入侵。其实 Windows 更新组件、Hyper-V 集成服务、第三方杀毒软件都可能在重启时省略注释。此时应结合 Reason Code 与进程路径判断:若进程为 C:WindowsSystem32svchost.exe 且原因代码含“计划内”,多为系统自身更新。

另一个常见误区是认为 1074 一定代表人为点击“开始-电源”。实际上,远程桌面会话中的注销并勾选“关闭”,以及任务计划程序里配置的“重启计算机”动作,同样产生 1074。因此在写事故报告时,不能单凭事件存在就定性为操作员失误,必须交叉比对安全日志中的登录事件 ID 4624 与 4634。

为提升排查效率,建议建设自动化基线:每日凌晨拉取所有服务器的 1074,与变更窗口比对。若某机器在非窗口期出现 1074 且进程为未知路径,则触发告警。下面是一段简单的比对逻辑片段:

import subprocess
import datetime

# 假设已通过 PowerShell 导出 csv,此处读取并判断
def check_offhours(record_time_str, process_path):
    rt = datetime.datetime.strptime(record_time_str, "%Y-%m-%d %H:%M:%S")
    # 定义维护窗口为周一至周五 02:00-04:00
    if rt.weekday() < 5 and 2 <= rt.hour < 4:
        return False
    if "System32" not in process_path:
        return True
    return False

通过此类分析,运维人员能把杂乱的关机记录转化为可行动的安全信号,而不是在故障复盘时盲目猜测。事件 ID 1074 虽小,却是系统健康度画像中不可或缺的一块拼图。

EventID_1074系统日志关机重启修改时间:2026-08-15 19:22:25

免责声明:​ 已尽一切努力确保本网站所含信息的准确性。网站内容多为原创整理与精心编撰,观点力求客观中立。本站旨在免费分享,内容仅供个人学习、研究或参考使用。若引用了第三方作品,版权归原作者所有。如内容涉及您的权益,请联系我们处理。
内容垂直聚焦
专注技术核心技术栏目,确保每篇文章深度聚焦于实用技能。从代码技巧到架构设计,为用户提供无干扰的纯技术知识沉淀,精准满足专业提升需求。
知识结构清晰
覆盖从开发到部署的全链路。AI、前端、编程、数据库、服务器、建站、系统层层递进,构建清晰学习路径,帮助用户系统化掌握开发与运维所需的核心技术。
深度技术解析
拒绝泛泛而谈,深入技术细节与实践难点。无论是数据库优化还是服务器配置,均结合真实场景与代码示例进行剖析,致力于提供可直接应用于工作的解决方案。
专业领域覆盖
精准对应开发生命周期。从前端界面到后端编程,从数据库操作到服务器运维,形成完整闭环,一站式满足全栈工程师和运维人员的技术需求。
即学即用高效
内容强调实操性,步骤清晰、代码完整。用户可根据教程直接复现和应用于自身项目,显著缩短从学习到实践的距离,快速解决开发中的具体问题。
持续更新保障
专注既定技术方向进行长期、稳定的内容输出。确保各栏目技术文章持续更新迭代,紧跟主流技术发展趋势,为用户提供经久不衰的学习价值。