Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo


#886 NSIS installers always show warning on Windows 7

2.0 Series
Amir Szekely
General (292)
Eric Lawrence

When a NSIS-installer runs on Windows 7, it will generally finish before the Win7 Program Compatibility Assistant verifies that it worked correctly. Because NSIS-installers use the old Vista manifest format, the user is prompted with an ugly "program compatibility assistant" warning after completion asking if they want to try reinstalling with different settings.

To fix this, we need to update NSIS with an updated manifest.

Microsoft says:

For windows 7, we are introducing a new application manifest support to enable apps describe the operating system they support. This will help appropriately give the compatibility modes for apps moving forward. Having this manifest will ensure turning off Program compatibility assistant in Win7.

Please see below instructions for adding this manifest, which his part of the app quality cookbook for windows 7 at http://code.msdn.microsoft.com/Windows7AppQuality under section applicaiton manifest.

Update the application manifest with the latest Compatibility information for operating system support. The section below describes the additions to the manifest:
• Name Space: Compatibility.v1 (xmlns="urn:schemas-microsoft-com:compatibility.v1">)
• Section name: CompatibilityInfo (New section)
• SupportedOS: GUID of supported operating system
The GUIDs that map to the supported operating systems are:
• {e2011457-1546-43c5-a5fe-008deee3d3f0} for Windows Vista: This is the default value for the switchback context.
• {35138b9a-5d96-4fbd-8e2d-a2440225f93a} for Windows 7: Applications that set this value in the application manifest get the Windows 7 behavior.
Microsoft will generate and post GUIDs for future Windows versions as needed.
An XML example of an updated 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">
<supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/>
<supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}"/>


  • Eric Lawrence
    Eric Lawrence

    Error message seen on Win7

  • Eric Lawrence
    Eric Lawrence

    Incidentally, I encounter this problem with the latest version of NSIS (2.44).

  • John T. Haller
    John T. Haller

    I can confirm this on NSIS 2.44. It affects Windows 7 Builds after the public Beta and will apparently affect the Release Candidate in a few weeks and the final due in October or earlier. Microsoft has details on the compatibility section of the manifest here:


    Only a single line needs to be added to the NSIS source to accommodate it. To the file manifest.cpp, after line 59 which is:

    xml += "\" uiAccess=\"false\"/></requestedPrivileges></security></trustInfo>";

    and before line 60 which is:


    add a single line as:

    xml += "<compatibility xmlns=\"urn:schemas-microsoft-com:compatibility.v1\"><application><supportedOS Id=\"{35138b9a-5d96-4fbd-8e2d-a2440225f93a}\"/> <supportedOS Id=\"{e2011457-1546-43c5-a5fe-008deee3d3f0}\"/></application></compatibility>"

    That will take care of the issue and cause all installers to show as compatible with Vista and Windows 7.

  • John T. Haller
    John T. Haller

    Additionally, I've recompiled NSIS 2.44 with the additional change and it works properly on Windows 7 Build 7077 now (which is the latest leaked build).

    Oh and I accidentally left off the trailing ; at the end of my additional line.

  • John T. Haller
    John T. Haller

    After digging a bit more, my previous patch will actually cause problems for normal installers on Windows 7. Basically, we only need to avoid the Program Compatibility Assistant when we're not doing a normal installer... a standalone installer... which in Vista is keyed to the NSIS setting: RequestExecutionLevel user

    So, I've updated the code to only include our additional features when set as such. The previous patch can be ignored. We'll now be changing the case statement instead to read:

    case exec_level_user:
    level = "asInvoker";
    xml += "<compatibility xmlns=\"urn:schemas-microsoft-com:compatibility.v1\"><application><supportedOS Id=\"{35138b9a-5d96-4fbd-8e2d-a2440225f93a}\"/> <supportedOS Id=\"{e2011457-1546-43c5-a5fe-008deee3d3f0}\"/></application></compatibility>";

    That should do it for fixing the bug right now. Later on, we may wish to delve into more complete Windows 7 support.

    You can download a compiled version of the patch here:

  • Eric Lawrence
    Eric Lawrence

    I'm not sure I understand why you'd do this only in that case?

    I'm encountering this problem for my applications which are set to

    RequestExecutionLevel admin

    not "user".


  • John T. Haller
    John T. Haller

    NSIS should work properly in Windows 7 without requiring this change provided that your app makes a change within the programs section of the registry (which shows up Add/Remove Programs). Unless the end user cancels the installation, in which case they will see the error (as they do on Vista I believe... at least for cancelled NSIS uninstallers). An admin-requiring installer that doesn't alter add/remove programs would be a different (and rarer) animal and may require deeper changes within NSIS to accomodate it.

    Technically, if you include the compatibility token, your installer is supposed to be fully Windows 7 aware and compatible. NSIS isn't to my knowledge, and may require more changes. This current patch is to fit a common need of non-admin installers so it may not be the end-all and be-all of it.

  • critternyc: You're correct on the *theory* of how registry modifications ought to work. However, per the Windows appcompat team (whom I've spoken to directly):

    "Your Setup.exe installs a single tiny dll, so it can be very fast. I believe it is updating the ARP list before PCA can make a baseline snapshot. If I take my time clicking through the install, PCA detects the changes properly. The fix here is to change the way PCA detects ARP changes. We could either block installs from starting until we finish our snapshot, or find a way to listen for changes in the registry.

    requestedExecutionLevel is the Vista indicator for PCA; NSIS needs a switchback manifest for Win7."

    The Win7 guys haven't done a snapshot change (at least for RC) and have not indicated that they plan to do so, so the best bet is to make NSIS simply use the proper manifest.

    This problem is the *only* problem I've seen with NSIS-generated installers on Win7.

  • John T. Haller
    John T. Haller

    I think the issue is that if the installer requires admin abilities, you can't just set an NSIS installer as having the compatibility token for Windows 7. If you do that, that means the installer is supposed to be smart enough to then ask Windows for admin level privs. If my patch were applied to all NSIS installers for Windows 7, they'd fail because they aren't asking for admin level privs and wouldn't then be allowed to write to Program Files or edit the add/remove programs keys.

    Like I said, my fix is a quick and dirty one for non-admin installers. And nearly all admin installers that work normally will already work properly on Win7. The exception would be admin-level installers that either don't alter add/remove programs or (apparently) those that close too quickly. For those, a more thorough rewrite of certain elements in NSIS would be required to be able to ask Windows 7 for admin abilities on the fly.

  • Eric Lawrence
    Eric Lawrence

    <<If you do that, that means the installer is supposed to be
    smart enough to then ask Windows for admin level privs.>>

    I think you might be confused about how NSIS's RequestExecutionLevel token works.

    When a manifest contains a requestedExecutionLevel of Admin, *it is* asking Windows to elevate and run it as an admin.

    And that's why NSI files that specify a RequestExecutionLevel end up writing an XML manifest to the setup program specifying the desire for requestedExecutionLevel=Admin.

    The problem here is that the manifest file format has changed between Windows Vista and Windows 7. Hence, makensis.exe needs to be updated to generate manifests in the new format to remain compatible and avoid the unneeded compatibility dialog.

    You're correct to note that indicating Win7 compatibility in the manifest is going to disable virtualization, but that's EXACTLY the behavior you want for an installer which is configured to elevate to Admin!

    (Keep in mind that specifying the RequestExecutionLevel disabled virtualization on Vista as well.)


  • John T. Haller
    John T. Haller

    Eric, you're missing how Windows 7 works now. Windows 7 ignores the requestexecutionlevel token now and instead looks for this new token. But what this new token indicates is that the installer understands that it's on Windows 7 and will act accordingly, which NSIS does not do. A Windows 7-aware installer will start at the execution level of the current context and then ask windows to elevate it to a higher level if it needs it. NSIS does not do this. If we told Windows 7 that the installer was aware when it wasn't and broke out of the PCA mold, the installer wouldn't work right.

    So, as it stands, my patch works just fine for what it is intended, to let non-admin installers work properly on Windows 7. Your example that isn't working right will require deeper changes to NSIS itself.

  • Critternyc: I should probably be a bit more explicit; I'm a program manager on the Internet Explorer team at Microsoft, and the guidance I've been providing is directly from the Windows 7 development team.

    The fix (updating to the latest manifest) is specifically recommended for NSIS by the Windows AppCompat team. You can learn more about what exactly this new manifest entails here: http://msdn.microsoft.com/en-us/library/dd371711\(VS.85).aspx

    As you can see, there is *no impact* on the requested execution level token (your statement that Win7 ignores this token is wrong) and beyond suppressing the Program Compatibility Assistant warning, the side-effects of the new manifest are extremely minor and unlikely to be at all relevant to NSIS.


  • Amir Szekely
    Amir Szekely

    • assigned_to: nobody --> kichik
    • status: open --> closed-fixed
  • Amir Szekely
    Amir Szekely

    Thanks everyone for your help and many details. I've added the manifest, changed the PE version number and updated all of the utilities' manifests too.

    Eric, please let AppCompat team know they can find me at kichik@gmail.com. There's no need for the broken phone.

  • Sorry I'm late to this conversation - but thought I would add some clarity.

    As background, I teach both Windows 7 Application Internals and Windows Installer.

    I am hitting this same frustration on two fronts - one is portableapps.com EXEs that are not installers, but are picked up by PCA. (I think this is handled by the work already described in this thread.) The other is installers that add resources (e.g. e-books) to an existing piece of software - as such they never touch the normal "install locations" and trigger PCA - but may be installing to a protected location as per the user's previous install of the software itself. Technically this may be non-compliant with data storage guidelines for Windows 7, but exists the user's choosing.

    If I understand correctly the support for switch back manifesting ("SupportedOS") is automatically compiled in if "asInvoker" is selected for an NSIS project?

    I think this should be configurable on a per NSIS project basis. It should be off by default and be able to able to be turn for a given NSIS project.

    Benefit: This would cover situations where the installer is detected by Windows (and needs to be), but does not do the normal things to make PCA happy that all went well (such as create an uninstall entry).

    Future Proofing Benefit: Also if I could specify the CONTENT of the Switchback manifesting, there would be no need for an NSIS platform update when "Windows 8" comes out. I can add the new GUID to the manifest myself and use the version of NSIS I am already on.

    Actually it would be a great option to be able to completely specify my own manifest to head this issue off for good. Could still have built-in options for those who don't want a complete override - but allow those who do to have that option. (apologies if this exists and I haven't come across it yet).

    As a side note, critternyc's description of "how an installer should work on Windows 7" is not correct for anything other than Windows Installer. Windows Installer works with UAC completely differently than any other use of UAC on version 6.x of the Microsoft Kernel (Vista, 7, Server 2008). It uses the prompt only to authorize it's built-in (since MSI version 1.0) "elevated privileges" model which has always been more restrictive than the UAC process level elevation that occurs in the rest of the platform (MSI sandboxes any custom code, admin rights only for select sections of the package AFTER the prompt, etc). It is not an expectation that all installation systems will follow a user experience like Windows Installer, but rather the setup.exe flow is perfectly acceptable for setup.exe generating tools.