App minimization and relaunch causes consistent and reproducable crash for Windows 10/8.1

It looks like I have a consistent and reproducable crash case on most Windows 10 and Windows 8.1 devices:

1) Minimize your game.
2) Go to your app list, and "relaunch" the game by pressing on your app icon.
3) Normally, non-Unity Windows app behaviour is that "relaunching" your game via tapping your game's icon in your list of apps on device (when it's already open in background) simply maximizes the application. However, with Unity the app maximizes then immediately crashes.

This issue does not occur if you minimize the app and maximize it by selecting it from your list of background apps. This only happens if you minimize the app and then launch the app by pressing its icon in your app list (as you normally would if launching it for the first time). Again, non-Unity apps behave such that if you were to do this with an app already in background, it would just maximize the app. With Unity apps, it crashes.

This issue was tested and confirmed with a Unity 5.4.3p4 build on the following devices:

Windows Phone 8.1 ARM build on Nokia Lumia 620
Windows 10 x86 build on Samsung Series 7 Slate tablet (both in tablet mode and desktop mode)
Windows 10 x86 build on Asus laptop (desktop mode only)
Windows 10 ARM build on Nokia Lumia 925

Strangely, the issue does not occur on a Windows 8.1 x86 build on an Asus laptop running Windows 10, nor does it occur on a Windows 8.1 ARM build on Microsoft Surface 2 tablet.

These are the only logs I get from a Windows 10 x86 build:

It's strange, but I notice that the local version and app version logs are the same logs that appear when the app first launches. So it's almost like it's actually trying to re-launch the app rather than maximizing it.

 

Ah, very helpful. No new logs, but it now triggered a breakpoint at this line in App.xaml.cs

Code (CSharp):

1. appCallbacks.AddCommandLineArg("-force-gfx-direct");

We fixed an issue with our project we had a while ago by adding this line to force single-threaded rendering as per this documentation: https://docs.unity3d.com/Manual/CommandLineArguments.html

Full code of InitializeUnity() method is here:

Code (CSharp):

1.         private void InitializeUnity(string args)
2.         {
3. #if UNITY_WP_8_1 || UNITY_UWP
4.             ApplicationView.GetForCurrentView().SuppressSystemOverlays = true;
5. #if UNITY_UWP
6.             if (Windows.Foundation.Metadata.ApiInformation.IsTypePresent("Windows.UI.ViewManagement.StatusBar"))
7. #endif
8. #pragma warning disable 4014
9.             {
10.                 StatusBar.GetForCurrentView().HideAsync();
11.             }
12. #pragma warning restore 4014
13. #endif
14.             appCallbacks.AddCommandLineArg("-force-gfx-direct");
15.             appCallbacks.SetAppArguments(args);
16.             Frame rootFrame = Window.Current.Content as Frame;
17.  
18.             // Do not repeat app initialization when the Window already has content,
19.             // just ensure that the window is active
20.             if (rootFrame == null && !appCallbacks.IsInitialized())
21.             {
22.                 rootFrame = new Frame();
23.                 Window.Current.Content = rootFrame;
24.                 Window.Current.Activate();
25.  
26.                 rootFrame.Navigate(typeof(MainPage));
27.             }
28.  
29.             Window.Current.Activate();
30.         }

Looks like it doesn't like it. I'll let you know what I get with a D3D build.

 

Looks like the issue is fixed. Thanks!

As for multi-threaded rendering, it's been a long while since we looked at that issue. From what I am able to remember, our touch input response was visually sluggish.

To explain, our game uses an on-screen thumbstick controlled by touch input, which is rendered on its own orthographic UI camera (the rest of the scene is rendered on a separate perspective camera). Even if the rest of the game was running at a smooth 60 FPS, the UI camera would appear to always suffer from a super low framerate on Windows devices only. Whereas normally the thumbstick is supposed to always be directly underneath your thumb, the thumbstick would now severely lag behind your thumb or cut and skip all over the screen which made it look like a framerate problem.

This wasn't just a visual problem either. Character movement, since it's directed by the thumbstick movement, was also affected even if the rest of the scene was running at a smooth 60 FPS.

We've seen this issue for a year or two, but I don't think we ever identified the true source of the problem. Forcing single-threaded rendering was simply a hotfix that both immediately fixed the issue and didn't break anything else (except for this crash issue we just discussed) so we never really looked back on it.