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.
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 quiet.
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 hair wired again. In fact, during the app package compilation, .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 minimum problem. 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.
- If app submission still hitting error 1201, resubmit again until it success.