WPF应用触发System.AccessViolationException，如何调试？

一、先排查环境与近期变更 #

• 确认是否最近做了Telerik库版本升级：这类异常常出现在控件库更新后，调用栈里的HwndSubclass信号指向Win32窗口子类化逻辑，回滚到之前稳定的Telerik版本测试，看是否恢复。
• 检查Windows系统更新：近期系统补丁可能影响WPF的Win32交互逻辑，对比崩溃出现前后的系统更新记录，尝试卸载可疑补丁测试。
• 排查第三方依赖变更：除Telerik外，是否更新了其他NuGet包、组件，或引入新的UI工具类？逐一回滚测试。

二、针对WPF UI线程与内存问题的调试手段 #

1. 收集完整崩溃转储并分析 #

• 用Windows任务管理器右键进程选择「创建转储文件」，或用procdump.exe -e -w Avalon.exe自动收集崩溃转储。拿到转储后：
  • 在Visual Studio中加载转储，勾选「显示外部代码」查看原生调用栈，定位具体Win32消息或Telerik控件内部代码。
  • 用WinDbg执行!analyze -v命令自动分析崩溃原因，重点关注Telerik控件的非托管内存操作异常。

2. 监控UI线程非法操作 #

• 开启WPF线程调试助手：在App.xaml.cs的OnStartup中添加System.Windows.Threading.DispatcherHelper.EnableDispatcherUnhandledException();，同时订阅DispatcherUnhandledException事件，捕获更多UI线程未处理的隐藏异常。
• 排查跨线程UI操作：部分场景下非UI线程直接操作控件不会抛出明显异常，但会导致内存损坏。用Visual Studio的「线程窗口」监控Dispatcher线程，检查是否有跨线程控件调用。

3. 针对Telerik控件的专项排查 #

• 聚焦崩溃关联控件：复制网格（如RadGridView）、上下文菜单（RadContextMenu）、窗口（RadWindow），单独测试这些控件的使用场景，看是否能复现崩溃。
• 检查自定义模板/样式：是否有自定义控件模板中使用了不安全的绑定或资源引用？比如绑定到已释放对象、静态资源生命周期异常。
• 核对Telerik已知问题：确认当前版本的Telerik控件是否存在涉及窗口子类化、拖拽、菜单弹出的AccessViolationException已知bug。

三、内存损坏深层排查 #

• 启用托管堆检查：在项目属性中勾选「启用本机代码调试」，然后在调试选项（Debug -> Options -> Debugging -> General）中开启「启用托管堆检查」，帮助定位托管对象的非法内存访问。
• 内存快照分析：用Visual Studio内存分析器或CLR Profiler捕获运行时内存快照，对比崩溃前后的对象状态，查看是否有Telerik控件对象被提前释放、引用计数异常的情况。
• 模块隔离测试：拆分应用为单独模块逐一加载测试，找到触发崩溃的具体模块或组合，缩小排查范围。

四、临时缓解措施（如需快速恢复） #

• 禁用Telerik控件高级特性：比如RadGridView的复制功能、RadWindow的自定义拖拽逻辑，改用WPF原生控件替代测试。
• 关闭硬件加速：在App.xaml中添加RenderOptions.ProcessRenderMode="SoftwareOnly"，排除显卡驱动兼容性导致的随机UI崩溃。

内容的提问来源于stack exchange，提问作者Damien