应聚焦事件id 6005与100的时间差定位桌面可用延迟，用etw捕获毫秒级启动轨迹并以wpa分析，结合autoruns扫描隐藏启动项，再通过procmon回溯进程行为细节。
要分析 windows 启动速度减慢的性能日志，核心是定位从固件初始化到桌面可用之间的耗时瓶颈，而不是泛泛查看系统日志。关键在于抓取结构化、带毫秒级时间戳的启动过程数据，并聚焦于真实加载延迟而非估算值。
用事件查看器筛选关键启动事件
Windows 在启动过程中会自动记录多个精确时间点，其中事件 ID 100 和 6005 是最直接的锚点：
- 事件 ID 6005 表示“事件日志服务已启动”，通常出现在内核加载完成后、用户会话初始化前，可视为启动中段基准点
- 事件 ID 100 表示“用户会话已准备就绪”，即 Explorer 加载完成、桌面图标开始渲染，是用户感知“开机完成”的实际标志
- 两者时间差就是从内核就绪到桌面可用的总耗时，若超过 20 秒，说明登录后阶段存在明显延迟
- 在“Windows 日志 → 系统”中筛选 100、6005、101（服务启动耗时）、102（驱动加载耗时），按时间排序，观察相邻事件间隔是否突增（如某服务启动耗时 8 秒）
用 ETW 工具捕获毫秒级启动轨迹
任务管理器和事件查看器只能提供粗粒度参考，真正定位第三方程序加载卡点，需启用 Windows 内置的 ETW（Event Tracing for Windows）：
- 以管理员身份运行 PowerShell，执行：
xbootmgr -trace boot -traceflags BASE+LATENCY+DISK_IO_INIT+FILENAME+FILE_IO+DRIVERS+LOADER - 命令执行后系统自动重启并采集全程数据，日志保存在 %SystemRoot%\Tracing\Boot 目录下，文件名含日期和时间戳
- 用 Windows Performance Analyzer（WPA）打开 .etl 文件，在“Generic Events”或“Process Start”视图中，按“Time Relative to Boot”列排序，找出启动时间晚于 winlogon.exe 但早于 explorer.exe 的第三方进程
- 重点关注 Disk I/O Wait、CPU Usage、Page Faults 高的进程，这些才是真实拖慢桌面呈现的元凶
用 Autoruns 补全隐藏启动入口的上下文
很多程序不走常规启动项路径，而是通过注册表 Run 键、计划任务、映像劫持（AppInit_DLLs）、WMI 事件订阅等方式注入，任务管理器完全不可见：
- 下载微软官方 Autoruns64.exe，解压即用，首次运行取消勾选 “Hide Microsoft Entries”
- 扫描完成后，按 “Time” 列排序，找到加载时间落在 services.exe 启动之后、explorer.exe 启动之前 的条目
- 对路径异常（如临时目录、用户 AppData 下无签名 EXE）、名称模糊（如 Updater、Helper、Agent）的项目，右键选择 “Check Virus” 在线比对哈希值
- 特别注意 “Logon”、“Scheduled Tasks”、“Services”、“Image Hijacks” 等标签页，这些位置常被网盘、输入法、安全软件滥用
结合 Process Monitor 查看进程行为细节
当 ETW 显示某个进程启动耗时长，但不确定是卡在磁盘读取、注册表查询还是 DLL 加载时，可用 ProcMon 进行行为级回溯：
- 运行 procmon.exe → Options → Enable Boot Logging，重启电脑
- 再次打开 procmon，加载生成的 LogBoot.PML，设置过滤器：Operation is Process Start，再加一层 Path contains your_app_name.exe
- 观察该进程启动瞬间的前 50 条操作：是否反复访问不存在的注册表键？是否卡在某个 DLL 的 LoadLibrary 调用？是否大量重试读取网络路径？
- 典型卡顿模式包括：Registry Query 失败后循环重试、File Read 返回 TIMEOUT、TCP Connect 长时间等待响应——这些都指向配置错误或网络依赖问题
