2

Here's a strange issue I'm facing with a Windows 8.1 XAML application.

A bug in DevExpress controls causes the entire application to crash, despite my implementation of exception handling. DevExpress developers have replicated this particular bug and are working on a solution - this question is about the crash despite error handling and NOT about the DevExpress bug.

The unique thing about this crash is that it breaks on this line in the auto-generated code in App.g.i.cs (as opposed to other exceptions being thrown in other places):

#if DEBUG && !DISABLE_XAML_GENERATED_BREAK_ON_UNHANDLED_EXCEPTION
            UnhandledException += (sender, e) =>
            {
                if (global::System.Diagnostics.Debugger.IsAttached) global::System.Diagnostics.Debugger.Break();
            };
#endif

It seems this is triggered when some kind of exception / crash happens in XAML-related mechanisms (but this is just a wild guess on my part)... I don't think the above code is responsible for the "crash to desktop" effect, but it does seem to be a symptom.

My own code for error handling (in App.xaml.cs):

public App()
{
  //...
  this.UnhandledException += App_UnhandledException;
  //...
}

private async void App_UnhandledException(object sender, UnhandledExceptionEventArgs e)
{
    var ex = e.Exception;
    e.Handled = true;
    Logger.LoggingError(ex);
        await Controls.MessageDialog.Show(ex.Message, Controls.MessageDialog.DialogType.Error, Controls.MessageDialog.DialogButtons.Retry, ElementTheme.Light);
    var frame = Window.Current.Content as Frame;
    frame.Navigate(typeof(Views.SplashLoading));
}

The error handling attempts to:

  1. log the error
  2. display the error
  3. go back to the start view

Again - this generally works very well for all other purposes. But if ever the breakpoint in App.g.i.cs gets triggered (or would get triggered, if the application is released on client machines) then my error handling fails completely.

Note, that this isn't exclusive to DevExpress controls. It's just that the DevExpress control causes this behavior in a way that can be replicated. Again - if an exception would cause the code in App.g.i.cs be fired, then it seems there's no saving the application.

What could I do to make sure the application keeps going once this unfortunate event occurs and doesn't crash to the desktop?

EDIT:

For reference, this is the error message which occurs when using the DevExpress controls:

System.ArgumentException: The parameter is incorrect.

The value cannot be infinite or Not a Number (NaN).
   at Windows.UI.Xaml.Controls.ScrollViewer.ChangeView(Nullable`1 horizontalOffset, Nullable`1 verticalOffset, Nullable`1 zoomFactor, Boolean disableAnimation)
   at DevExpress.Core.Native.DXVirtualizingPanel.ScrollElementIntoView(Double elementOffset, Double rowHeight)
   at DevExpress.Core.Native.DXVirtualizingPanel.ScrollIntoView(Int32 visibleIndex)
   at DevExpress.UI.Xaml.Grid.DataControlBas

Unfortunately that's the full message - it appears the complete stack-trace is missing.

MBender
  • 5,395
  • 1
  • 42
  • 69
  • What is the actual error message? – Barptad Jan 22 '16 at 11:51
  • @Barptad I've added the exception message for the `DevExpress` controls to the question. I don't think it matters however... – MBender Jan 22 '16 at 12:11
  • Can you your clarify your question? Are you afraid that event handler from `App.g.i.cs` will be fired in release version on the end-user device? – Alex Jan 22 '16 at 12:31
  • @Alex Hmm, I was hoping I was clear enough. The application crashes to the desktop despite my error handling code. I wish to prevent that - I want to display an error message and go back to the start view. The crash seems to happen only when the code in `App.g.i.cs` is executed - but I think this is a symptom, not the cause. – MBender Jan 22 '16 at 12:35
  • "Again - this generally works very well for all other purposes. But if ever the breakpoint in App.g.i.cs gets triggered (or would get triggered, if the application is released on client machines) then my error handling fails completely." I've asked because of this part of your question. I can't understand it. Sorry. So your error handling works great, but it doesn't work only in case of code execution from `App.g.i.cs`. Am I right? – Alex Jan 22 '16 at 12:48
  • And what do mean under "my error handling fails completely"? Is it executes? – Alex Jan 22 '16 at 12:49
  • Why not just fix the thing causing the error instead of trying to circumvent it reporting? I would chew one of my guys if they did something like this. – Chris W. Jan 22 '16 at 15:50
  • @Alex It fails in preventing the application from crashing and returning the user to the desktop. I does execute. – MBender Jan 22 '16 at 17:18
  • @Chris W. Well, if it's my error, then I fix it. But if an error from an external DLL causes issues then I can only find workarounds, and those aren't always reliable. If the proverbial poop hits the fan I want to have reliable error handling for all cases to make sure the user experience is as smooth as possible. – MBender Jan 22 '16 at 17:20
  • Fair enough, I've not worked with any of the DevExpress stuff yet but I've heard their support is pretty decent. Maybe shoot it over as a bug report and see what they have to say? – Chris W. Jan 22 '16 at 19:09
  • @Chris W. That was the first thing I did. But it was about a month ago, and the bug is apparently quite complicated (or so I was told) and the bug is still there. I'm using workarounds, but those occasionally fail... – MBender Jan 22 '16 at 20:52

1 Answers1

0

Apparently setting e.Handled = true; does not guarantee that the application won't crash (as described on MSDN):

The Windows Runtime considers exceptions encountered during certain operations as nonrecoverable, because the Windows Runtime itself will be in an inconsistent state following these exceptions. For such exceptions, even if the UnhandledException event handler sets Handled to true, the app will still be terminated.

However, why does the DevExpress cause such an invalid state with its control is a mystery to me... But at least it solves the question of why the app closes despite the event being handled.

Extra thanks goes to the folks from DevExpress support team, who helped with the case.

MBender
  • 5,395
  • 1
  • 42
  • 69