应通过事件查看器→windows日志→应用程序筛选错误/警告事件，依据事件id（如1000、1026）、来源（application error等）、错误模块名（如kernelbase.dll）及异常代码（如0xc0000005）精准定位崩溃根源。
windows 应用崩溃时，栈信息（call stack）是定位问题根源最直接的线索——它记录了崩溃瞬间函数调用的完整路径，相当于程序“倒下前最后一刻在做什么”。结合系统日志归档，不仅能复现单次故障，还能横向比对、识别模式性缺陷。关键不在堆栈本身多深，而在于如何准确提取、关联和长期留存。
从事件日志里快速抓取有效栈线索
并非所有崩溃日志都显式显示完整调用栈，但部分字段已隐含关键路径信息：
- 事件ID为1000（Application Error）的日志中，“错误模块名称”（Faulting Module Name）和“异常地址”（Fault Address）组合，可指向具体DLL或EXE中的可疑区域；若模块名是第三方组件（如pdfium.dll、libcef.dll），优先排查该模块版本兼容性
- 事件ID为1026（.NET Runtime）的日志，在“详细信息”→XML视图里查找
<data></data>节点中包含StackTrace字段的内容，里面就是托管代码的原始栈帧，含类名、方法名与行号（需PDB匹配） - 若日志描述中出现“无法访问内存位置”“尝试读取/写入受保护内存”，大概率对应栈顶函数存在空指针解引用、数组越界或已释放内存访问——此时栈底（最老调用）往往是问题触发点，而非栈顶（最后执行）
用转储文件还原真实调用栈
事件日志只给线索，转储文件（.dmp）才保存现场。没有它，栈信息常被截断或符号缺失：
Windows-Android_SSH_Remote_Control
下载
通过 SSH 隧道从 Android 设备在互联网上对 Windows PC 实现完整远程控制的设置与使用指南，适用于远程桌面访问、安全 RDP 等。
- 用WinDbg Preview加载.dmp后，执行
!analyze -v，输出中STACK_TEXT段即为原始栈；重点关注靠下的几行——通常是你的业务代码入口（如MyApp!MainWindow::OnButtonClick+0x2a），而非系统DLL - 若看到
ntdll.dll!NtWaitForSingleObject或kernelbase.dll!WaitForMultipleObjectsEx在栈顶，说明不是崩溃，而是线程死锁或长时间挂起；需配合~* kb查看所有线程栈对比 - 符号路径必须配置正确：
.sympath srv*C:\Symbols*https://msdl.microsoft.com/download/symbols（微软公有符号）+ 本地PDB路径；否则栈中全是十六进制地址，无法定位源码
日志归档要兼顾可检索性与上下文完整性
单次分析靠工具，长期治理靠归档——但随便复制粘贴日志文件容易丢失关键上下文：
- 导出事件日志时，右键“应用程序”日志 → “将所有事件另存为…” → 选.evtx格式，它保留结构化字段（如EventID、ProviderName、TimeCreated），比文本更利于后续PowerShell批量筛选
- 归档转储文件时，务必配套保存同次崩溃的.evtx文件、程序版本号、操作系统版本（
winver）、以及崩溃前3分钟内的CPU/内存使用快照（可用typeperf或性能监视器导出.blg） - 建立命名规范：例如
MyApp_v2.4.1_Win11_230615-142218_crash_1000.dmp+..._log.evtx，时间戳精确到秒，避免多崩溃混杂
自动化归档与轻量级监控建议
人工归档易遗漏，尤其对频繁崩溃的应用，可借助系统能力降低维护成本：
- 启用WER自动转储：注册表配置
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps下DumpFolder（路径）和DumpType（2=全内存），系统会在每次崩溃后自动生成.dmp并记录事件ID 1001 - 用PowerShell定时归档：每周运行脚本，筛选过去7天Application日志中EventID=1000的条目，导出.evtx并压缩存档，同时发送摘要邮件（含崩溃次数、高频模块、Top 3异常代码）
- 对自研应用，在
App.UnhandledException中不仅写本地crash_log.txt，还调用EventLog.WriteEntry写入自定义事件源，确保它出现在事件查看器中，与其他系统日志统一管理
