A secret. The Windows 8.1 Bing News App has been crashing on me for weeks. I’m not sure what’s wrong with it but I run it up (across 3 Windows 8.1 devices, not my Phone – it’s ok there) and it runs for a few seconds and then it crashes. Every time.

I’m assuming that this isn’t happening to all the users of the app and so it must be one of the news feeds that I’ve added into the app which is driving it crazy but I don’t know which one.

I’m not exactly perfect myself though. I’ve got an app of my own that I know is crashing out in the wild and my friend Joost flagged to me that the app was crashing specifically on a Surface 2 device.

I asked whether he would mind sending me a crash dump from that device and he came back with a “how would I do that then?”.

I thought I’d try and write that up here but I haven’t quite succeeded…

One of the nice little features that Visual Studio 2013 has (and possibly 2012 but I haven’t got an install to verify that on right now) is the ability to quickly debug a Windows 8.1 app even if it’s not your app.

This is a convenience but a nice one and so if I want to debug (e.g.) the Bing News app then I can just run Visual Studio 2013 and then use the DEBUG menu;

to debug an installed app package which raises this dialog;

which offers me a chance to browse through the packages installed on the machine (or to filter them by name “Bing” as I’m doing above) and then choose the debugging engine and how I want the debugger to launch the app (e.g. I might want to tick that “Do not launch…” option if I was thinking of debugging something like share activation ).

I think that I have to guess what kind of debugging engine to use though. I don’t think there’s anything in this dialog which will help you figure out which type of debugger to attach in terms of Script/Native/Managed and so on and if it’s not your app that you’re trying to debug then you’re probably not going to know what implementation technology it uses although you could always go and have a poke around inside the app’s folders and see if you can work it out that way.

I might launch it with the native debugger as below;

and then let it run up before hitting BREAK and having a look at the loaded modules in the modules window of the debugger;

As far as I know, WWAHost.exe is the host process for Windows Web Applications so I’m assuming that this is a HTML/JS application. However…there’s something else going on;

so I’ve got to assume there’s some .NET in this app as well and, sure enough, there’s a long list of .NET assemblies loaded into this process;

and there’s also a sign of SQLLite being used as a storage engine;

and some interesting sounding assemblies;

and I haven’t gone and attempted to disassemble any of these but maybe these could be .NET implementations of WinRT components that are then perhaps being called from an HTML/JS UI layer? Mixing technologies like this is a possibility for Windows 8.1 Store apps but it’s something that needs to be done with care because having both a JS engine and the CLR loaded and then paying for the marshalling of data types backwards and forwards across the boundary between those technologies might be a source of performance headaches.

Regardless, if I then debug the package again with Script debugging rather than Native debugging and wait for it to crash then the app seems to stop in its unhandled exception handler;

and there’s a stack trace in that error object;

The text associated with this error code could not be found.

Platform.PlatformException: 103
   at Platform.DataServices.QueryServiceOperation.<GetNetworkResponse>d__49.MoveNext()
— End of stack trace from previous location where exception was thrown —
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()
   at Platform.DataServices.QueryServiceOperation.<>c__DisplayCla

so I’ve got to assume that some piece of code was doing some kind of looping query of data that was mean to come back from the network (presumably updating feeds or similar) and hit an error that it didn’t know how to handle or ignore.

If I debug the app one more time but this time run with the managed debugger, maybe I can see this exception being thrown. That is, restart the app with;

and then set a breakpoint whenever a .NET exception is thrown;

and then letting the code run on. That kind of works “ok” but I was seeing a lot of AggregateExceptions (from Tasks) so I ignored that one exception and a few others until I seemed to land at the call-stack I was expecting from the JS code;

Now, at that point, I’m not necessarily the best person to figure out exactly what’s happened here as it’s not my app but I can move around on that call-stack and have a look at what the locals window can show me. For instance;

and looking in there a little further gives me;

so maybe this is caused by a bad HTTP status being returned which seems fair but the only message I seem to be able to extract out of it is a mysterious “103” value in the exception message.

Wandering around on the call-stack might help. I can see;

and also inside that object I see;

maybe that’s the problem? The URL it’s trying to hit is;

http://az301819.vo.msecnd.net/flighting/prod/v1/en-gb/experiments.json?Client-AppVersion=3.0.1.321

which comes back with a 404 but I’ve no idea what that does or whether it’s important enough such that it being missing makes the app crash.

Probably at this point it’d be wise to find the app developer and give them a crash dump to take a look at.

The debugger can save a memory dump of this process for me using its menu;

and then another developer can open that up hopefully with source code/symbols and have a look at what’s going on.

The Windows Store will generally have these kinds of crash dumps already in their developer portal for the developer of the app and I have a post about that so I’m sure the Bing News folks are processing their crash dumps on a regular basis.

It’s also worth pointing out that this kind of diagnosis can be done remotely. I thought that I could also do it remotely onto an ARM device like my Surface RT but I hit a bit of a blocker in trying to do that here.

Once the remote debugging tools are installed (for ARM or Intel) and you’ve got connectivity between the two machines it’s possible to use that same “Debug Installed App Package” dialog to debug an installed app on a remote machine.

One tip I’d pass on is if you have authentication switched on for the remote debugger (and you should unless you’re on a safe private network) then it’s not always obvious what account to use to connect the remote debugger securely. For instance, on my Surface RT the only account that I use to login is my Microsoft Account (i.e. the one ending in hotmail.com) and so it’s those credentials that I enter to connect the remote debugger session from Visual Studio.

and then I can start debugging that remote installation but the blocker that I hit that surprised me a little was this dialog from Visual Studio;

which I hadn’t expected. I tried debugging a few installed packages and found that I hit the same thing. In fact, the only installed packaged that I seemed to be able to debug this way was one of my own apps for which I have source and which I had deployed onto the device via Visual Studio as part of using the regular cycle of debugging an open project on a remote machine – i.e. via this menu;

I wondered if this was an “ARM” thing – i.e. can I use that “Debug Installed App Package” menu option to remotely debug that Bing News App on my Dell Venue Pro device which is running on Intel. I found the remote debugger on the network, set up the dialog;

and, sure enough, I can debug Bing News on that remote device via the “Debug Installed App Package” menu and that all works fine even down to saving a crash dump either to the local machine (the debugger) or the remote machine (the debuggee);

But I can’t do this to my ARM based Surface RT device as of the time of writing.

Now, this might be a “Windows RT” thing or it might be a “you have set up your remote debugger incorrectly” thing – I’m not 100% sure at the time of writing so if someone has info or a link then let me know and I’ll update the post. It’s not such a common scenario (i.e. debugging someone else’s app on Windows RT) and I don’t think I’d tried it before so I just assumed that it would work in the same way as debugging apps that I’d deployed down to the device myself via Visual Studio.