(Case 946609) Beta 10 - Mixed Reality Apps Launched from Visual Studio crash immediately.

Unity Engine
1

This has been happening in the last few betas. When building UWP with C# projects enabled the game crashes at startup from a Unity dll everytime.

Stack Trace:

This is the output leading up to the crash.

This is becoming a major blocker.

2

Okay, so it turns out I can at least get into the game if I change the build from x86 to x64 and enable Mixed debugging.

If mixed debugging is not enabled the game silently crashes at start. However, with mixed debugging on, it shows the native exception and I can press F5 to continue past it without it crashing the game.

The above bug is still applicable to x86, but there is another interesting issue.

The game now loads as expected. When switching from a successfully loaded first scene to a new scene the game throws a strange null reference exception I’ve never seen before.

It looks like Unity Engine is trying to call Start on my GameObject but getting a null reference exception.

Here is the stack trace:

3

The first crash you mentioned is a known issue and will be fixed in a future beta.

As for the NullReferenceException - I don’t think that GameObject (or actually the MonoBehaviour) is null, as it would then be thrown in “UnityEngine.Internal.$MethodUtility.InvokeMethod”, rather than GamePlayManager.Start(). You should be able to enable “break on null reference exception” in exception settings in VS and it should stop in your script when it gets thrown.

1 Like
4

Attached shows how the debugger recognizes the first curly brace of the method as where the exception is thrown.

On the GamePlayManagerStart.png you can see how I have a breakpoint on the first line of the Start method and it never gets hit. The native exception gets thrown first.

I tried running the game as a UWP with the headseat unplugged (regular UWP pc game) and the exception on GamePlayManager.Start() was not thrown. The start method gets called successfully. However, I was able to continue and executed code that would take me to a different scene. When I did this I received the exception shown in ShotBehaviorException.png. This script was on an object in the scene that was getting destroyed. Same issue where the debugger broke on the first curly brace on the method scope.

3209606--245702--GamePlayManagerStart.PNG
3209606--245703--ShotBehaviorException.PNG

5

After digging into things a bit more it looks like I can’t hit any managed/c# breakpoint when debugging in mixed mode.

mixed mode = no managed breakpoints
managed only = fatal crash at game start that can not be continued

3209624--245707--NoBreakpoint.PNG
3209624--245707--NoBreakpoint.PNG1772×186 11.6 KB

3209624--245708--manageddebuggercrashexit.PNG
3209624--245708--manageddebuggercrashexit.PNG1196×246 7.88 KB

6

Try sticking this in one of your source files (don’t forget to remove it before shipping):

using System.Diagnostics;

[assembly: Debuggable(DebuggableAttribute.DebuggingModes.Default | DebuggableAttribute.DebuggingModes.DisableOptimizations)]

This should suppress JIT optimizations when using mixed mode debugger (I think managed debugger does this automatically).

7

Added it in. Still not recognizing managed break points.

8

Sorry, I have no idea why it behaves that way :/. I’ll ask around if anyone knows why breakpoints wouldn’t work.

Could you go into project properties → Build and enable .NET Native toolchain? Afaik .NET Native uses a different debugging engine and that might make breakpoints work. It will make builds take longer, but that’s better than not being able to debug at all. You could also try setting to “native mode” debugging with .NET Native - that will still allow you to step through managed code, but watch window will behave a little bit differently.

9

By enabling .NET native toolchain, I was able to debug managed code. From there I was able to isolate the null reference exception to .net code that was executing in the start method.

But, you were correct. It was a painfully long wait just to get the compile completed. This isn’t a work flow that can be used going forward.

I am currently using Visual Studio 2017 Community edition version 15.2. I will update to the latest version and see if that allows managed debugging.

10

Yeah, I tried recreating your scenario and debugging managed code worked just fine here. I’m on VS 2017 version 15.3. I don’t know why you’re hitting such weirdness.

11

Did you by any chance try it on the Insider Preview fast ring build 16281?

12

No, I am on stable 15063 windows build.

13

This is happening for me on the insider build, which is required for mixed reality development. Do you by any chance have someone available that can quickly do a spot test on an insider build?

14

In which Unity beta are you seeing this crash?

15

Beta 10.

16

The debug breakpoint issue has been reported.

Any update on when this fix is coming? This is a big blocker for Mixed Reality Launch.

17

The inability to debug a Universal Windows App is still happening in the first Release Candidate. Is there an update on when this fix will land?

I can’t imagine a full, public release will be approved with such a severe bug.

18

We’re in the process of actively investigating it.

1 Like