05 September 2018

Getting a quick Mixed Reality log file from someone else's computer or HoloLens

When the **** hits the fan

A quick tip this time, born from necessity. I guess we've all been here - you make a perfectly working Mixed Reality app for Immersive Headsets and/or the HoloLens,, you test the hell out of it, you submit it to the store, you get approved, and you sit back and relax to wait for download numbers to go up and five star reviews to roll in...

... except they don't. Between the five stars a few one stars appear. "Does not work". "Crashes immediately on my system". Especially on Immersive Headsets things like this can happen, for the simple reason there are like 8 different headsets out there, connected to Finagle knows how many differently configurated PCs. I've had this happen to me last year, on systems that were configured with gtx1080i-based systems and/or the Samsung Odyssey headset - those things were so bloody fast my app ran into timing issues. But I didn't have either so I could not reproduce. What to do?

Getting the log file from a PC

Turns out you can actually get a Unity Player logfile from someone's system pretty easily. If your user is using an Immersive Headset, simply ask them to open go to the desktop of the PC the headset is connected to, open the File Explorer and go to the following folder:


In that folder there are a number of app-specific folders, usually quite a lot. Suppose there's a problem with my app AMS HoloATC. In the folder, your user needs to find the folder that is specific for AMS HoloATC


So you user needs to look into 17852LocalJoost.AMSHoloATC_rt0w0x8frck66

In that folder there's a folder TempState, which contains your coveted UnityPlayer.log:


In that file there's a lot of stuff - basically everything you see passing by in your Visual Studio Output window if you are running the app from Visual Studio:

    Version:  Direct3D 11.0 [level 11.1]
    Renderer: Intel(R) HD Graphics 630 (ID=0x591b)
    Vendor:   (null)
    VRAM:     2111 MB
Initialize engine version: 2018.1.0f2 (d4d99f31acba)
WARNING: Shader Unsupported: 'MixedRealityToolkit/InvisibleShader' - Pass '' has no vertex shader
UnloadTime: 1.484216 ms
TryGetGeometry always returns false.
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug.bindings.h Line: 43)

Display is Opaque
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug.bindings.h Line: 43)

NullReferenceException: Object reference not set to an instance of an object.
   at OpaqueDetector.get_IsOpaque()
   at InitialPlaceByTap.Start()
   at InitialPlaceByTap.$Invoke2(Int64 instance, Int64* args)
   at UnityEngine.Internal.$MethodUtility.InvokeMethod(Int64 instance, Int64* args, IntPtr method) 
(Filename: <Unknown> Line: 0)

And lo and behold - apparently my OpaqueDetector class is playing havoc on the user's machine. Now at least I know where my app is going wrong.

Getting the log file from a HoloLens

You can do the same thing on a HoloLens, but there are a few caveats there:

  • You can only do this for sideloaded apps, not apps installed from the Store
  • Your user will need to use the file explorer in the device portal.


In User Folders \ LocalAppData \ 17852LocalJoost.AMSHoloATC_2.1.9.0_x86__rt0w0x8frck66 \ TempState \ you will find the log file. But you will need to send the user experiencing the problem an Appx package first. Since HoloLenses are basically all the same, this scenario is not very likely to happen, but it can be useful if you are making a sideloaded business app and someone hits upon an unforeseen scenario making the app behave in an unforeseen way - this may help a quick diagnosis.

Important notes

  • The log file is overwritten every session. So if the user starts the app again after aforesaid unexpected behavior, the data is gone. So make sure people using or testing the app know this.
  • Make sure you only write none-sensitive stuff to the log stuff: API keys, cookie values, decoded stuff and other information you don't want to tell the word - don't write that in your log file.
  • This is not a replacement for instrumentation. But it can (and has been to me) a life saver if someone from the HoloDevelopers Slack community can repro the problem, can quickly send you some log files, you can send a fixed Appx back for them to test, and in a few rounds you can squash the bug and submit a fixed version - even if you don't have access to the system playing havoc.

Credits and thanks

Special thanks to freshly (finally!) minted MVP Jesse McCulloch, both for making me aware of this file and where to find it - as well as being that invaluable repro/tester for me when Walk the World for Immersive Headsets suddenly started to crash on certain configurations - including, fortunately, his 

No comments: