Windows 10 Crash Whodunit

Question

I have an app in the store that has been causing me some headaches. My client reported, and I verified, that the app crashes/closes in the following scenario:

• Launch the app
• Close the app
• Wait at least ~15 minutes
• Open the app

The app will close right as the splash screen ends and the extended splash screen starts. It's unclear what's causing the issue. The app will keep closing/crashing. The app has to be completely deinstalled and installed again before it starts working again. I'm only able to reproduce this issue with the store version of the app. I'm not finding any crash reports in the Event Viewer program.

I've downloaded some crash reports from the dev portal but I don't think I'm seeing that crash show up based on the timestamps and frequency of the crashes.

Extra Information: I'm not running any background tasks, or tile updates.

I have three sub-questions:

1. What are the good places to look for in the system to find out more about why the app is closing?
2. Is it possible for me to run a store build on my system so that I can run some tests without having to submit the app to the store each time?
3. Based on the fact that 1) the app runs the first time 2) runs any subsequent time when launched within ~15 minutes or the previous launch 3) will close itself when running it when the previous launch was > 15 minutes ago 4) it only happens in the store build, does anyone have any ideas what could be causing this?

UPDATE:

I tried to debug the store version of the app using Visual Studio and all I can see is the following:

Exception thrown at 0x00007FFF54D7A1C8 (KernelBase.dll) in App.exe: 0x40080201: WinRT originate error (parameters: 0x000000008000000E, 0x000000000000002C, 0x0000006E46EAE9B0).
Exception thrown at 0x00007FFF54D7A1C8 (KernelBase.dll) in App.exe: 0x40080201: WinRT originate error (parameters: 0x000000008000000E, 0x0000000000000046, 0x0000006E46EAE630).
The thread 0x1be8 has exited with code 1 (0x1).
The thread 0xfa8 has exited with code 1 (0x1).
The thread 0x115c has exited with code 1 (0x1).
The thread 0x730 has exited with code 1 (0x1).
The thread 0xed4 has exited with code 1 (0x1).
The thread 0x1894 has exited with code 1 (0x1).
The thread 0x18a0 has exited with code 1 (0x1).
The thread 0x194c has exited with code 1 (0x1).
The thread 0x1a3c has exited with code 1 (0x1).
The thread 0x1988 has exited with code 1 (0x1).
The thread 0x16ec has exited with code 1 (0x1).
The thread 0x1584 has exited with code 1 (0x1).
The thread 0xfd0 has exited with code 1 (0x1).
The thread 0xd8c has exited with code 1 (0x1).
The thread 0xcec has exited with code 1 (0x1).
The thread 0x16b4 has exited with code 1 (0x1).
The thread 0x12f8 has exited with code 1 (0x1).
The thread 0x146c has exited with code 1 (0x1).
The thread 0x36c has exited with code 1 (0x1).
The thread 0x1854 has exited with code 1 (0x1).
The thread 0x1ae4 has exited with code 1 (0x1).
The thread 0xa38 has exited with code 1 (0x1).
The thread 0x230 has exited with code 1 (0x1).
The program '[3840] App.exe' has exited with code 1 (0x1).

I guess programs normally exit with code 0, so something must be wrong. It's hard to see what the exception thrown is.

I tried to break at the exception and step over to see what is causing it but all I got was another exception:

Exception thrown at 0x00007FFF54D7A1C8 in App.exe: Microsoft C++ exception: _com_error at memory location 0x000000EE2788E9D0.

I uploaded a version of the app to the store with a built in easter egg allowing me to disabled all code in the extended splash screen. Even all the code disabled it still crashes/closes.

UPDATE 2: The time-frame after which the app starts closing on startup seems to be related to the time it takes the system to hibernate/sleep.

Answer 1

I guess it could have something to do with the app's life cycle.

After your app is suspended by the user, it could be terminated by the OS due to resource constraints. When this happens, the previous session data in your app will be lost. So if you don't have any checks to restore the data and if your app start-up depends on this data, the app will crash and give you for example, NullReferenceExceptions.

One way to debug this is to use the Visual Studio's Lifecycle Events debugger. To activate it, you need to run your app, then open up the Lifecycle Events in the taskbar (see image below) and select Suspend and shutdown. Note this will cause the app to close. Now re-launch the app with Visual Studio, and this time it's launched from the Terminated mode.

Normally you will see the following piece of code in your App.xaml.cs. It's a good place for restoring your previous app state. A good reference can be found here (note it's for Windows 8 store apps, but it's the same concept in UWP).

if (e.PreviousExecutionState == ApplicationExecutionState.Terminated)
{
    //TODO: Load state from previously suspended application
}

Also, I would strongly recommend you to write your exceptions to a log file and either store it to a server or, politely ask users to email it to you. Since the crash happens in the app's foreground, you will be able to catch it in -

public App()
{
    this.UnhandledException += (s, e) => { };

Hope this helps and good luck!