Windows Store Build Freezes with No Error

I have a reproducible bug in my game where the Windows Store build will freeze up with no errors or reason. Watching the cpu activity in the profiler, it actually drops to zero and sits. The managed callstack if paused it just shows it sitting at the CoreApplication.Run phase (which I think is a lie), and native callstack is included below.

I can’t think of any reason for this to happen (and its not happening on any other platform). It happens whenever I try to destroy a large number of objects (either by loading a new scene after first loading a complex scene), or when I reset the large scene by destroying the scenes dynamic root object (to allow quick scene reset I duplicate the dynamic root, activate it, and then when I need to reset I destroy that duplicate and make a new one). Anyway, that’s my guess… any ideas from anyone else? Looking at the callstack it does seem to be trying to Destroy something.

I’ll try submitting the project, but it will be huge. I wouldn’t even know where to start at making a small repro unfortunately.

-Sean

Native Callstack

ntdll.dll!_NtWaitForMultipleObjects@20() Unknown
KernelBase.dll!_WaitForMultipleObjectsEx@20() Unknown
coreclr.dll!01e5ce5e() Unknown
[Frames below may be incorrect and/or missing, no symbols loaded for coreclr.dll]
coreclr.dll!01e5cbf1() Unknown
coreclr.dll!01fc6feb() Unknown
mscorlib.ni.dll!0ff3f1a5() Unknown
mscorlib.ni.dll!0ff3f09c() Unknown
mscorlib.ni.dll!0ff3f137() Unknown
236f0573() Unknown
0ec1d3cb() Unknown
0ec1d2e2() Unknown
0f9d93b0() Unknown
00ffd166() Unknown

UnityPlayer.dll!metro_invoke_method(struct ScriptingMethodDotNet,class WinRTScriptingObjectWrapper,struct ScriptingArguments *,class WinRTScriptingObjectWrapper *,bool) Unknown
UnityPlayer.dll!scripting_method_invoke(struct ScriptingMethodDotNet,class WinRTScriptingObjectWrapper,struct ScriptingArguments &,class WinRTScriptingObjectWrapper *,bool) Unknown
UnityPlayer.dll!ScriptingInvocation::Invoke(class WinRTScriptingObjectWrapper *,bool) Unknown
UnityPlayer.dll!ScriptingInvocation::Invoke(class WinRTScriptingObjectWrapper *) Unknown
UnityPlayer.dll!ScriptingInvocationNoArgs::Invoke(void) Unknown
UnityPlayer.dll!ScriptingInvocationNoArgs::InvokeChecked(void) Unknown
UnityPlayer.dll!MonoBehaviour::CallMethodInactive(struct ScriptingMethodDotNet) Unknown
UnityPlayer.dll!MonoBehaviour::WillDestroyComponent(void) Unknown
UnityPlayer.dll!GameObject::WillDestroyGameObject(void) Unknown
UnityPlayer.dll!PreDestroyRecursive() Unknown
UnityPlayer.dll!DestroyGameObjectHierarchy(class GameObject &) Unknown
UnityPlayer.dll!DestroyObjectHighLevel(class Object *,bool) Unknown
UnityPlayer.dll!DelayedDestroyCallback(class Object *,void *) Unknown
UnityPlayer.dll!DelayedCallManager::Update(int) Unknown
UnityPlayer.dll!Script_RunDelayedDynamicFrameRate() Unknown
UnityPlayer.dll!PlayerLoop(bool,bool,class IHookEvent *) Unknown
UnityPlayer.dll!metro::MainLoop(bool) Unknown
UnityPlayer.dll!UnityPlayer::AppCallbacks::MetroMainLoop(void) Unknown
UnityPlayer.dll!UnityPlayer::AppCallbacks::smile:oPerformUpdateAndRender(void) Unknown
UnityPlayer.dll!UnityPlayer::AppCallbacks::PerformUpdateAndRender(void) Unknown
UnityPlayer.dll!UnityPlayer::AppCallbacks::_AppThreadImplementation(void *) Unknown
UnityPlayer.dll!UnityPlayer::AppCallbacks::_AppThread(void *) Unknown
UnityPlayer.dll!(void)() Unknown
UnityPlayer.dll!Platform::smile:etails::__abi_FunctorCapture<class <lambda_a289f33883e38467cd81ad5832c27d4b>,void,struct Windows::Foundation::IAsyncAction ^>::Invoke(struct Windows::Foundation::IAsyncAction ^) Unknown
UnityPlayer.dll!Windows::System::Threading::WorkItemHandler::Invoke(struct Windows::Foundation::IAsyncAction ^) Unknown
UnityPlayer.dll!Windows::System::Threading::WorkItemHandler::[Windows::System::Threading::WorkItemHandler::__abi_IDelegate]::__abi_Windows_System_Threading_WorkItemHandler___abi_IDelegate____abi_Invoke(struct Windows::Foundation::IAsyncAction ^) Unknown
threadpoolwinrt.dll!0f724c6f() Unknown
threadpoolwinrt.dll!0f72aff6() Unknown
kernel32.dll!743862c4() Unknown
ntdll.dll!__RtlUserThreadStart() Unknown
ntdll.dll!__RtlUserThreadStart@8() Unknown

actually, now that I look at it, the project folder is around 30gb… that’s probably not practical to send. I assume there is some combination of folders I can send that would give you enough to debug the UWP project? If you can tell me what you need (I assume the build directory with the visual studio solutions minus the giant “Players” folder, and then the script assets from the Assets folder?) I’d be happy to put a smaller submission together.

If you don’t have any custom modifications in the export VS solution, then we only need Assets and ProjectSettings directories from you Unity project.
However, before sending a giant project it’s worth to try to investigate, what’s failing.
From the stack trace one question that arises: are you using InvokeOnUIThread/InvokeOnAppThread anywhere in your scripts/exported solution? Or perhaps you have so Windows Store specific plugins that do use that?

I removed a few Invokes I was using but that didn’t fix it. I’ll dig into it a little bit more from that angle tomorrow and see if I can dig up any more info. I do have some custom stuff in the VS solution (xbox live configuration and such), but its probably just a few files I’d need to send in addition to Assets/ProjectSettings. If I can’t make any more headway tomorrow I’ll zip it up and get it sent over.

It’s amazing what actually using the VS thread window can do. Turns out it was one of the third party scripts using Threading. One of the other 3rd party scripts I was using had WindowsStore threading polyfill, so I used that for another… that was a mistake. The polyfill implemented thread cancellation wrong, so the other script was locking waiting for its thread to come back canceled. Rewrote it using ThreadPool and now I’m back in business. Thanks for taking a look. Glad I didn’t waste your time with the giant project :wink: