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:
- 32 bit executables
- Applications without a
requestedExecutionLevel
- 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 available
if (!CheckForUpdatesAvailable())
return; //no updates. We're done
//If the user is an administrator, then get the update
if (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 it
ExecuteAsAdmin(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.
