UWP Submission Error 1201 and Weird Certification Crash

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.


UWP App Manifest Resources Tests Failed The Size Restrictions

Another day another random error hit. Today I try to submit an update for my UWP app to Windows store. I submitted countless number of update previously and never encounter any error especially I always run the Windows App Cert Kit locally before submitting my app as precaution. Everything work great exception app certification failed with the following message:

  • Image reference “Resources\Images\Logos\store_logo.png”: The image “s:\t\7E7C79\appcert_2A0C\7463Ooiks.Bugko-MTGTool_5.8.8.0_neutral_split.scale-100_t9y74dhqw19zm\Resources\Images\Logos\square_71x71_logo.scale-100.png” failed the size restrictions of 50 X 50.
  • Image reference “Resources\Images\Logos\store_logo.png”: The image “s:\t\7E7C79\appcert_2A0C\7463Ooiks.Bugko-MTGTool_5.8.8.0_neutral_split.scale-125_t9y74dhqw19zm\Resources\Images\Logos\square_71x71_logo.scale-125.png” failed the size restrictions of 62 X 62.
  • Image reference “Resources\Images\Logos\store_logo.png”: The image “s:\t\7E7C79\appcert_2A0C\7463Ooiks.Bugko-MTGTool_5.8.8.0_neutral_split.scale-150_t9y74dhqw19zm\Resources\Images\Logos\square_71x71_logo.scale-150.png” failed the size restrictions of 75 X 75.
  • Image reference “Resources\Images\Logos\store_logo.png”: The image “s:\t\7E7C79\appcert_2A0C\7463Ooiks.Bugko-MTGTool_5.8.8.0_neutral_split.scale-400_t9y74dhqw19zm\Resources\Images\Logos\square_71x71_logo.scale-400.png” failed the size restrictions of 200 X 200.

Continue reading UWP App Manifest Resources Tests Failed The Size Restrictions

Android App Crash & Reboot OS / Phone

I’m been spending a whole weekend trying to hunt down a crash reported by one of my user who is running Samsung J3 on Android Oreo 8.1. The app launch then crash. It also bring down the whole Android OS and rebooted the phone. This is very unusual and because app crash normally won’t bring down the whole OS.

No crash report recorded on App Center (crash analytical tool I used) or Google Play Console which is understandable because whole OS is down). This make the debugging almost impossible since I cannot duplicate this on my phone nor emulator I tried. Since only 1 user reported, I suspect this is very much a isolated case.

After some deep search on the internet. It seem like Samsung Android phone have this cache partition that help app launch faster by caching some data in it. Some time it will become corrupted and causing random problem. Since wiping the cache partition doesn’t wipe any of the user data, I tell my user to give it a try. It work!

Here are the post on how to wipe the cache partition: https://us.community.samsung.com/t5/Phones/How-to-wipe-the-Cache-Partition-on-your-phone-or-tablet/td-p/12662

Xamarin UITest Finished Immediately After Run

I’m trying to rerun a few Xamarin UITest that I created a few months ago in Visual Studio 2017 on Android. As expected, they all failed, but not because of the test is outdated, but the tool is broken.

First thing I discovered that the test finished immediately once it started.

========= Run test finished: 0 run (0:00:00.5110016) ==========

After some search online, new version of Visual Studio messed the test tool by adding something new. To revert the changes that affect this, go to Tools > Options > Test > General > Active Solution then uncheck “For improved performance, only use test adapters in test assembly folder or as specified in runsettings file.

I have no idea why, but this solution is provide here: https://forums.xamarin.com/discussion/140234/what-causes-ui-tests-to-run-without-getting-a-pass-or-fail

You should also turn change the logging level to diagnostic because you properly need that later.

Everything should be smoonth now, but the test failed immediately with the following information (not error).

The running adb server is incompatible with the Android SDK version in use by UITest

Instead of messing with the platform-tools folder by downgrading adb version suggested by many. The actual solution is pretty simple, open the Android SDK, and delete any folder with platform-tools.oldXXXXXXXX (those X are number).

Source: https://stackoverflow.com/questions/52254881/cannot-run-xamarin-ui-test-on-xamarin-forms-error-system-exception

While switching back to Visual Studio Mac try to run the UITest on iOS simulator, I hitted with another problem. The iOS emulator failed to launch and no output is given. In turn out the old Xamarin.UITest version 2.2.6 I used is not compatible with XCode 10, by upgrading it to version 2.2.7. It run smooth again.

Gosh, so many trouble.

UnsatisfiedLinkError in Android 8.0

I received quite a number of crash reported in my Xamarin.Android app reported in Play Console with the following stack trace:

  at mono.android.Runtime.register (Native Method)
  at md5dd7a5194eb3bf67181b6a5c267c0f7e7.PushNotificationMessagingService. (PushNotificationMessagingService.java:15)
  at java.lang.Class.newInstance (Native Method)
  at android.app.ActivityThread.handleCreateService (ActivityThread.java:3470)
  at android.app.ActivityThread.-wrap4 (Unknown Source)
  at android.app.ActivityThread$H.handleMessage (ActivityThread.java:1748)
  at android.os.Handler.dispatchMessage (Handler.java:108)
  at android.os.Looper.loop (Looper.java:206)
  at android.app.ActivityThread.main (ActivityThread.java:6733)
  at java.lang.reflect.Method.invoke (Native Method)
  at com.android.internal.os.Zygote$MethodAndArgsCaller.run (Zygote.java:240)
  at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:845)


I have no idea what crashed. The only thing it point to is the push notification services in the app with no additional information. They happen on Android 8.0 and above devices only. Android 8.0 above doesn’t required any special permission to receive notification. No similar crash reported in App Center (I use App Center as my crash reporting tool). Search online doesn’t return me anything meaningful. So I just ignore the error since no user complain anything to me.

Then today I found out that Android 8.0 and above required channel id when showing notification else it will crash in the background. Oh, snap, this is the problem! If you have simiar crash stack trace, this is probably the answer: https://blog.xamarin.com/android-oreo-notification-channels/

Failed to Launch Android Device Monitor

Every time I reformatted my machine and reinstall back Android Studio / Visual Studio. There are always some components in Android development tools are broken. It work perfectly previous, but now it doesn’t work on new freshly installed machine. It is always a new problem. This is annoying.

When I launch Android Device Monitor from Visual Studio 2017 or launch the android device monitor manually from executable. The following error pop up.

Failed to load the JNI shared library “C:\Program Files\Java\jdk1.8.0_181\bin\..\jre\bin\server\jvm.dll”

Depend on your installed JDK version, the error message might be different.

This is because Visual Studio tried to launch the x86 version of Android Device Monitor, while my machine only have x64 Java SDK / JDK installed, so it complain that. Unlike previous Visual Studio which install x86 JDK, all new Visual Studio now come with x64 JDK only.

Continue reading Failed to Launch Android Device Monitor

Connecting Bluetooth Mouse in Windows 10 on Macbook Pro

Connecting a bluetooth mouse in Windows should be a fairly easy and strait forward thing. Thing can get complicated fast when Windows is running on Macbook / Mac device or you previously tried reformat the Windows running on Macbook / Mac device. You may find that your bluetooth mouse no longer able to connect to Windows after that.

If you face the same problem like bluetooth mouse keep on connect and disconnect in Windows running on Macbook, try reset the NVRAM on Macbook. It basically remove and “forget” all connected devices, so you can connect them again. This will make MacOS running on the same device forget the all bluetooth device as well. You will need to manually connect all again.

You might want to turn off energy saving on bluetooth mouse in Windows 10 as well to prevent it keep on disconnecting the mouse. So much trouble to just get a bluetooth mouse working as usual.

How to Switch to New FreshCoat Layout for MouseHunt

The latest MouseHunt AutoBot script (version 2.04) only work on the new layout of MouseHunt. If you are running on old layout, the script will hang after sounding the horn. I will fix them in future, but currently the only way to make sure the script run without problem is use the new layout. Here is how you can do it:

First, go to Help > User Preferences


Continue reading How to Switch to New FreshCoat Layout for MouseHunt

MouseHunt AutoBot 2.05 Update

I’m back in the game, it has been a while since I left the game. Enjoying the Chinese New Year event and Winter Olympic event (also server down event).  Here are some quick update what is in the latest update.

  • Do no disturb time. (Help avoid warning sound when you sleep. Sleep is important)
  • Cheese zero warning.
  • Stop warning sound when king reward is resolved.
  • Clean up a bunch old code.


Continue reading MouseHunt AutoBot 2.05 Update