WinUI3中含GroupName的RadioButton设置IsChecked时随机触发COMException

以下是具体的定位步骤，逐步缩小问题范围：

• 捕获详细异常信息
  默认情况下Visual Studio可能只显示无额外信息的COMException，需要开启完整异常捕获：

  1. 打开「调试」→「窗口」→「异常设置」
  2. 展开「COM Exceptions」，勾选「Break when thrown」选项
     当异常触发时，就能获取到具体的错误HRESULT值和完整的调用栈，这是定位框架内部问题的核心依据。

• 分析调用栈定位框架模块
  异常触发后，查看调用栈中Microsoft.UI.Xaml.dll内的调用链：

  • 重点关注与RadioButton分组状态同步（如RadioButtonGroupManager相关逻辑）、ContentDialog生命周期管理（如控件销毁/重建时的资源释放）相关的方法
  • 如果调用栈显示异常来自分组状态同步时的COM对象访问，大概率是框架在处理GroupName关联控件时，未正确处理ContentDialog关闭后控件的资源释放，导致再次显示时访问了已释放的对象。

• 验证生命周期与状态残留问题
  既然对话框的Unloaded事件每次都会触发，但崩溃发生在后续显示时，可以做以下验证：

  • 在ContentDialog的Closing事件中，手动将两个RadioButton的GroupName设为null，并重置IsChecked状态
  • 再次多次显示对话框，观察是否还会触发异常。如果异常消失，说明是GroupName关联的控件组状态在对话框销毁后残留，导致下次初始化时冲突。

• 排查版本与框架更新情况
  当前使用的WindowsAppSDK 1.2.221209.1是较旧的版本，很多已知bug在后续版本中已修复：

  • 升级到最新稳定版（如1.4或更高），重复复现步骤，看问题是否消失
  • 查看WinUI3官方的GitHub Issues和发布日志，搜索关键字「RadioButton GroupName ContentDialog COMException」，确认是否有已记录的bug或修复记录。

• 排除自定义样式的影响
  虽然仅修改了状态颜色，但自定义样式可能意外覆盖了框架默认的状态处理逻辑：

  • 暂时恢复RadioButton的默认样式（移除自定义Style），再次测试崩溃情况
  • 如果异常消失，说明自定义样式与GroupName机制存在冲突，需要检查样式中是否修改了与状态同步相关的触发器或事件绑定。

• 替代框架分组逻辑验证
  手动实现RadioButton的分组逻辑，替代框架的GroupName属性：

  // 绑定同一个枚举属性，在属性变更时同步其他RadioButton状态
  private void RadioButton_Checked(object sender, RoutedEventArgs e)
  {
      if (sender is RadioButton checkedRadio)
      {
          var otherRadio = checkedRadio.Name == "Radio1" ? Radio2 : Radio1;
          otherRadio.IsChecked = false;
      }
  }
  

  用这种方式替代GroupName后，如果不再触发异常，即可确认问题根源是WinUI3框架的GroupName机制与ContentDialog生命周期的兼容性bug。

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