App Elevation Samples – Part 1


Elevate your packaged apps with the new ‘allowElevation’ capability. With the 1809 update for Windows 10, apps can now declare this new capability in order to require elevation – or elevate themselves dynamically when needed. I will explain the new capability with three samples in this mini-series of posts:

1 – “Hello Elevated World” – simple packaged elevated desktop app (this post)
2 – Desktop app self-elevates dynamically when needed
3 – Elevated extension to a UWP application

As with all restricted capabilities, be sure to read the official Microsoft documentation regarding current policies for distribution via the Microsoft Store:

Outside of the Microsoft Store you can of course distribute your apps with any restricted capabilities.

Hello Elevated World


I already have the 1809 update and the Windows SDK 17763 (or later) installed. Just show me the code  …
Sample Code Repo on Github

Step-by-Step Tutorial

1. Create a new desktop application

Make sure you run Windows 10 with the 1809 update and have the Windows SDK 17763 (or later) installed. Now create a new C# desktop console application in Visual Studio 2017 (can be any type of desktop application really):

2. Add a few lines for testing

static void Main(string[] args)
    Console.Title = "Hello Elevated World!";
    Console.WriteLine("Press any key ...");

3. Add app manifest and require elevation

Project | Add New Item … | Application Manifest File
addManifestOpen the app.manifest file and change the requested execution level from “asInvoker” to “highestAvailable”:

<requestedExecutionLevel level="highestAvailable" uiAccess="false" />

Now verify that running the unpackaged app will run as elevated after popping up the UAC prompt (unless you have turned this off).

4. Convert to a packaged app

Add a Windows Packaging Project to the solution and call it “Package”:addPackage

Be sure to set both “Minimum” and “Target” version to 17763 or higher as build number 17763 maps to the 1809 update for Windows 10:


Reference your desktop console application from the packaging project by right-clicking on the “Application” node under the “Package” project and selecting “Add Reference …” :addRef

Now set the “Package” project as your startup project in the solutions settings:setStartup

5. Final Step: add the ‘allowElevation’ capability declaration

If you now hit F5 to run your packaged console app you will see the expected error stating that the launch failed because it requires elevation. This is the correct default behavior for packaged applications.


With the new ‘allowElevation’ capability apps can now properly disclose that they will/may request to run with elevated privileges. So let’s add this capability in Package.appxmanifest:

    <Capability Name="internetClient" />
    <rescap:Capability Name="runFullTrust" />
    <rescap:Capability Name="allowElevation" />

Hit F5 again and you will see your packaged app requesting elevated privileges and then run as elevated process:elevated

And we are done! You have now implemented your first packaged app that runs with elevated privileges. To create the actual distribution package for your application you would follow the usual steps: Select the “Package” project in solution explorer, then go to Project | Store | Create App Packages …

In the next post I will cover how a packaged app can self-elevate itself dynamically, for example to access a file that requires administrative privileges.

AllowElevation Samples Part 2 – Dynamic Self Elevation





17 thoughts on “App Elevation Samples – Part 1

  1. I am getting the elevation error even after updating the manifest file with elevation.
    In my case, i call UWP->Win32 App(C++). I did change the UAC Execuation Level in my project Linker| Manifest File| UAC Execution Level.
    Am i missing anything?


    1. Are you using FullTrustProcessLauncher to directly launch an EXE that declares itself as requiring elevation? This won’t work. You will have to do it as described in part 3 of this series, i.e. self-elevate yourself from the Win32 EXE (or launch a third process which can require elevation).


      1. In my case, i have 3rd process, so it worked, i have created the 3rd process as runas , so it elevated the process.
        I am thinking of running a single background desktop process for doing, is it possible, UWP is directly calling win32 background process that requires elevated rights?


      2. Today it’s not possible directly from the UWP. But you don’t need a third process, you can runas yourself from the Win32 background process that the UWP launches (as my sample in part 3 demonstrates).


    2. After changing ‘Enable UAC control’ to No, it worked fine.
      But I have a different question.
      My Win32 App uses other configuration files, how do i package those files in the appx files?


    1. This is a personal blog, not official Microsoft documentation. I won’t make any statements about Microsoft Store policies as those are subject to change and outside of my control. My blog posts aren’t suggesting that elevated apps would be suitable for Store submission. As with all restricted capabilities you should always refer to the official Microsoft Store documentation about current policies. I have added a note to my post along those lines. Thanks for your comment!


      1. Thank you for your reply. We also didn’t mean to imply it was because of your post that we spent the development time. It wasn’t.


  2. Hi, stefanwick! Thanks for you great article again! It help me a lot!
    My question is that, consider to Microsoft Store policies. So personal developer cann’t submit APP with Elevation capability. That’s why you don’t have sample APP in Microsoft Store, is that right?
    For me, I create a WCF service host in console app. And I have a UWP project communicate with this WCF service. There is a packaging project contains UWP APP and console APP through Desktop Extension.
    It will show UAC window and works well when I run it on Windows 10 Pro. But it always be block on Windows 10 S mode.


    1. Yes, apps with allowElevation are typically not suitable for Store distribution. Think about this way: Store users are generally non-admins. If they purchase an app/game that requires elevated privileges they wouldn’t actually be able to use it.

      For your scenario I am wondering why you even need elevation. A UWP can communicate with a Console app through other means that don’t require elevation, for example through an AppServiceConnection.


    1. For executing the elevated operation the user needs to provide credentials that have elevated privileges. So the user itself is not administrator, they will get prompted for user credentials that have administrative rights. Of course the non-elevated parst of the application will just work as normal for a standard user.


      1. Thanks Stefan for the response. We observed similar behavior as you said. Wanted to follow up with another question if you can help with if we would want to build an Application Installer for managed (MDM) devices in a non-admin scope what are the APIs or concepts that we should be looking at?

        Basically we are able to push UWP and MSI using Windows 10 CSP, but it is with the executables that we are stuck at, what we would want is when an Admin pushes an Executable app, install them silently even on non-admin users, but we are not sure how to approach this problem. We have seen applications that are able to do this and are wondering which API allows this 🙂


  3. Hello Stefan. Do you know, why this example stays in Debug mode (when running with F5) even after the console application has exited? I tried to run Visual Studio elevated itself with the same result. This, however, is not happening with a self-elevated console application that was run from UWP that was started with FullTrustProcessLauncher API (as described in part 3).


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s