Infinite loop invalidating the TimeManager

Question

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

Answer 1

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.

Answer 2

I'm a bit late to the party, but hopefully this will help someone else in the future.

I've experienced this issue recently, but after ruling out the typical animations per-se, I've tracked it down to something that I didn't consider an animation (which looking back was a mistake) - VisualStateManager with Storyboards with a single KeyFrame. But in a very very specific combination of different factors.

So let's start with my VisualStateGroup:

<VisualStateGroup x:Name="ExpansionStates">
  <VisualState x:Name="Expanded">
    <Storyboard>
      <ObjectAnimationUsingKeyFrames Storyboard.TargetProperty="(UIElement.Visibility)"
                                     Storyboard.TargetName="ItemsHost">
        <DiscreteObjectKeyFrame KeyTime="0" Value="{x:Static Visibility.Visible}" />
      </ObjectAnimationUsingKeyFrames>
    </Storyboard>
  </VisualState>
  <VisualState x:Name="Collapsed" />
</VisualStateGroup>

As you can see, it seemed quite simple. But here are the factors that complicated this very much and caused the mentioned issue in my scenario:

• The items which had the VisualStateManager states were part of a custom control with VirtualizingStackPanel.IsVirtualizing="True" and VirtualizingStackPanel.VirtualizationMode="Recycling"
• The ItemsHost visibility was changed in the Visual State. This also caused the actualHeight and actualWidth of the element to change.

After switching to VirtualizationMode="Standard", the crashing went away but I saw what was probably causing it under the hood - some of the items in my listView were getting rendered on top of each other if you were scrolling through them quickly, creating a very artsy (but broken) collage. However, it didn't cause a crash and was resolving itself after a split second.

I dug a bit deeper and found that going back to the Ol' reliable <Trigger>s for changing the Visibility instead of using the VisualStateGroup resolved all the issues.

So to sum it up: If you get here with the same issue and are using VisualStateManager inside something that has virtualization, and the States can change the actual height/width of the rendered items, this can in some cases lead to this hard to debug scenario. Consider switching to Triggers for the debugging!

Answer 3

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:

 catch(Exception ex)
{
..
}

to

    catch()
{
..
}

There are other low level exceptions that are difficult to catch, as mentioned in the reply by Peli

Answer 4

Have you already solved your problem? I was researching a little bit, and it sounds like you are using third-party controls from Infragistics right?

http://help.infragistics.com/doc/WinForms/2014.2/CLR4.0/?page=Infragistics4.Win.UltraWinStatusBar.v14.2~Infragistics.Win.UltraWinStatusBar.TimerManager.html

Were they able to help you on this issue?