Could you add the link for the feedback hub to the store's app review form? I believe that the 'app review' and 'report for developers' should be divided.
Because - a lot of user post a bug report to the app review on the Microsoft Store.
But, In fact, most of these posts should be handled with feedback hub. By using feedback hub, we - app developers - can contact with the users to get know the detail and track the defects.
Is it possible to add the note to the review form as following?
"If you have a trouble for using this app or want to send a report to the app developer, please consider to post it to the feedback hub, instead of review. Here is a link --> [link] "

I have a disk imaging (which I have already converted) application that writes bytes directly to disk (USB and SD cards). It requires admin rights to get a lock on the disk. The app gets rejected during submission to the store as some features are disabled as admin privileges are required. It would be good if we could submit utility tools to the store as there is no way to perform these tasks without admin. Maybe warn the user when downloading the app or more stringent verification process for these apps but don't block them completely as you're hurting both devs and users. And a user will just go elsewhere to get the app and end up downloading from shady app from the web causing them to get viruses as you won't allow elevated apps in the store. So in a round about way you're actually raising the chances of users getting viruses by blocking these apps as they just get them from the web instead.

The last three days I was working hard to solve a problem, submitting our UWP app to the store. Now I know why it was not working and I want to make my knowledge public. Maybe it will help someone.

Problem:

We have an UWP app targeting Windows 10 fall creators update which was published successfully to the sore previously.
A new version fails the certification process with “10.4.2 App Crash or Freeze”
Debug build of the app is starting and working on our developer machine
Side loadable release builds are also starting and working on our build and test machines
The “.appxbundle” – package created by the “build for store” process contained in the AppPackages/AppName*version*_Test folder is also loading without troubles. (This package contains our code compiled with the native tool chain)
But the “.appxbundle” – package extracted from the *.appxupload (this is the zip-file uploaded to the store) fails at startup after it was side loaded on my test machine. (for side loading you need to install the *.cer file contained in the AppPackages/AppName*version*_Test folder to your system cert store unter trusted roots) OK. Something must be wrong with the uploaded “.appxupload ” package. WRONG! The “.appxbundle” contained in the “.appxupload ” contains the .net dlls and not the compiled code from the native tool chain. This package does always crash after side loading it. So this crash is not the problem reported by the certification process!

Now things are very complicated:

- The uploaded “.appxupload” package contains the .NET dlls which are compiled via the native tool chain on the Microsoft certification server which generates a package which fails at startup. The same build process on my developer machine with the locally installed native tool chain generates perfectly loadable builds. Unfortunately, there are no more details available from the certification process. Also Microsoft support could not help me. They build a package which fails without details and I can not download the build package for debugging. That’s bad!

- Fortunately, I have found a way to use the Microsoft certification build server to get a downloadable UWP package for debugging. I used test-flight. The test-flight certification process builds the same package internally. Fortunately, it does not try to start the build as part of the certification process. So I was able to install the test flight package on my local machine for debugging. And it crashed at startup! Yeah! Using some gflags and VS I was able to find, that the entry point for “FormatMessage” was not found.

- Entry point for “FormatMessage” not found: After some searching I found this https://github.com/AArnott/pinvoke/commit/2843cb918562050fd4e6df1f3fca0c72f4812eb4 and yes, I was using this library with the old version. The problem here was, that for some VS releases the “C:\Program Files (x86)\Windows Kits\10\App Certification Kit\SupportedAPIs-x??.xml” file contains some entry point definitions for FormatMessage which does not exist. So the native tool chain compiles against the wrong entry point which causes the app crash at startup. But why was it working on my local machine? This is because I am using Visual Studio 15.7.1 which has already fixed the problem. Unfortunately, the build infrastructure of Microsoft which is used for the UWP certification process (at least for our targeted OS version: Windows 10 falls creators update) uses the buggy version of the SupportedAPIs-x??.xml file which generates broken packages for our UWP app. After I used the latest version of PInvoke.Kernel32.dll which contains a workaround for the problem, all was fine. (If you are also using PInvoke.Kernel32.dll please install the nuget-package directly to the UWP-project, automatic references added by other nuget-packages like PCLCrypto add an older version, verify the version of PInvoke.Kernel32.dll in your bin/x86/Debug build output folder, it should be at least 0.5.147.53150)

So, in short:

- The Microsoft Build server for submitted UWP packages is using a buggy “C:\Program Files (x86)\Windows Kits\10\App Certification Kit\SupportedAPIs-x??.xml” file, which allows bindings to non-existing function entry points causing app crashes for the certification process. Local release builds created with the native toolchain of VS 15.7.1 are working. Here the SupportedAPIs-x??.xml is fixed!

è Microsoft should fix the SupportedAPIs-x??.xml for their build environment!
è Microsoft should give us the possibility, to download created app packages for failed certification processes for further debugging.
I hope this helps!

Regards,

Thomas.