matthiasb
29th August 2008 10:47 UTC

Cancelling uninstaller on Vista causes a nonsensical error message
Hi,

This error message only shows up when aborting an NSIS uninstall from the Windows Vista (SP1, German) control panel. Even if I click "Cancel" on the first page. The uninstallers do fine and seem not to change the system in any way when they're cancelled.
This error is also caused by NSIS example scripts and pops up a few seconds after the uninstaller closes.
(Image in attachement)

Entries in the regestry seem to be valid and not causing the error (keys do not change when cancelling uninstall)

HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall
DisplayIcon      REG_SZ
DisplayName      REG_SZ
DisplayVersion   REG_SZ
InstallLocation  REG_SZ
ModifyPath       REG_SZ
Publisher        REG_SZ
UninstallString  REG_SZ
VersionMajor     REG_DWORD
VersionMinor     REG_DWORD

Since this is affecting every NSIS script on my system (even if their uninstall section is completely empty) and the "Nullsoft Install System" Installer itself there should be no need to post a script.

I cannot exclude the possibility that this error only shows up on my system but in case you noticed this behaviour too please post here.

(Picture in attachement is not moonlanguage)
States: "Program compatibility assistent"
"The program might not be uninstalled correctely"
"If this program wasn't uninstalled correctely, retry and use settings which are compatible with this Windows version" (doesn't make much sense in German either)
"unknown program", "unknown publisher"
- "Uninstall with recommended settings"
- "Program was uninstalled correctely"

Thanks in advance

Anders
29th August 2008 18:51 UTC

I think Vista will display that dialog if the uninstaller has a non 0 exit code. So, if this is bugging you that much, you can probably force the exit code in .onUserAbort with SetErrorLevel. This is mostly a stupid move from MS, a real installer SHOULD return non 0 when something did not complete, but I guess some crappy big name installer does not (can't deal with UAC or whatever the problem might be) so MS are helping some big guy out while screwing people doing the correct thing.

Case
30th August 2008 08:36 UTC

You can read an explanation why the dialog is shown here. You can fix it by adding RequestExecutionLevel command in the NSIS script.

matthiasb
1st September 2008 09:16 UTC

@Anders: It's not bugging me that much, I just have to write known issues in the installer specifiaction so costumers know everything works as usual.
I tried setting the error level to 0 but that doesn't solve the problem. Maybe there's really something wrong with my ModernUI script. (Although MessageBox shows up.)

!define MUI_CUSTOMFUNCTION_UNABORT un.customabort
;...
function un.customabort
MessageBox MB_OK "un.customabort"
SetErrorLevel 0
functionend

@Case: The problem is that I've already set the "RequestExecutionLevel" to admin in my scripts.

http://msdn.microsoft.com/en-us/library/bb756937.aspx
[...] If it is an uninstaller, the detection looks for whether an entry was deleted from ARP.

The manual is either misleading or actually states that I have to delete regestry keys regardless if I abort the uninstall or not.

http://msdn.microsoft.com/en-us/library/bb756937.aspx
The best option to exclude a program from PCA is to include, with the program, an application manifest with run level (either Administrator or as limited users) marking for UAC.

And that's exactly the case. Reading the manifest with the mt.exe (Microsoft (R) Manifest Tool version 5.2.3790.2075) of the uninstall.exe shows

<?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="Nullsoft.NSIS.exehead" type="win32">
  </assemblyIdentity>
  <description>Nullsoft Install System v2.39</description>
  <dependency>
    <dependentAssembly>
        <assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls"
          version="6.0.0.0" processorArchitecture="X86" publicKeyToken="6595b64144ccf1df" language="*">
        </assemblyIdentity>
    </dependentAssembly>
  </dependency>
  <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
    <security>
      <requestedPrivileges>
        <requestedExecutionLevel level="requireAdministrator" uiAccess="false"></requestedExecutionLevel>
      </requestedPrivileges>
    </security>
  </trustInfo>
</assembly>

I fail to see the problem.

Thank you for your fast help.

matthiasb
3rd September 2008 09:13 UTC

Me again,
i took a closer look at the uninstaller's error level (read: programming by permutation) and ended up trying this in the installer's ".onInit" for checking the error level.

execwait "$INSTDIR\uninstall.exe" $0
MessageBox MB_OK "returned: $0"

First i thought i was accidentally using "exec" instead of "execwait" because the MessageBox pops up immediately (showing "0") not waiting for the uninstaller to exit but then reading in the reference

4.6.2 Uninstall Section
[...] The first Delete instruction works (deleting the uninstaller), because the uninstaller is transparently copied to the system temporary directory for the uninstall.

i thought: "maybe Vista isn't expecting a 0 error level but a 1 (as it should be), which can't be returned since the first return states '0' due to the self copy mechanism".
Sadly, i didn't find any uninstaller callback firing at the right moment to change the error level to a different value to see if my assumption is right.

Can anyone confirm this behaviour or knows how NSIS uninstaller handles return values?

Anders
3rd September 2008 12:13 UTC

There is no uninstaller callback that you can use, the uninstaller will parse the commandline for the special param before any "user" code runs. This is a design problem IMHO. I'm not sure if there is a way around this. MS gets around it by using MSI, maybe we can do something like that as well by using rundll32 or something. I'll try to come up with a concept that works

matthiasb
3rd September 2008 12:55 UTC

I don't know if working on that is solving our problem.
After some further testing (yes, permutation programming again) i set the "UninstallString" in the registry to my own setup.exe, which now returned hard-coded error levels. I tried 0, 1, 2, 1604, 1602 (MSI codes) and various other numbers i found somewhere. No success.

Spying other installer's error level which don't cause PCA to show this error message (mostly MSI based), i just get "0" and "1602".

What bothers me is that PCA shouldn't even interfere since the manifest is existent (in both, installer and uninstaller) and requesting an execution level.

Every clue we found seems to lead toward "New Windows Vista Bug".

As said in post #4: All i want to know is why it happens. Fixing that issue would be great but has less priority and is in no way urgent.

Thanks again for the fast reply.

Comperio
4th September 2008 04:39 UTC

What I got from Case's link (from a previous post) is that the dialog will appear during uninstall if the program's entry under add/remove program is not properly deleted:

The logic used by PCA is to detect if a setup did not complete successfully. It monitors a program detected as setup by Windows Vista and Windows Server 2008 and checks whether the program registers an entry in Add or Remove Programs (ARP). If no entries are created in ARP, PCA concludes that the installer did not complete successfully. It will then wait for the install program to terminate before displaying the UI. If it is an uninstaller, the detection looks for whether an entry was deleted from ARP.

So, if the user is canceling and nothing is being changed in the add/remove programs section of the registry, then it makes sense to me that you'd see the error.

matthiasb
4th September 2008 07:00 UTC

@Comperio
I mentioned that in post #4. Still, since a manifest is present PCA shouldn't interfere at all. I was able to prevent the error message like the paragraph said if there wasn't this little nuisance:

http://msdn.microsoft.com/en-us/library/bb756937.aspx
[...], the detection looks for whether an entry* was deleted from ARP.

* 'Entry' doesn't mean any value in the ARP regestry uninstall section, but the complete key, including every value set in the ARP subkey. The MSDN manual is misleading, the right way to put this would be:

[...], the detection looks for whether THE entry was deleted from ARP.

In other words: A regular uninstall.

Comperio
4th September 2008 15:54 UTC

You right, it is confusing... (I had to re-read it again just to make sure I understood.)

So based on the information here, I'd say that either this is a bug in MS or it's just treating NSIS "special". (The article is a bit vague about the special algorithm that it uses--either that means it's top secret or that no one at MS really understands it either...)

Sorry I couldn't be more help. :(

Anders
5th September 2008 05:52 UTC

Maybe you could post on the MSDN forums and get a "official" response?

matthiasb
12th September 2008 10:20 UTC

Originally posted by Anders
Maybe you could post on the MSDN forums and get a "official" response?

Done: http://forums.microsoft.com/MSDN/Sho...63624&SiteID=1

blaaaaaaap
19th March 2009 23:28 UTC

This appears to be a Windows Vista bug. The same thing happens on my machine when canceling Google app uninstalls (e.g. Chrome or Talk).

InnoSetup users ran into the same problem and developers added a workaround (would have to browse CVS to see what this is exactly) in 5.2.3 (http://www.softpedia.com/get/Authori...no-Setup.shtml):

"Added workaround for bug in Windows Vista (still present in SP1): With UAC turned off, launching an uninstaller from the Programs and Features Control Panel applet and answering No at the confirmation message box would cause a "This program might not have uninstalled correctly" dialog to be displayed, even though the uninstaller includes a proper "Vista-aware" manifest."

Anders
20th March 2009 10:58 UTC

blaaaaaaap, thanks for the info.

Inno sets the Image Version in the PE header to 6.0 (compile.pas)

I'll add a bug fix request...

Comm@nder21
22nd March 2009 01:51 UTC

just researched on the same issue :)

here's my new wiki page:
http://nsis.sourceforge.net/Vista_ap..._compatibility

feel free to improve!