I have a windows native binary (actually, a small collection of them, but one is the 'controller' for everything else), which I want to be able to put in the Windows Store. The controller needs to run elevated. They're designed to be used with an installer and a workflow which is entirely unsuited to AppContainers, so I am using the Desktop Bridge (Packaged Win32). These are old, gnarly, and definitely not rewritable in short order, so I've concluded I need to create an MSIX package and workflow which wraps the original binaries (albeit with some small adaptations). So, what I have now is a package containing:
- the binaries, arranged in the package in the same relationship as in a native installation;
- A .net intermediate process which starts the binaries elevated, intended to run full-trust;
- A UWP UI program, which starts the intermediate full-trust;
- A Service Provider, which mediates the communication between the UI and the intermediate.
When I install the package onto a machine's admin account, and run it, everything works just fine. When I install it onto a user account, it works fine provided it is also installed into an admin account on the same machine. But if it's installed only onto the user account, and not the admin account, the intermediate fails to start the controller. The error it produces is "File not found" (which, I know, could mean anything). In fact, I can install on both, run it in the user account, then delete it from the admin account, and then it fails on the user account.
The misbehaviour happens whether I side-load it onto development machines, or whether I download it from the store. It's a reliable failure, demonstrable on several different versions of W10.
A bit of mousing around shows that the file is exactly where the intermediate thinks it should be (in the installation directory in Program Files\WindowsApps), and that doesn't change whether or not the admin installation is there. Also, the access control settings are identical whether or not the admin installation is there. In fact, I can't find any difference that would tell a user whether the admin has installed it. But something is causing an error, and I have no idea where to look for it.
I want to stress: this is not a problem of the controller misbehaving in some way. The controller never even gets to run. I get to see the UAC prompt (which correctly identifies the file), and then the next thing I get is the File Not Found exception from inside Process.Start().
Has anybody experienced anything like this, or have any deeper understanding of how the different users' installations are controlled? Thanks.
EDIT: I think I've now satisfied myself that it's not a failure to find the file, it's a failure to run elevated. When the intermediate attempts to run the binary without elevation, the binary starts correctly (and then fails subsequently because of a lack of permissions for its own behaviour). Of course, there's no AUC prompt. So, what could cause a failure to elevate after the UAC prompt?
---Edit---
I've made a toy app, based on the demo at https://stefanwick.com/2018/10/07/app-elevation-samples-part-3, which demonstrates exactly the same effect. I've published it in the store, and it passed certification. I've not been able to see any way, in the store, to mark an app as unsuitable for installation by a non-admin (nor would I expect to).
I'm pretty certain now this is not a bug in my app, but is a bug in Windows. Does anybody knw how I can report it?