无限循环的无效TimeManager [英] Infinite loop invalidating the TimeManager

问题描述

我在我的WPF应用程序遇到了一个非常棘手的缺陷追查。错误消息是：

I am experiencing a very tricky defect in my WPF application to track down. The error message is:

这是无限循环似乎导致从多次
布局在TimeManager无效/渲染过程。

An infinite loop appears to have resulted from repeatedly invalidating the TimeManager during the Layout/Render process.

堆栈跟踪（对于它的价值）是：

The stack trace (for what it's worth) is:

在System.Windows.Media.MediaContext.RenderMessageHandlerCore（对象
resizedCompositionTarget）在
System.Windows.Media.MediaContext.RenderMessageHandler（对象
resizedCompositionTarget）在
System.Windows.Threading.ExceptionWrapper.InternalRealCall（代表
回调，对象指定参数时，的Int32 numArgs）在
MS.Internal.Threading.ExceptionFilterHelper.TryCatchWhen（对象
源，代表法，对象ARGS，的Int32 numArgs，代表
catchHandler）

at System.Windows.Media.MediaContext.RenderMessageHandlerCore(Object resizedCompositionTarget) at System.Windows.Media.MediaContext.RenderMessageHandler(Object resizedCompositionTarget) at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs) at MS.Internal.Threading.ExceptionFilterHelper.TryCatchWhen(Object source, Delegate method, Object args, Int32 numArgs, Delegate catchHandler)

这是一个间歇性的缺陷，唯一的地方我都不能抓住它是在我圈住Application_DispatcherUnhandledException消息应用程序配置文件。我的一切都在我的应用程序被包裹在尝试catch块，但在此捕捉未处理的异常的地方卷起。

This is an intermittent defect, and the only place I can ever catch it is in the app config file where I am trapping the Application_DispatcherUnhandledException message. Everything I have in my app is wrapped in try catch blocks and yet this winds up in the place for catching unhandled exceptions.

没有人有任何见解呢？我搜索的东西，互联网和发现什么，也许还以为有人在这里可能有一些见解或观点如何跟踪下来。目前，我吞下此异常，让应用程序继续运行，因为它似乎不具备（不是崩溃这等）上的任何影响。

Does anyone have any insight into this? I've searched the internet for something and have found nothing and thought maybe someone here might have some insight or ideas how to track this down. Currently, I am swallowing this exception and letting the app continue to run as it does not seem to have any effect on it (other than crashing it).

推荐答案

这是可以预料的，你将无法捕获异常代码：你的错误来自于你的应用程序的XAML中的一部分，从动画最有可能。

It is to be expected that you won't be able to catch the exception in the code : your bug comes from the Xaml part of your application, from an Animation most probably.

所以，无论您在XAML中或使用代码创建动画，你是，例如，触发动画时，动画乙停止开始，和动画B到时停止动画A开始。
所以，你有一个无限循环：一个开始 - >乙站 - >一个开始 - > B停止 - > ...

So, wether you create animation within Xaml or using code, you are, for instance, triggering animation A to start when animation B stops, AND Animation B to stop when animation A starts. So you have an endless loop : A Start -> B stops -> A Start -> B stop -> ...

有很多死循环情况可能实际上。
他们可能被CurrentStateInvalidated处理程序或已完成处理程序，或CurrentTimeInvalidated被触发，我会忘记使用其它类型的触发器（鼠标，...）和/或以前mentionned三大一些场景。可能的代码是太复杂了。

There are many endless loop scenario possible in fact. They might be triggered by a CurrentStateInvalidated handler OR a Completed handler, OR a CurrentTimeInvalidated, and i might forget some scenarios using other types of triggers (mouse, ...) and/or the three previously mentionned. Possibly the code is too complex.

删除所有动画来测试这种情况。

Remove all animations to test this scenario.

尝试有一个清晰的方式来重现错误，并检查该处理器可能在这样的循环中参与并自称彼此不休。

Try to have a clear way to reproduce the bug and check which handlers might be involved in such a loop and calling themselves one another endlessly.

...你也可以使用处理器内的柜台，并有，例如，一个复选框，提醒您达到调用一个给定的（大）的数量。该复选框也给处理程序的名称。点击ok几次检查循环成员。结果
你可以在发行版本保持类似的代码，并有一个日志文件写的，只有一次，当达到这个数字，那么处理程序将始终做任何事情之前返回。不是崩溃更好。

... you might also use a counter within the handlers and have, for instance, a checkBox warn you that a given (big) number of calls was reached. This checkBox would also give the handler's name. click ok several time to check the loop 'members'.
You can keep a similar code in the release version and have a log file written, only once, when that number is reached, then the handler would always return before doing anything. Better than a crash.

...或者只是一个代码审查可能会告诉你可能的循环（S）。

... or just a code review might show you the possible loop(s).

希望这有助于

编辑：
请，请听从我的建议是：

EDIT : please please listen to my advice :

A）删除所有动画，测试应用程序，看看会发生什么。
B）如果您没有看到更多的错误。这是原因

A ) remove all animations, test the application, and see what happens. B ) If you see no more bug : this is the cause.

C）然后，在anims，尝试删除最危险的触发，事件触发。
你可以把XAML为注释使用，所以只需复制过去动画后触发

C ) Then, in the anims, try removing the most 'dangerous' trigger, the event trigger. You can put XAML into comments by using , so just copy past the trigger after the animation.

D）测试再次：如果你看到没有更多的错误，这是一个事件触发
e）审查所有的事件触发就像我上面描述看一个循环。

D ) Test again : if you see no more bug, this is an event trigger E) Review all the event trigger and watch for a loop like i described above.

如果在D）你还是看的bug，位于C与其他触发器重复）（属性触发/数据触发）

if in D) you still see the bug, repeat at C) with other triggers ( Property Trigger / Data Trigger )

二，虽然：它可能是一个属性/数据触发了一些数据变化非常频繁...

Second though : it might be a Property / Data Trigger with some data changing very often...

发表一些XAML也许吧。

Post some xaml maybe.

我有一个想法：尝试设置一个断点在Application_DispatcherUnhandledException。然后看内部异常的内部异常的......直到你到达MS.Internal.Threading.ExceptionFilterHelper.TryCatchWhen。例外，那么你就可以知道源。我不会感到惊讶它是Infragistics的网格导致了问题。我曾经测试过Telerik的控制和战斗的几个可怕的问题后，我只是回到上一个经典的格子，我自己定制的：时间和金钱都得救了。我赶紧看了这个网格：他们就像是转换器或自定义样式这个网格像你这样的问题。
- >尝试，如果可能的话，一个标准DataGrid结果
- >如果没有错误，我们根本原因：尝试'裸'Infragistic格，然后进行测试，再加入风格，然后进行测试。我不知道，你可以不带转换器测试。尽管如此，总是可以让视图模型暴露转换属性...

I had an idea : try to set a breakpoint in your Application_DispatcherUnhandledException. Then watch the inner exception's inner exception's ... until you reach the MS.Internal.Threading.ExceptionFilterHelper.TryCatchWhen. exception, then you can know the source. i wouldn't be surprised it is the Infragistics grid causing the issue. I once tested Telerik's control, and after fighting a few terrible issues, i just went back on a classical grid that i customized myself : both money and time were saved. I watched quickly for this grid : they are like issues like yours with converters or custom styles with this grid. --> try, if possible, a standard DataGrid.
--> if there's no bug, we have the root cause : try a 'bare' Infragistic grid, then test, then add style, then test. I am not sure you could test with no converters. Still it is always possible to have the view model expose the 'converted' properties...

还是那句话：在您的文章，您引用一些XAML，描述故障的情况下

Again : in your post, quote your some xaml, describe the fail-cases.

这篇关于无限循环的无效TimeManager的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！