Infinite loop invalidating the TimeManager
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 triggerE) 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.
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
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?
Were they able to help you on this issue?