Extremely slow installer startup on Vista

Has anyone tested the test installer on Win7 RC1? I just did on a fresh install of the 64-bit version, and although it was not *instantaneous*, it only took about 10 seconds to appear. That is WAY quicker than Vista x86, and should be quite acceptable.

Of course, this COULD be due to the 64-bit version reacting diferently to 32-bit executables - I can't say this for certain, as I don't have the 32-bit RC installed.

I might download the 32-bit RC and set up a VM for testing, if no one else has it installed already - if the problem is indeed fixed for Win7, then changing the manifest should be quite managable.

AOL installer

Hi There,

Not sure if my problem is the same as what you are talking about. I am no where near as tech savvy as you guys but i cannot install AOL software (9.1 or BETA) from aol's download page. It gets to my desktop but when i double click...nothing. I have contacted AOL and my ISP. I have uninstalled my security software. I have tried everything that i know and still nothing. When I click run as, I then get an error message NSIS error eror launching installer. Any advice?

@GaryandDonnaM: probably http://nsis.sourceforge.net/Why_do_I_get_NSIS_Error and not related to this thread

OK, I've spent the past 3 or 4 days trying to get NSIS built. I've come to the conclusion that there's a magic combination that isn't documented well enough.

(Assume Python 2.6.2 and SCons 1.2.0.d20090223 below, unless noted otherwise.)

Build box #1: Vista 64-bit + Python (64-bit) = SCons can't find Python
Build box #2: XP SP 3 + Python + SCons + VS 2008 (no SP) = SCons "Couldn't find a good version of libcp.lib"
Build box #3: XP SP 2 + Python + SCons + VC++ 2005 Express (no SP) = can't find windows.h
Build box #3(a): Above + WSDK 6.0 = same as box #2
Build box #4: XP SP 3 + Python + SCons + Mingw = same as #2 (WTF? I even modified the SConscript to try to force mingw...)
Build box #5: Linux + Python 2.4.4 + SCons + Mingw = Contrib/MakeLangId/MakeLangId.cpp:1:21: windows.h: No such file or directory

So, yeah. I can't come up with a patch for others to apply, since I can't build the result myself, to test it. But, to answer Xutzl's request: just modify the manifest to have anything different as <assemblyIdentity name="">. I added to the end of it, and got the results I mentioned earlier in this thread. But, I can't verify this is a general fix or just a random behavior on the two test machines that I've tested on (large binary to be tossing around, after all), due to not being able to get NSIS built.

If someone monitoring this thread can get NSIS built, the change to be made is in Source/manifest.cpp on line 31. Just change "Nullsoft.NSIS.exehead" to anything else, and try building and running the script I included earlier in this thread with the resultant MakeNSIS. You should get approximately the same speed launching the installer on XP and Vista.

I can't confirm that this is a NSIS specific issue, but I can confirm the copy to %windir%\temp (not %temp%)

The code I used:

!define APPNAME "Test of Slow Installers2"

RequestExecutionLevel admin

CRCCheck off

XPStyle on

SetCompress Off

Name "${APPNAME}"

Caption "${APPNAME}"

OutFile "${APPNAME}.exe"

InstallDir "$PROGRAMFILES\${APPNAME}"

VIProductVersion 0.1.2.3

VIAddVersionKey "ProductAppName" "${APPNAME}"

VIAddVersionKey "FileDescription" "http://forums.winamp.com/showthread.php?s=&threadid=305783"

page directory

page instfiles

Section "This is a LOT of files..."

  SetShellVarContext all

  File 1gigfile

 /* DetailPrint "Creating Uninstaller..."

  WriteUninstaller "Uninstall.exe"

  CreateShortCut "$SMPROGRAMS\${APPNAME}\Uninstall.lnk" "$INSTDIR\uninstall.exe"

SectionEnd

Section "Uninstall"

  SetShellVarContext all

  RMDir /R "$INSTDIR"

  Delete "$SMPROGRAMS\${APPNAME}\Uninstall.lnk"*/

SectionEnd

you can comment out the large file, the problem still exists, its just so fast that you don't notice

The reason I say its not nsis specific is, it still happens if I rename things in the manifest (there is one NSIS string in the internal header that I did not change so it COULD still be nsis specific, one would have to recompile with a different name to make sure)

now for some pics:

changed strings:


service file copy:


consent.exe scanning for? (ignore the different temp name)


..and we are up and running (the "real" exe, not the copy):




WHY it's doing this, I don't know, but I would _guess_ its one of the services starting with "Application" seen here

Originally posted by Anders
you can comment out the large file, the problem still exists, its just so fast that you don't notice

I probably should have made it clearer that it still happens with every installer, but that it's only noticeable with large ones.

The reason I say its not nsis specific is, it still happens if I rename things in the manifest (there is one NSIS string in the internal header that I did not change so it COULD still be nsis specific, one would have to recompile with a different name to make sure)

Yeah, I'd like to poke at changing some things in the exehead sources, too. If you have good instructions for creating a build environment, please let me know. 🙂

WHY it's doing this, I don't know, but I would _guess_ its one of the services starting with "Application" seen here

Well, Application Experience controls "compatibility" and has no effect and Application Information is kinda required for UAC so it's impossible to be sure if it's the cause. :P

Also, it's weird that editing the manifest didn't work for you; but I'm not wholly surprised. Further testing indicates that it's very hit or miss. 🙁

I haven't had the time yet, but I'm curious if the following manifest manifests any changes (sorry...):

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">

<assemblyIdentity version="1.2.3.4" processorArchitecture="X86" name="xxxx" type="win32">

</assemblyIdentity>

<description>XXXX</description>

<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">

<security><requestedPrivileges>

<requestedExecutionLevel level="requireAdministrator" uiAccess="false">

</requestedExecutionLevel>

</requestedPrivileges></security>

</trustInfo>

</assembly>

Hopefully, I'll find the time today to revisit this again.

Hm... More research is indicating that manifest changes won't likely make a difference... (Why did I see a difference? Who knows? Yay Windows?)

It's been noted by a couple MVPs that playing with secpol.msc may give an idea what's really going on. (I've not had time yet...)

Is anyone following this thread able to recompile NSIS to see if a simple change to the source will fix things?

Alternatively, how difficult would it be to add Xutzl's approach to the UAC plugin? My only real concern with wrapping the installer like that is that "Run program" will still run as an administrator, due to the plugin not being able to get the "real" user...

it does the same copy to temp with a random inno setup I tested

Awesome. 🙁 I'll try making a .msi later to see what it does... But maybe this is a core fault in Vista? 🙁

On the plus side, perhaps this could be leveraged longer-term by NSIS. If the "proper" solution is to spawn the installer via an elevated stub that's extracted, perhaps the functionality of the UAC plugin could/should be rolled into the core at some point?

.msi is special and it uses msiexec and services, does not have the problem probably

I'm not going to add anything to the UAC plugin, you would need a external .exe in $pluginsdir

I just tried the manifest you posted on a random .exe (WinSpy), same result and that is not even an installer

edit: as far as I can tell, process monitor does not seem to have this problem

If someone could test lewellyn's example on Win7, that would really help narrow things down

I'm downloading the x86 RC now. I'll probably have a VM up and running in about an hour or so - I'll post an update then.

UPDATE: VM is ready. I copied the installer over, just like I did on my x64 install.

It's *much* slower to start up than on Win7 x64, so it looks like this might not be fixed. However, it still seems faster than Vista x86, as well as my Win7 Beta1 x86 VM.

Process Monitor actually CRASHES when I try to start the installer, claiming it's out of memory (granted, the VM only has 512MB of RAM...), so I can't say for sure what happens. I'd allocate more RAM, but this computer doesn't have THAT much available (2GB RAM total, but keep in mind that it's a VM and Vista is running as well, so it might compromise the test result. Indeed, this might cause quite a bit of the slowdown here (my x64 machine has 4 GB RAM, and it's running "natively" there, not in a VM).

I don't see the file appearing in %windir%\temp - or %temp%, for that matter - so I'm guessing it now does whatever check it needs to do in-place.

I haven't tried altering the manifest yet, but if you have a specific one you want me to try, let me know - I'll keep an eye on this thread.

Process Monitor failed for me also, and I was not running in a VM

Hi everybody,

Did you find a solution to this issue ?
i'm experiencing the same problem.

i tried to change the manifest and rebuild makensisw.exe but issue is the same.

any clue ?

Guillaume

there is no solution, NT6 sucks, deal with it

ok.

Thanks for this answer. 😉