Have you built a Windows app that runs fine in development but fails in production unless launched as administrator? Operations like starting services or writing to system directories stop working under standard privileges because Windows enforces User Account Control (UAC).
If that sounds familiar, you may want to understand how the requestedExecutionLevel element in your application manifest controls process elevation and determines whether your app can run with administrative rights when necessary.
Role of Execution Level in Windows Applications
Windows uses User Account Control (UAC) to separate applications running with standard privileges from those that require administrative rights. This separation protects the system from accidental or malicious changes. Every executable that runs on Windows operates within a specific privilege level, also known as its execution level.
When an application is launched, Windows checks its manifest file to see if it includes the requestedExecutionLevel element. This element tells the system what level of access the application expects.
If the manifest requests administrative privileges, Windows prompts the user for permission before starting the process. Without this declaration, the system assumes the application should run with the same privileges as the calling process, which can cause unexpected permission errors during runtime.
Manifest Configuration and Attributes
The application manifest is an XML file that instructs Windows on how to run your program. Inside this file, the requestedExecutionLevel element defines the privilege level your executable needs.
If this setting is missing, Windows assumes the application should run with the same privileges as the process that launched it, which often causes permission issues in real-world deployments.
Here’s what the structure looks like:
<requestedExecutionLevel level="requireAdministrator" uiAccess="false" />This element accepts two attributes:
level: controls how much privilege your application requests.
- asInvoker runs with the same permissions as the parent process.
- highestAvailable requests the highest level the current user can provide.
- requireAdministrator forces elevation and always runs the app with full administrative rights.
uiAccess: determines whether your program can interact with higher-privilege interface elements such as other elevated applications. This should remain false unless your program genuinely needs to control or monitor the user interfaces of other apps.
In short, requestedExecutionLevel tells Windows what the program expects before it starts. Choosing the right level is about finding the balance between security and functionality. Too little privilege, and your app will fail when performing protected actions; too much, and it can trigger unnecessary UAC prompts that annoy users.
How UAC Interprets the Manifest
When an application starts, Windows checks the embedded manifest before launching it. The requestedExecutionLevel value in the manifest indicates to the operating system whether to run the program normally or display a UAC prompt requesting higher privileges.
If the level is set to asInvoker, Windows runs the program with the same rights as the user who opened it. This is the safest and most common setting for apps that only need user-level access.
If it is set to highestAvailable, Windows gives the process the highest privilege level available to the user. For example, if an administrator runs the program, it will start with elevated rights. If a standard user runs it, it continues with standard privileges. This mode works well for apps that can perform optional tasks requiring elevation but do not depend on it.
If the level is requireAdministrator, Windows always prompts for administrative access before launching. The user must approve the prompt or enter admin credentials. This setting is necessary for tools that manage system configurations, services, or files in protected locations.
Embedding and Verification
Adding the manifest is only half the job. For Windows to recognize it, the file must be properly embedded into your executable. In Visual Studio, this can be done through a few simple steps.
First, open your project, right-click it in Solution Explorer, and choose Add → New Item → Application Manifest File. Visual Studio will create a file named app.manifest with a default configuration that includes the line:
<requestedExecutionLevel level="asInvoker" uiAccess="false" />Change the level value according to your application’s requirements. Once you edit it, make sure the manifest is actually linked to your project. Go to Project Properties → Application → Manifest, and select the file you just created.
When you build the project, Visual Studio automatically embeds this manifest into the executable’s resources. Embedding is important because Windows only checks internal manifests by default. If the file remains external, the system might ignore it or lose the association when the program is distributed.
To confirm that the manifest is correctly embedded, you can verify it using the Windows SDK tool mt.exe or any resource viewer. Extracting and checking the manifest helps ensure that the correct privilege configuration is included before release.
Practical Scenarios
Understanding how to set the correct execution level is easier when you see how it applies to real use cases. Different types of Windows applications require different privilege levels, depending on their functionality.
For example, a service management tool that starts or stops Windows services requires administrative rights. In that case, your manifest should specify:
<requestedExecutionLevel level="requireAdministrator" uiAccess="false" />This ensures the system always prompts for elevation before running the application, allowing it to perform privileged operations successfully.
For applications that can benefit from extra access but are not strictly dependent on it, the better choice is:
<requestedExecutionLevel level="highestAvailable" uiAccess="false" />This configuration enables the program to utilize administrative rights when available, while still operating normally for standard users.
If your application is a portable launcher that extracts and runs another executable, set the execution level only in the launcher’s manifest. The privileges will automatically transfer to the main application it starts, so you do not need to configure both.
Frameworks such as .NET and Wails automatically embed manifests during compilation, but developers can still modify them before building to customize the behavior of privileges. Regardless of the framework, the same logic applies: Windows reads the manifest, interprets the requested level, and enforces it at runtime.
Wrapping Up
Avoid setting requireAdministrator unless your program truly needs full system access. Doing so unnecessarily triggers UAC prompts every time the app launches, which can frustrate users. Similarly, never set uiAccess=”true” unless your application is digitally signed and installed in a trusted directory. Without that, the system will refuse to start the program.
Another frequent oversight is relying on an external manifest file. Windows often ignores detached manifests, especially when the executable is moved or renamed. Always embed the manifest directly into the binary to ensure consistent behavior on every machine.
Ultimately, requestedExecutionLevel is more than just a configuration tag. It instructs Windows on how to handle your application during startup. Setting it correctly allows your software to request the right level of access, maintain security, and run smoothly without depending on manual elevation.