Infinite loop invalidating the TimeManager

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

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:

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)

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).

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.

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 -> ...

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.

... 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.

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

Hope this helps.

EDIT : please please listen to my advice :

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

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 ) 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.

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...

Post some xaml maybe.

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...

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

avani gadhai

At times exceptions are very tricky. One of the suggestion is to have a catch block without the exception object. So you can update your catch block from: