Windows程序卡死时应通过事件查看器查ID为1002的“应用程序无响应”日志，结合可靠性监视器定位时间点，并在Linux中用journalctl检查内核阻塞与服务级日志。

当电脑上某个程序突然卡住、窗口显示“未响应”、鼠标点击无反应，又无法通过任务管理器正常结束进程时，系统其实在后台已悄悄记下关键线索——这些线索就藏在系统日志里。直接看进程状态或强行重启只会掩盖真实原因，而日志能告诉你它卡在了哪一步、等什么资源、被谁阻塞。

Windows事件查看器定位程序挂起事件

第一步：按下 Win + R，输入 eventvwr.msc → 回车。这比从开始菜单点开快得多，尤其在系统已轻微卡顿时更可靠。

第二步：左侧导航栏依次展开【Windows 日志】→【应用程序】，右侧列表默认按时间倒序排列，最新事件在最上方。

第三步：右键【应用程序】→【筛选当前日志】→ 在“事件级别”中仅勾选【错误】和【信息】→ 在“事件来源”框内输入程序名（如 wps.exe、Handler.exe 或你遇到问题的进程名，不带扩展名也可）→ 点击确定。

第四步：重点查找事件ID为 1002 的记录，这是Windows明确标记“应用程序无响应”的信号；若找不到1002，再看ID为 1000（程序崩溃）、1001（.NET运行时异常）的条目。双击打开后，在“详细信息”选项卡里拉到底部，注意“故障模块名称”和“异常代码”字段——【它们直接指向崩溃位置，不是猜测】。

结合可靠性监视器交叉验证时间点

可靠性监视器是Windows自带的“健康档案”，它把程序挂起、系统错误、更新失败等事件按天聚合，用红黄蓝条直观标出问题密度。

方法一：在搜索栏输入“可靠性监视器”并打开 → 页面顶部滑动到你记得程序卡死的日期 → 点击当天的红色叉号图标，下方会列出所有关联事件，包括Application Hang 1002、服务停止、驱动警告等。

方法二：若想导出完整记录用于对比分析，可右键某天的条目 → 【查看相关历史记录】→ 再右键任意事件 → 【将事件保存到文件】，生成.evtx格式存档。

注意：可靠性监视器的数据源正是事件查看器，但它做了时间轴归并，能帮你快速确认“是不是那天唯一出问题的程序”，避免被其他无关错误干扰判断。

Linux系统下用journalctl抓取命令级卡顿日志

当你在终端执行某个命令后光标一直闪烁、无输出、Ctrl+C也无效，问题往往不在命令本身，而在它依赖的服务或内核资源。

第一步：新开一个终端窗口（别关掉卡住的那个），执行：
sudo journalctl -u systemd-journald -n 50 ——先确认日志服务自身是否健康。

第二步：执行 sudo journalctl -n 100 查看最近100行系统级日志，重点找含 “Killed process”、“Out of memory”、“blocked for more than 120 seconds” 的行。如果看到后者，说明内核检测到某个进程被I/O或锁长期阻塞，【这不是程序bug，而是底层资源争抢】。

第三步：若问题与特定服务相关（如docker、nginx），用 sudo journalctl -u docker.service -f 实时跟踪，复现卡顿时观察最后几行输出——常能看到“waiting for lock”或“connect timeout”这类明确提示。