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 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).

-Michal

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.