0

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?

Peter Torr - MSFT
  • 11,824
  • 3
  • 18
  • 51
Jules May
  • 753
  • 2
  • 10
  • 18
  • Hi Jules, this may be related to the administrator rights during the application installation process. Have you checked the installation directory of the application and the controller file is missing? – Richard Zhang Nov 14 '19 at 02:11
  • @RichardZhang-MSFT The installation directory is exactly where you'd expect a UWP app to install: \Program Files\WindowsApps\ – Jules May Nov 14 '19 at 09:47
  • Unsure what you mean about "administrator rights during the application installation process" - I thought that installing a UWP app was reserved to TrustedInstaller (not even an administrator). In any case, it doesn't matter what order I install or uninstall the app in the user and admin accounts: it is the absence of the admin account's installation which causes the user's account to error. I can install to both user and admin (and everything works) then uninstall it from the admin account, and (without touching the user's installation) the user's account then generates the error. – Jules May Nov 14 '19 at 09:49
  • My guess is that since MSIX apps are *registered* per-user, something is missing when the admin account tries to run the process. File Not Found is probably just what gets bubbled up through the layers. – Peter Torr - MSFT Dec 10 '19 at 05:02
  • @PeterTorr-MSFT When the admin account tries to run the process, it works. When the non-admin account tries to run the process, it works only if it's already installed on an admin account, otherwise it fails. The issue is: the admin user's installation status (installed or not) affects whether it will run on the non-admin user's account. Since MSIX apps are supposed to be registered per-user, I found this behaviour mystifying. (Kudos to the tester who found it, BTW!) I agree: File Not Found is probably not what actually happened. :-) – Jules May Jan 07 '20 at 19:52
  • We're saying the same thing :-). The admin account doesn't have the package registered. Note this issue has been filed internally. – Peter Torr - MSFT Jan 07 '20 at 19:59

1 Answers1

1

Sorry for my late response. I got in touch with the engineering team. We need you to use Process Monitor to capture some data for us to analyze.

Here is the steps:

You will need to collect logs from bad (Active Batch launch fail) and good scenario (Active Batch launch successfully)

Imgur

  • Choose Filter -> Filter…, and then click Reset, then click Apply, then OK.

Imgur

  • Click the Capture icon in the toolbar (The red cross over the icon will disappear)

Imgur

  • And now you should be able to see events shown in the software like the following, it means that the tool begins to capture events in the system, from now, please reproduce the issue as soon as possible, otherwise the logs will be large size.

Imgur

  • Launch the application Active Batch, until the dll missing error message shown. Then stop event capture by clicking the Capture icon again.

  • Ensure to save out all the events to a .pml file and exit the process monitor tool.

Imgur

  • Repeat the above process for a good scenario.

If you have captured the data, please share it with us, we can help you analyze the data and see the cause of the problem.

Best regards.

Richard Zhang
  • 7,523
  • 1
  • 7
  • 13
  • Hi, Richard. Thanks for the response. I have downloaded Procmon and it's working fine. But, can I ask: - When I start capturing, it records a lot of events - I'm getting 120,000 before I can even exercise my test. Is this as you'd expect? - You mention "Active Batch" several times. I'm not using Active Batch at all. I've got a toy program demonstrating the problem (and it's in the store if you'd like to explore it - I can provide a link); Is that what you'd like me to run? - How would you like me to get the recordings to you? (They're far too big to post on here!) – Jules May Dec 13 '19 at 20:38
  • Hi, you can upload the log file to GitHub, share the link here, and then tell us your **process name** and we will analyze it (P.S. Please make sure the uploaded log does not contain any sensitive personal information) – Richard Zhang Dec 16 '19 at 01:59
  • Hi, Richard. You can see some logs at https://github.com/julescmay/ElevationTestLogs, but in light of Peter's comments above, you may not need them. – Jules May Jan 08 '20 at 15:39
  • Hi Jules, we have received your log files. We will analyze the data as soon as possible, please provide your process name, it will help us analyze your process information – Richard Zhang Jan 09 '20 at 09:01
  • Sorry - I missed that off the readme. The UWP process is called ElevationTest, and the task which tries to elevate itself is ElevatedExtension. – Jules May Jan 09 '20 at 12:43
  • Ok, got it. We will analyze the data as soon as possible, and if there are new developments, I will post here. – Richard Zhang Jan 10 '20 at 01:04
  • Hi, we are still analyzing your data. Can you provide detailed error information or screenshots of application errors? – Richard Zhang Jan 10 '20 at 06:00
  • I've uploaded a screenshot to the GitHub repo, but there's not a lot to see - just the dialog reporting the error. I've uploaded the source code too, so you can compile and test it for yourself: the dialog is being triggered at ElevatedExtension/program.cs:23 – Jules May Jan 10 '20 at 12:15
  • Thank you for the information, I'm communicating with the engineer, if there have news I will post here. Judging from the analysis results of Log, no obvious problems have been found. – Richard Zhang Jan 13 '20 at 07:03
  • Hi @JulesMay , As Peter said, the issue has been dealt with in an internal process, you can contact Peter for the progress – Richard Zhang Feb 17 '20 at 07:17