双击一个程序图标，等几秒弹出“程序已停止工作”，窗口只有一个关闭按钮，没有其他提示。这种场面在Windows上很常见，但“停止工作”本身不是错误码，它只是外壳，真正的原因藏在事件查看器和转储文件里。选错排查方向，就会在重装和杀毒之间来回折腾。
第一步，先确认弹窗的完整信息。把窗口拉宽或点击“查看问题详细信息”，看有没有附带模块名称、异常代码或故障应用程序路径。很多“已停止工作”弹窗会显示类似appcrash、BEX或clr20r3的签名，这些签名决定了接下来是查内存、查依赖还是查权限。
第二步，打开事件查看器。Win+R输入eventvwr，展开Windows日志下的应用程序，按时间倒序找与弹窗时刻对应的错误事件。重点看事件ID 1000和1001，前者是应用程序错误，后者是Windows错误报告。记录下出错模块名称和异常代码，比如0xc0000005指向访问冲突，0xc0000409指向栈溢出，0xc0000142指向DLL初始化失败。没有代码时，模块名称同样能缩小范围。
第三步，按异常类型分流。若是0xc0000005，先排查数据执行保护设置和第三方注入型软件；若是0xc0000142，优先检查运行库完整性和程序目录权限；若是clr20r3，则多为.NET程序自身异常，需要看堆栈首行。不要把所有“停止工作”都当成同一个问题，异常代码不同，处理路径完全不同。
第四步，检查转储文件。如果系统开启了本地转储，程序崩溃后会在%LOCALAPPDATA%\CrashDumps或临时目录留下.dmp文件。用WinDbg打开后执行!analyze -v，能看到更精确的异常地址和调用栈。对普通排查来说，至少可以确认是程序自身模块崩溃，还是系统DLL被错误调用。
第五步，做最小化验证。把程序搬到另一个用户账户下运行，或者临时禁用所有非微软服务，再启动程序。如果问题消失，说明是配置或第三方组件干扰；如果依旧，则回到程序安装目录检查依赖是否缺失。整个过程不需要重装系统，也不必先跑优化工具。我自己的做法是：先看事件日志里的异常代码，再决定查内存、查依赖还是查权限，顺序对了，多数弹窗都能定位到具体模块。
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 2305938578@qq.com 举报，一经查实，本站将立刻删除，本文链接：https://www.spubm.cn/73138.html
