How can I get useful information (like stack traces) on C# Windows Store (Metro) Apps, when they crash?

Question

So I'm doing my first steps in C# (and .NET/Visual Studio in general) and started by writing a simple tile puzzle as a portable library and writing UI's for different target platforms. I started with a Console UI and moved to a WPF Application. Then I tried "Windows Store" and for the most part I could copy the WPF code and just change some namespaces and method signatures.

But some thing do behave a bit differently and it took me over an hour of googling to get it to give me any kind of information about the crashed I was having. So if for example I make something like this in the conventional WPF application:

Storyboard.SetTargetProperty(animation,       new PropertyPath("{Canvas.MispelledProperty}")); 

I get a .NET exception at the exact place where the exception is raised. If I do the same mistake in the Windows Store App all I get to see is this

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

(Edit: this is in a file called App.g.i.cs)

And then I have to carefully look at the output to find

WinRT information: Cannot resolve TargetProperty (Canvas.MispelledProperty) on specified object. 

Now in some cases this might be enough but, but I really find it hard to believe that is all you can get. I got some problem related with nuances in the way Storyboar works sorted out pretty easily (Completed events attached directly to the animation where not being fired like in the WPF counterpart) but right now I'm completely clueless about a this error:

A first chance exception of type 'System.ArgumentOutOfRangeException' occurred 

caused simply by wildly clicking around, which also crashes the entire app.

Now my app is really trivial and it probably has something to do with how I handle PointerPressed and PointerReleased events but it's really frustrating not to have something better to start with.

So I guess the actual question would be: Is it really supposed to be like this or can I configure the debugger to give me more useful information? And if not then: What kind of debugging techniques/workarounds do you guys use when developing Windows Store Apps?

UPDATE:

Well at first I thought this only happened to WinRT related Exception that where happening outside the CLR and where not properly wrapped but it turns out all unhandled exceptions take you to App.g.i.cs instead of the place where they happened. For instance I purposely tried to access a list out of it's ranges in a method to see if Visual Studio would take me there when the exception was raised but instead it took me again to App.g.i.cs. In the locals I get this Windows.UI.Xaml.UnhandledExceptionEventArgs and the message string has some information that looks almost like stack trace but has no line numbers. Here is an example of my intentional error:

System.ArgumentOutOfRangeException    at System.ThrowHelper.ThrowArgumentOutOfRangeException()    at System.Collections.Generic.List`1.get_Item(Int32 index)    at StorePuzzle.PuzzleRenderer.HandleTileReleased(Object sender, PointerRoutedEventArgs e) 

All I want is Visual Studio to immediately take me to place where the exception is being raised instead of taking me to App.g.i.cs just like it does in "Non Store Apps". Now, that compiler preprocessor directives makes it look like I could just turn it off (#if DEBUG && !DISABLE_XAML_GENERATED_BREAK_ON_UNHANDLED_EXCEPTION) but googleing it has not showed me any way of doing so.

Answer 1

I have a very similar question myself about getting stack traces and dumps which I asked here: How do I get crash logs and stack traces from WinRT apps written in C#?.

Microsoft makes getting crash info from WinRT apps very difficult compared to Android. Unlike Android there is no builtin log like logcat where you can see why your app crashed with a simple stack trace. Android gives this to developers and doesn't ask them to write a single line of code!

For WinRT apps It looks like we all have to roll our own solutions to this problem. There are many different places exceptions can occur, if you want to log them all--and what's the point of logging exceptions if you don't log them all--it looks like it is going to be a lot of work!

This article gives some explanation on how to catch XAML exceptions so that you can log them:

• http://msdn.microsoft.com/en-us/library/windows/apps/windows.ui.xaml.application.unhandledexception.aspx

This article explains why you'll need to wrap all the code in your async event callbacks with try/catch:

• Unhandled exception handler not called for Metro / WinRT UI async void event handler

This library looks like a good choice for doing the logging, although it does seem a bit heavy since it relies on SQLite, if there is a lighter choice that does need a database that might be preferred.

• https://github.com/mbrit/metrolog

UPDATE:

Microsoft has announced some new logging capabilities in Windows 8.1, docs are up now here:

http://msdn.microsoft.com/en-us/library/windows/apps/windows.foundation.diagnostics.loggingchannel

Answer 2

Debugging exceptions in your code, when you know the specific type of exception you are looking for, is easy.

Select Debug then Exceptions from the menu (or Ctrl+D Ctrl+E)

Search your specific exception and check thrown.

The debugger will stop right at the line of code, where the exception occurs.

I usually have most exceptions turned on to find problems early on.

Errors in XAML are a different beast though and are sometimes very hard to find.