应通过事件查看器→windows日志→应用程序筛选错误/警告事件，依据事件id（如1000、1026）、来源（application error等）、错误模块名（如kernelbase.dll）及异常代码（如0xc0000005）精准定位崩溃根源。
windows 应用崩溃时常常不弹窗、不留痕迹，但系统其实悄悄记下了全部细节。事件查看器就是那个“沉默的见证者”，只要知道看哪里、怎么看，就能快速锁定崩溃根源。
打开事件查看器并直达应用程序日志
按 Win + R，输入 eventvwr.msc 回车，进入事件查看器。在左侧树形菜单中，依次展开 Windows 日志 → 应用程序。这个日志专收用户运行的软件异常，比如闪退、无响应、“已停止工作”等，是排查的第一站。
筛选出真正相关的崩溃事件
应用程序日志条目可能成百上千，直接滚动容易漏掉关键线索。右键“应用程序”日志 → 选择“筛选当前日志”，然后：
- 勾选“错误”和“警告”级别
- 在“事件来源”栏填入
Application Error（通用崩溃）、.NET Runtime（.NET 程序）、Windows Error Reporting，或直接写程序名（如chrome.exe、obs64.exe） - 若记得崩溃大致时间，设置“事件发生的日期和时间”范围
点击确定后，列表就只留下你关心的几条——通常最近一条红色错误就是目标。
重点看懂这四个字段
双击筛选出的错误事件，在“常规”选项卡里盯住以下信息：
- 事件ID：1000 表示普通程序崩溃；1026 是 .NET 异常；1001 常伴随错误报告生成
-
错误模块名称（Faulting Module Name）：如
ucrtbase.dll、KERNELBASE.dll、ntdll.dll—— 指向问题发生的底层组件 -
异常代码（Exception Code）：如
0xc0000005（内存访问违规）、0xe0434352（.NET 未处理异常） - 应用程序名称：确认是不是你要查的那个程序，避免误判
这些组合起来，基本能判断是程序自身缺陷、运行库缺失、还是第三方插件冲突。例如多次崩溃都指向 msvcp140.dll，大概率要重装 Microsoft Visual C++ 运行库。
辅助验证与延伸排查
如果事件日志线索不够明确，可配合其他方式交叉印证：
- 打开“可靠性监视器”（搜索“可靠性历史记录”），它用图形化时间轴标出每次崩溃，点进去能看到对应事件ID和简要描述
- 检查程序自己的日志文件，路径常见于
%APPDATA%\[程序名]\logs\或安装目录下的Logs文件夹 - 对于反复崩溃的程序，尝试以管理员身份运行、禁用兼容性设置、或关闭杀毒软件临时测试
不复杂但容易忽略。
