Installer manifest embedding problems - windows

I have my own installer application. In order to elevate permissions to admin I have this RC file:
2 ICON "icon.ico"
1 RT_MANIFEST "setup.exe.manifest"
And following manifest:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
<application>
<!--This Id value indicates the application supports Windows Vista functionality -->
<supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}"/>
<!--This Id value indicates the application supports Windows 7 functionality-->
<supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/>
<!--This Id value indicates the application supports Windows 8 functionality-->
<supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}"/>
<!--This Id value indicates the application supports Windows 8.1 functionality-->
<supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}"/>
<!--The ID below indicates application support for Windows 10 -->
<supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}"/>
</application>
</compatibility>
<asmv3:trustInfo xmlns:asmv3="urn:schemas-microsoft-com:asm.v3">
<asmv3:security>
<asmv3:requestedPrivileges>
<asmv3:requestedExecutionLevel level="requireAdministrator" uiAccess="false" />
</asmv3:requestedPrivileges>
</asmv3:security>
</asmv3:trustInfo>
</assembly>
The installer is compiled using MSVC 2017, then I append the actual data to install to the setup.exe file. I assume the beginning of the EXE file contains info about its original length, so system can read anything it needs and won't actually touch appended data. The icon is displayed correctly, so I assume things are working fine.
But I have 2 problems:
On some computers (which unfortunately I don't have, I only have reports) the OS doesn't seem to actually elevate the permissions and the installer fails to write some files.
On many computers after the installer ends the system displays the famous "This software hasn't been installed correctly..." window.
Any ideas what I'm doing wrong?
Edit: If the installer is then "run as administrator" via right-click menu, it finishes without problems.
Edit2: The installer is also signed and the signature is correctly read by Windows.

Apparently embedding it as resource like this just doesn't work. One can use this command to verify the manifest:
mt.exe -inputresource:blablabla.exe;#1 -out:extracted.manifest
But it works when used directly from the Linker / Manifest file page inside MSVC, without an actual manifest file, it generates some itself.

Related

How to use manifest to control disable DPI scaling and compatibility

I have a manifest file and use the mt command in makefile to add it into one of my exe files. After it's installed. If I use DPI Awareness Enabler or check the registry in HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers, it does NOT show anything interesting. Normally if I manually set Compatibility to Windows 7 and disable DPI scaling in file property, it would show up in DPI Awareness Enabler and the registry.
So am I right to assume register is linked only to GUI not the actual file? As if I use mt command to extract manifest file from exe, I can see my original manifest file.
Above all, I don't think my manifest file works as expected. The way I test it is to reproduce a bug in the app. The workaround is set Compatibility to Windows 7 and disable DPI scaling in file property. If I just use the installed file even with manifest file embeded, it doesn't solve the problem. But if I manually change it in property, it solves the bug.
Some extra information, the app is built with VS2010 with hotfix to fix the manifest warning. Not sure if that is the cause.
Any help would be appreciated.
Here is the manifest file
<?xml version="1.0" encoding="UTF-8"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" xmlns:asmv3="urn:schemas-microsoft-com:asm.v3" manifestVersion="1.0">
<compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
<application>
<!-- Windows 7 -->
<supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}" />
</application>
</compatibility>
<asmv3:application>
<asmv3:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">
<dpiAware>true</dpiAware>
</asmv3:windowsSettings>
</asmv3:application>
</assembly>
Here is the part in Makefile
ADD_CUSTOM_COMMAND(
TARGET myExe
POST_BUILD
COMMAND "mt.exe" -manifest \"${CMAKE_SOURCE_DIR}\\res\\dpiaware.manifest\" -inputresource:\"$<TARGET_FILE:myExe>\"\;\#1 -outputresource:\"$<TARGET_FILE:myExe>\"\;\#1
COMMENT "Adding display aware manifest..."
)
Ok, I finally give up on the manifest solution. Just so happen we use wix. So I add some registry values to HKLM->SOFTWARE->Microsoft->Windows NT->CurrentVersion->AppCompatFlags->Layers during installation.

Windows application toolkit fails to remove UAC prompt on specific program

OS: Windows 7 Professional 64 bit
My Arduino IDE fails to open unless I "Run as administrator". If I don't,It will just show the loading screen:
but will not actually open up the IDE. I have been searching for ways that I could bypass this just for arduino.exe and have found that this could be done with Windows Application Compatibility toolkit as outlined here.
When I get to the test run part after checking runasinvoker as shown here:
(source: meridian.ws)
Arduino started with no issues. But after I follow the rest of the steps and install the fix, my Arduino IDE program still has the same problem. If I do not run it as administrator, it will just show the loading splash screen and not the IDE part.
Please help! Thanks!
If this program does not support running as a standard user, you will not be able to fix that. The developers of the application need to fix it so that it runs correctly as a standard user.
People are confused by the UAC. Try running the same application on Windows XP.
It's possible that File and Registry Redirection is causing an issue, but i doubt it. You can disable File and Registry Redirection by adding an assembly manifest that includes the runas invoker section:
Arduino.exe.manifest:
<?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="client"
type="win32"
/>
<description>Don't Arguino With Me</description>
<!-- Disable Windows Vista UAC compatability heuristics -->
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
<security>
<requestedPrivileges>
<requestedExecutionLevel level="asInvoker"/>
</requestedPrivileges>
</security>
</trustInfo>
</assembly>
and place arduino.exe.manifest in the same folder as arduino.exe.
Note: Windows will only read an external assembly manifest file if there isn't already an assembly manifest resource inside the application. I doubt there already is one.
Best guess: this application must be run as an administrator, and that's the end of it (until they fix it)

Manifest being ignored in mingw app

I have an old-fashioned Windows GDI application, written in C, which is being compiled with the Mingw toolchain.
Some of my users have been complaining about Windows Vista and Windows 7's Virtual Store, where files which are written to directories the app shouldn't have access to are siphoned off and stored elsewhere. They say it's confusing them, and they'd much rather have an error. According to Microsoft's documentation, the way to prevent this from happening is to add an application manifest.
Unfortunately this doesn't seem to do anything.
My manifest is:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<description>WordGrinder</description>
<assemblyIdentity version="1.0.0.0" name="WordGrinder"/>
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
<security>
<requestedPrivileges>
<requestedExecutionLevel
level="asInvoker"
uiAccess="false"/>
</requestedPrivileges>
</security>
</trustInfo>
</assembly>
...and the resource file which refers to it is:
CREATEPROCESS_MANIFEST_RESOURCE_ID RT_MANIFEST "src/c/arch/win32/manifest.xml"
101 ICON DISCARDABLE "src/c/arch/win32/icon.ico"
(Not complicated, as you can see.) The resource file is compiled with windres and linked to my application in the usual way. The icon shows up, so I'm confident that this bit, at least, is correct.
Is there anything else I need to be doing to have the manifest be honoured?
Solved: I was missing this line from the resource file:
#include "winuser.h"
Without it, you don't get any diagnostics or indication that it hasn't worked; you just don't get a manifest. Sigh.
I figured this out using the manifest extraction tool here: http://weblogs.asp.net/kennykerr/archive/2007/07/10/manifest-view-1-0.aspx

Running .exe with a .manifest file causes a "...did not install correctly" dialog. Why?

I'm trying to get a VB app (my.exe) to run as Administrator on Windows 7. So I'm using a Manifest (below) to do that. But when I run it (and immediately exit the My.exe) I get the Program Compatibility Assistant warning:
"This program might not have installed correctly"
Of course, I am not doing any installing.
If I set the EXE to Run As Administrator (by right-clicking My.exe ) then I do not get this warning (with or without the manifest present)
or
If I remove the manifest file (and set exe to run as admin or do not do that) I do not get the warning.
Any ideas why this is happening and how to NOT get this warning using the Manifest?
MANIFEST
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<!-- Make My Manifest 0.7.300 -->
<assemblyIdentity name="Bungalow.Software,.Inc..CDCodes" processorArchitecture="X86" type="win32" version="10.0.0.16" />
<description>Internal BSW program to generation installation and actvation codes</description>
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
<security>
<requestedPrivileges>
<**requestedExecutionLevel level="requireAdministrator" uiAccess="false"** />
</requestedPrivileges>
</security>
</trustInfo>
</assembly>
Try adding a compatibility section in your manifest.
Your manifest says "I am an admin app; I change this computer" but when it has finished running, the registry is unchanged, program files is unchanged, etc. So Windows wonders to itself -is everything ok? And then it asks you.

How do I deploy applications in run as administrator mode?

How Do I deploy applications so that they require administrator rights without the end-user doing that by hand?
I use Delphi 2009 to build the application.
You can inform Windows that your application needs to run as an administrator by using the requestedExecutionLevel element in your application manifest.
The manifest file is an XML file that looks as follows. It should be named YourApp.exe.manifest and placed in the same folder as the executable. (It can also be embedded in the resources of your application; it must have a resource type of RT_MANIFEST and an ID of 1.)
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity version="1.0.0.0" processorArchitecture="X86" name="YourApp" type="win32"/>
<description>Description of your application</description>
<!-- Identify the application security requirements. -->
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
<security>
<requestedPrivileges>
<requestedExecutionLevel level="requireAdministrator" uiAccess="false"/>
</requestedPrivileges>
</security>
</trustInfo>
</assembly>
For further details on application manifests and how to create them, see Create and Embed an Application Manifest (UAC) at MSDN.
Note that the manifest is only respected by Windows Vista and later. If your user is running as a standard user on Windows XP, your application will not be launched as an administrator; you may need to write code to detect this if it will be a problem for your application.
Another option, although not recommended for "every day applications", is to name your executable with "Install" or "Setup" as part of the name. Keep in mind that if you don't change any registry settings, or create any new files then windows will display a warning to the user that the program might not have run properly.

Resources