A whole month, this random submission error 1201 and unproducible crash reported by certification team of Windows store promoted me to look for the problem and solution in my UWP app that never existed.
When submitting the app to Windows Store, the submission will typical fail within 5 minutes after pre-processing complete. The following error message is what shown:
This submission failed with error code(s) 1201 . More info about the error(s) can be found here.
Quick online search mention about using old Microsoft.NETCore.UniversalWindowsPlatform may caused this problem, but I’m using the latest version 6.2.8 which doesn’t have this problem. The certification team told me to resubmit the app because this might be just some random issue on the server, which I did and fail again. I recompile the whole package again and submit to Windows Store. Well, everything went wel…. crash, crash, crash!
Now certification team told me that my app crash on startup which I was not able to reproducible at all using the same package I submitted to Windows store. I even tested it on multiple different machine which different language and region configuration. So I did the same trick of recompile and submit. The app still crash on startup when certification team tried the app. Here are the stack track captured in crash report, although it make no sense to me.
appname::app onlaunched() stowed_exception 80131500: stowed_exception combase.dll RoOriginateLanguageException() error.cpp:1504 System.Private.Interop System::Runtime::InteropServices::ExceptionHelpers OriginateLanguageException() ExceptionHelpers.cs:113 System.Private.Interop System::Runtime::InteropServices::ExceptionHelpers GetHRForExceptionWithErrorPropogationNoThrow() ExceptionHelpers.cs:219 System.Private.Interop System::Runtime::InteropServices::McgMarshal GetHRForExceptionWinRT() McgMarshal.cs:1239 appname.UniversalWindows.McgInterop.dll __Interop::ReverseComStubs.Stub_12_System __Canon_$catch$0() SharedStubs.g.cs:11147 mrt100_app.dll RhpCallCatchFunclet2() exceptionhandling.asm:438 mrt100_app.dll System::Runtime::EH DispatchEx() ExceptionHandling.cs:683 mrt100_app.dll System::Runtime::EH RhThrowEx() ExceptionHandling.cs:552 mrt100_app.dll RhpThrowEx2() exceptionhandling.asm:198 System.Private.Interop System::Runtime::InteropServices::McgMarshal ThrowOnExternalCallFailed() McgMarshal.cs:1267 appname.UniversalWindows.McgInterop.dll __Interop::ComCallHelpers Call() SharedStubs.g.cs:8527 appname.UniversalWindows.McgInterop.dll Windows::UI::Xaml::Controls::IFrame__Impl::Stubs Navigate() ImplTypes.g.cs:158360 appname.UniversalWindows.McgInterop.dll Windows::UI::Xaml::Controls::Frame Navigate() SafeTypes.g.cs:44489 appname.UniversalWindows.exe appname::App OnLaunched() App.xaml.cs:76 System.Private.Threading System::Progress$1_$89_System::VoidValueTypeParameter_.System.IProgress_T_ Report() SafeTypes.g.cs:23264 appname.UniversalWindows.McgInterop.dll __Interop::ReverseComStubs.Stub_12_System __Canon_() SharedStubs.g.cs:11130 appname.UniversalWindows.McgInterop.dll Windows::UI::Xaml::IApplicationOverrides__Impl::Vtbl OnLaunched__n() ImplTypes.g.cs:138287 Windows.UI.Xaml.dll DirectUI::FrameworkApplicationGenerated OnLaunchedProtected() frameworkapplication.g.cpp:502 Windows.UI.Xaml.dll DirectUI::FrameworkView OnActivated() frameworkview_partial.cpp:267 Windows.UI.Xaml.dll Microsoft::WRL::Details::DelegateArgTraits_long (__cdecl Windows::Foundation::ITypedEventHandler_impl_Windows::Foundation::Internal::AggregateType_Windows::UI::Core::CoreWindow *,Windows::UI::Core::ICoreWindow *_,IInspectable *_ *)() event.h:245 Microsoft::WRL::InvokeTraits_-2_::InvokeDelegates__lambda_3ad0adb09957fd62cbc86618ebbeb8fa_,Windows::Foundation::ITypedEventHandler_Windows::ApplicationModel::Core::CoreApplicationView *,Windows::ApplicationModel::Activation IActivatedEventArgs *_ _() internalevent.h:119 twinapi.appcore.dll Windows::ApplicationModel::Core::CoreApplicationView Activate() coreapplicationview.cpp:545 rpcrt4.dll Invoke() invoke.asm:183 rpcrt4.dll Ndr64StubWorker() srvcall.cxx:392 rpcrt4.dll NdrStubCall3() srvwrap.cxx:166 combase.dll CStdStubBuffer_Invoke() stub.cxx:1446 rpcrt4.dll CStdStubBuffer_Invoke() ndrfwds.cxx:182 combase.dll ObjectMethodExceptionHandlingAction__lambda_c9f3956a20c9da92a64affc24fdd69ec_ _() excepn.hxx:87 combase.dll DefaultStubInvoke() channelb.cxx:1452 combase.dll SyncServerCall StubInvoke() servercall.hpp:826 combase.dll ServerCall ContextInvoke() ctxchnl.cxx:1418 combase.dll ASTAInvokeInApartment() applicationsta.cpp:470 combase.dll AppInvoke() channelb.cxx:1182 combase.dll ComInvokeWithLockAndIPID() channelb.cxx:2290 combase.dll ThreadDispatch() chancont.cxx:416 combase.dll ModernSTAState HandleMessage() modernsta.cpp:472 combase.dll ModernSTAWaitContext HandlePriorityEventsFromMessagePump() modernsta.cpp:1550 Windows.UI.dll Windows::UI::Core::CDispatcher ProcessMessage() dispatcher.cpp:339 Windows.UI.dll Windows::UI::Core::CDispatcher WaitAndProcessMessagesInternal() dispatcher.cpp:1953 Windows.UI.dll Windows::UI::Core::CDispatcher WaitAndProcessMessages() dispatcher.cpp:461 twinapi.appcore.dll _lambda_643db08282a766b00cec20194396f531_ operator() coreapplicationviewagilecontainer.cpp:1145 SHCore.dll _WrapperThreadProc() thread.cpp:321 ntdll.dll RtlUserThreadStart() rtlstrt.c:1152
Contacted certification support team, but the certification support team insist that I should contact the developer support team. Contacted the developer support team, but the developer support team insist that I should contact the certification support team. In the end, both doesn’t even provide any help or direction and keep quite.
Long story, I rollback some changes and resubmit the app, everything went smooth. But none of the code I rollback look suspicious at all. In fact they aren’t. Add back the code and everything went hairwired again. In fact, during the app package comp ilation, .NET native toolchain start to fail, but I usually ignore them because they can be resolve by recompile again. In the end, I emailed .NET native team for help. This is what I get back.
We have seen similar symptoms when the compiler runs out of memory while compiling the app. Sometimes apps are on the edge, and timing around how memory is allocated is all that makes the difference between success and failure.
We have a 64 bit compiler available that can operate with more memory. Can you try to add <Use64BitCompiler>true</Use64BitCompiler> to a PropertyGroup in your main CSPROJ file?
You should be able to validate that it’s doing the right thing by enabling diagnostic build output in Visual Studio, switching build configuration to Release and building the project. In the build log, there should be a line with nutc_driver.exe in it. The nutc_driver.exe that was invoked should be in a tools64 directory (as opposed to the tools directory used by default).
Adding Use64BitCompiler is a life saver! It totally work and the app went through submission without a problem at all. Gosh, that took long enough! This is the few thing I learn:
- Windows Store will re-compile your package submitted. I never knew that, I though they just testing the package procvided.
- UWP app can grow big very quickly espcially if you use a lot of nuget libraries.
- Bad archtecture design will cause .NET native to run to limitation much quicker, such as two view model is refering each other directly.
- We really need a 64 bits Visual Studio.