预计您将无法捕获代码中的异常：您的错误来自应用程序的 Xaml 部分，最有可能来自动画。
因此，无论您是在 Xaml 中还是使用代码创建动画，您都会在动画 B 停止时触发动画 A 开始，并在动画 A 开始时触发动画 B 停止。
所以你有一个无限循环：A开始 -> B停止 -> A开始 -> B停止 -> ...
事实上有很多可能的无限循环场景。
它们可能由 CurrentStateInvalidated 处理程序或 Completed 处理程序或 CurrentTimeInvalidated 触发，我可能会忘记使用其他类型的触发器（鼠标，...）和/或前面提到的三种触发器的一些场景。可能是代码太复杂了。
删除所有动画来测试此场景。
尝试有一种清晰的方法来重现错误并检查哪些处理程序可能涉及这样的循环并无休止地互相调用自己。
...您还可以在处理程序中使用计数器，例如，有一个复选框警告您已达到给定（大）数量的调用。该复选框还将给出处理程序的名称。单击“确定”几次以检查循环“成员”。
您可以在发布版本中保留类似的代码，并只写入一次日志文件，当达到该数字时，处理程序将始终在执行任何操作之前返回。总比撞车好。
...或者只是代码审查可能会向您显示可能的循环。
希望这可以帮助。
编辑 ：
请听我的建议：
A ) 删除所有动画，测试应用程序，看看会发生什么。
B ) 如果您没有看到更多错误：这就是原因。
C ) 然后，在动画中，尝试删除最“危险”的触发器，即事件触发器。
您可以使用 将 XAML 放入注释中，因此只需复制触发器即可
动画之后。
D）再次测试：如果您没有看到更多错误，则这是一个事件触发器
E) 检查所有事件触发器并观察如上所述的循环。
如果在 D) 中您仍然看到错误，请使用其他触发器（属性触发器/数据触发器）在 C) 处重复
其次：它可能是一个属性/数据触发器，其中一些数据经常更改......
也许发布一些 xaml。
我有一个想法：尝试在 Application_DispatcherUnhandledException 中设置一个断点。然后观察内部异常的内部异常...直到到达 MS.Internal.Threading.ExceptionFilterHelper.TryCatchWhen。异常，那么你就可以知道来源。我不会感到惊讶的是基础设施网格导致了这个问题。我曾经测试过 Telerik 的控制，在解决了一些可怕的问题后，我只是回到了我自己定制的经典网格：金钱和时间都节省了。我很快就看到了这个网格：它们就像你的问题一样转换器 or 自定义样式与这个网格。
--> 如果可能的话，尝试使用标准 DataGrid。
--> 如果没有错误，我们就有了根本原因：尝试“裸”Infragistic 网格，然后测试，然后添加样式，然后测试。我不确定您是否可以在没有转换器的情况下进行测试。尽管如此，视图模型仍然可以公开“转换后的”属性......
再次：在您的帖子中，引用您的一些 xaml，描述失败案例。
