.NET MAUI WinUI应用长时间运行后导航返回主页面随机崩溃（COMException 0x80004005）求助

这种偶发的长时间运行后崩溃确实让人头疼，结合你提供的堆栈信息和场景，我整理了一些排查方向、可能的修复方案以及复现思路，希望能帮到你：

一、如何更可靠地复现问题 #

• 模拟持续导航+长时间运行：写个简单的循环逻辑，用DispatcherTimer每隔几秒自动执行「跳转到子页面→返回主页面」的操作，让应用保持前台运行持续1小时以上。同时打开Visual Studio的诊断工具，实时监控内存和CPU状态，能更快暴露问题。
• 借助UI自动化工具施压：用WinAppDriver这类工具编写自动化脚本，循环执行导航操作，模拟用户长时间使用的场景，不需要人工值守，更容易捕捉到偶发崩溃。
• 主动制造内存压力：在子页面ViewModel里模拟一些内存占用场景，比如循环创建临时对象、订阅事件后不取消，加速内存泄漏积累，让原本要1小时才出现的问题提前触发，方便排查。

二、排查与修复思路 #

1. 检查页面和ViewModel的资源释放 #

堆栈错误指向ContentPresenter设置Content失败，很大概率是长时间运行后页面/ViewModel没被正确回收，导致UI树状态混乱：

• 让子页面的ViewModel实现IDisposable接口，在Dispose方法里取消所有后台任务、清理跨页面/全局的事件订阅、释放非托管资源。
• 在页面的OnDisappearing方法中，手动清理绑定的数据源或UI元素引用，帮助GC更快回收页面实例。

2. 优化导航逻辑 #

• 尝试用Shell.Current.Navigation.PopAsync(animate)代替GoToAsync("//MainPage")返回主页面，直接弹出栈顶页面的方式比绝对路由跳转更简洁，可能避免路由解析时的潜在异常。
• 给NavigateInternalAsync方法加日志，验证每次导航确实在UI线程执行，避免并发操作UI元素引发冲突。

3. 排查数据绑定和UI元素问题 #

• 暂时简化主页面UI，去掉复杂绑定、自定义控件或第三方控件，逐步恢复后观察是否触发崩溃，定位到具体出问题的UI元素。
• 检查主页面的数据绑定是否存在内存泄漏：比如绑定对象持有页面引用，导致页面无法被GC回收，长时间积累后引发UI状态异常。

4. 环境与依赖检查 #

• 升级到.NET 8的最新补丁版本，同时把MAUI、WinUI相关NuGet包更新到最新稳定版——这类COM异常很多是框架层面的bug，后续补丁大概率已经修复。
• 在OnUnhandledException里补充记录更多异常细节：比如COMException的Message、HResult对应的具体描述，或用WinRT.ExceptionHelpers.GetErrorInfo获取更详细的错误信息，定位具体的WinUI控件问题。

5. 启用详细日志与诊断 #

• 在MauiProgram.cs中添加builder.Logging.AddDebug();开启MAUI导航日志，同时在导航前后添加详细日志，记录导航时间、页面实例ID，方便崩溃时追溯导航历史。
• 用Visual Studio的内存快照功能：在应用运行1小时左右多次抓取快照，对比页面、ViewModel的实例数量，如果实例持续增长没被回收，说明存在内存泄漏，进一步分析泄漏根因。

内容来源于stack exchange