14

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

abatishchev
  • 98,240
  • 88
  • 296
  • 433
Mike Malter
  • 1,018
  • 1
  • 14
  • 38
  • Is it failing on all machines (in all environments)? Do you have the latest version of WPF including all hot fixes? – Halvard Feb 18 '13 at 18:38
  • Failing on all machines in all environments and yes we are up to date on all service packs. However we are using version 4.0 of .NET and not 4.5, so we don't have the latest version of WPF. We are not likely to upgrade to 4.5 anytime soon. – Mike Malter Feb 19 '13 at 18:21

3 Answers3

4

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.

GameAlchemist
  • 18,995
  • 7
  • 36
  • 59
  • Vincent, thank you for taking the time to answer my question. Have you ever experienced exception before? My situation is that I am working with a graphic designer who knows how to code in xaml, but is not technically inclined. – Mike Malter Feb 12 '13 at 19:31
  • Thank you Vincent for your additional comments. Have you ever experienced this exception before? – Mike Malter Feb 13 '13 at 01:12
  • I just got this exception again and there was no animation involved. I was closing a dialog box that had an Infragistics grid, a text box and four buttons. The exception was thrown as I was closing the dialog box. – Mike Malter Feb 13 '13 at 06:19
  • Ok i am sorry if i was misleading. But, by any chance (and after maybe an another direction is to be seeked) : does that grid you mention involves an animation OR the closing of the grid involves an animation in the parent window ? – GameAlchemist Feb 13 '13 at 20:37
  • Vincent, I did not want my question about whether or not you had ever experienced this issue directly to suggest you were misleading me. Not at all, I welcomed your willingness to jump in and help. I just wanted to know if this had ever happened to you before. When my graphic designer gets back from vacation, I am going to have her look into this from an animation perspective. The grid does not use animation directly, but that does not mean that the designer is not using it in the depths of xaml code. – Mike Malter Feb 14 '13 at 00:23
  • i told about a mislead in reply to your comment 'no animation [was] involved'. I made an edit. – GameAlchemist Feb 14 '13 at 01:44
  • I received the exception using a progressbar and I could prevent it commenting out the animation (of the white glow) in the associated xaml.. Still wondering why though :P – EricG Sep 07 '15 at 08:26
  • Should be marked as answer. Thank you, GameAlchemist. – Maryna Klokova Feb 18 '19 at 11:27
-2

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

Community
  • 1
  • 1
avani gadhai
  • 460
  • 2
  • 12
  • Avani, thank you for taking the time to answer my question. I am interested in your thoughts about how using an empty catch will help me track my issue down? – Mike Malter Feb 13 '13 at 23:07
  • Hi MikeMalter, sorry for the late reply. The empty catch might help you in narrowing down to that region of your code that is throwing exception. – avani gadhai Feb 16 '13 at 07:20
  • How does an empty catch do that? Thanks. – Mike Malter Feb 19 '13 at 20:03
  • 1
    I do get your point, catch(Exception) is only catching an exception of type System.Exception and since I have everything wrapped up in try/catch(Exception) blocks and since the TimeManager exception never gets rolled up into a System.Exception, if I am catching exceptions without arguments I might catch the TimeManager exception. The problem is that the exception is intermittent and happens at random locations under random conditions and re-coding my application to trap this is not an option at this point. However, your answer is the best so far so you get the bounty. – Mike Malter Feb 19 '13 at 20:30
  • 1
    There is no such thing as an exception that doesn't inherit from System.Excetpion in .NET land. This answer is all wrong. https://referencesource.microsoft.com/#PresentationCore/Core/CSharp/System/Windows/Media/MediaContext.cs,1874 – Brannon May 30 '18 at 21:41
-2

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?

rodrigogq
  • 1,943
  • 1
  • 16
  • 25
  • Rodrigo, Your link is for WinForms and my question pertains to WPF. I looked at the link you posted and it is not relevant. – Mike Malter Oct 18 '14 at 02:12
  • I understand that, and that is why I thought you should look at. There isn't any referente to TimerManager class in WPF. Any chance you are using a wrong reference or something that might be crashing your WPF using WinForms classes? – rodrigogq Oct 19 '14 at 04:23