You are almost certainly hitting a Windows Installer Detection Technology^🕗 compatibility heuristic. Windows will try to detect when an application is an installer, and probably needs to be elevated.

Installer Detection only applies to:

1. 32 bit executables
2. Applications without a requestedExecutionLevel
3. Interactive processes running as a Standard User with LUA enabled

Before a 32 bit process is created, the following attributes are checked to determine whether it is an installer:

• Filename includes keywords like "install," "setup," "update," etc.
• Keywords in the following Versioning Resource fields: Vendor, Company Name, Product Name, File Description, Original Filename, Internal Name, and Export Name.
• Keywords in the side-by-side manifest embedded in the executable.
• Keywords in specific StringTable entries linked in the executable.
• Key attributes in the RC data linked in the executable.
• Targeted sequences of bytes within the executable.

So, as you said:

but i have a exe which checks for updates to software

My guess is that this CheckForUpdates.exe is triggering the compatibility heuristics.

The correct thing to do is to add an assembly manifest to your "checking" executable, informing Windows that it should not elevate the utility. This is done with a requestedExecutionLevel of asInvoker in the manifest:

AssemblyManifest.xml:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?><assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">    <assemblyIdentity       version="1.0.0.0"      processorArchitecture="X86"      name="ITReasearchAssociates.Contoso.Updater"      type="win32"   />    <description>Update checker</description>    <!-- Run as standard user. Disable file and registry virtualization -->   <trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">      <security>         <requestedPrivileges>            <requestedExecutionLevel level="asInvoker" uiAccess="false"/>         </requestedPrivileges>      </security>   </trustInfo></assembly>

That way your "Check For Updates" application will never elevate, and never mistakenly gain administrative privileges.

If you want your updater to actually apply updates (updates which require administrative privileges), then you would launch your updater application as an administrator.

Sample Code

//Check if there are updates availableif (!CheckForUpdatesAvailable())   return; //no updates. We're done//If the user is an administrator, then get the updateif (IsUserAnAdmin()){    //Maybe throw in a "Hey, user, wanna get the update now?" dialog    DownloadAndApplyUpdates();    return;}//The user is not an admin. //Relaunch ourselves as administrator so we can download the update//Maybe throw in a "Hey, user, wanna get the update now?" dialog. A button with a UAC shield on itExecuteAsAdmin(Application.ExecutablePath, "/downloadUpdate");

with the helper functions:

private Boolean IsUserAnAdmin(){    //Public domain: no attribution required    //A user can be a member of the Administrator group, and yet not be an administrator.    //Conversely, the user can be an administrator while not being a member of the administrators group.    var identity = WindowsIdentity.GetCurrent();    return (null != identity && new WindowsPrincipal(identity).IsInRole(WindowsBuiltInRole.Administrator));}private void ExecuteAsAdmin(string Filename, string Arguments){    //Public domain: no attribution required    ProcessStartInfo startInfo = new ProcessStartInfo(Filename, Arguments);    startInfo.Verb = "runas";    System.Diagnostics.Process.Start(startInfo);}

Then on startup you just need to look for the /downloadUpdate command-line parameter to know that you're job is to actually do work:

public Form1(){    InitializeComponent();    //Ideally this would be in program.cs, before the call to Application.Run()    //But that would require me to refactor code out of the Form file, which is overkill for a demo    if (FindCmdLineSwitch("downloadUpdate", true))    {        DownloadAndApplyUpdates();        Environment.Exit(0);    }}

Note: Any code is released into the public domain. No attribution required.

Your programs probably lack application manifests that mark them as non-legacy. As a result Windows will apply scripted installer detection heuristics to decide whether your program is an installer. This is pretty much the only way an "unexpected" UAC prompt gets raised.

These heuristics include keyword searches within the EXE file name and several of the extended properties of the EXE, and may even look for well-known binary signatures (i.e. byte strings) inside the file.

BTW, your crypto-signing doesn't enter into this at all. And it doesn't help a thing if it wasn't issued by a trusted CA.

For that matter anyone who trusts code just because Windows reports the commpany name on the UAC prompt is a fool. Malware authors steal these all the time, and for that matter they are trivial to obtain and almost never reported by users when crap programs cause problems. Save your money, code signing certs are a failed concept.

Someone can specify in the configuration of the exe that this file needs to be executed with higher Privileges.

How to request Admin Privileges

I don't know what this update is for, but I'd suggest that it needs to update a component like a service, or some files that are located in the ProgramFiles-Dir. Therefore it needs Admin Privileges.