Installer takes a long time to load
 

Hi,

I have a question which may or may not be related to NSIS 3. I have noticed that the installer that I am working on takes a long time to load. By loading time I mean the time after the user 2x Clicks the Setup.exe until something appears that the user can see, which tells him that something is happening. On an SSD disk it takes 10-15 seconds, on a "normal" disk, up to 40 seconds. It seems to be independent of UAC enabled / disabled.

During this time I can already see the Setup.exe process and it is using a small part of the processor. There appears to be no HDD activity though, at least not something substantial (so no idea why SSD is faster).

I also don't always see the "Verifying installer" and "Unpacking" messages either. When do these two messages come?

Now I wouldn't mind this that much but from a user perspective, it is unacceptable. I wanted to ask if anyone experienced something like this or if there are any tips on how to optimize the Installer scripts so that it loads faster.

Thanks,
Mircea

Please provide some more details!

Are you using solid compression?

Windows version? 64-bit?

Does it happen with example1.nsi?

Vista RTM would copy the installer to %windir%\temp to verify but only for installers that require elevation IIRC...

Hi,

I tried both uncompressed and with solid, lzma. I tried the installer on Windows 7 and Windows 10, both x64 (same behavior). It does not happen with example1.nsi. I do use

code:
RequestExecutionLevel admin

!ifdef NSIS_PACKEDVERSION

	ManifestSupportedOS all

!endif

and I also have this:

code:
VIProductVersion "${INSTALLER_VERSION_STRING}.${INSTALLER_BUILD_NUMBER}"

VIAddVersionKey FileDescription "${PRODUCT_NAME} Software Installer"

VIAddVersionKey FileVersion "1.0.0.0"

VIAddVersionKey ProductName "${PRODUCT_NAME}"

VIAddVersionKey ProductVersion "${INSTALLER_VERSION_STRING}.${INSTALLER_BUILD_NUMBER}"

VIAddVersionKey CompanyName "MyCompany"

VIAddVersionKey LegalCopyright "(C) 2015 - MyCompany"

Maybe this is an Antivirus software issue?

AV software checks every process at start so this delay can be caused by AV check.

Even worse: The A/V software probably recognizes the NSIS installer and unpacks + scans all the files in that installer - just like it does with other types of "archive" files - before it even allows the installer to run. This can take quite a while! And, while the A/V software is blocking things, NSIS has no chance to display any dialog, because the installer process is not even running yet.

You can check this very easily: Just disable the "real-time protection" or "guard" feature of your A/V software and then try again!

Hi,
thanks for the suggestion but I only have Windows Defender installer. After I disable Real-time protection the time needed to load doesn't change unfortunately :(

That might be the normal behavior. Which Size is your installer?
I´ve developed a simple app in NSIS with a huge payload (formats USB stick, make it bootable an copy lots of stuff on it). The app was stored on a networkshare to give access to all our users.
With RequestExecutionLevel admin the app took ages to open because the installer unpacks all stuff to local %temp% before executing. Regardless of which compression was used or uncompressed.
With RequestExecutionLevel user the app directly starts. But i dont know why.

My workaround was, because only one small function required admin rights (test stick with QEMU), a second embedded "installer" with RequestExecutionLevel admin that triggers that function.

Maybe it helps.

Perhaps if a file is requesting admin rights, the OS automatically virus checks the .exe?

That was one of my thougts and checked this also. No AV product, completely disabled windows defender, no microsoft malicious software removal tool and so on. But only Win7 x64 Ultimate because this is our working environment. Always the same behavior.

Hi,

I guess Highcoder is onto something. My installer size (unpacked) is 1.6GB (900MB with no compression, 250MB with compression). I also need the admin privileges throughout the installer as I am working with services (installing, stopping, starting, removing), change Windows settings, start other installers (ex: to install graphics drivers), deploy files in %ProgramFiles%, etc. It would be next to impossible to redesign the whole installer to work without admin privileges...

I also tested the installer on XP just now and, surprise (or not really), it starts immediately. So yes, I guess it's a combination of large size, admin privileges request and Windows playing it safe.

I should see what happens with UAC off (although this will not be the case for our customers).

Thanks again for all the input!

Mircea

Yep, on XP or with UAC off it will start immediately. But as you say this will be a no go.
So another attempt is to use one of the cab setup plugins or the wimImage plugin. So you have the small NSIS exe that starts immediately an the payload is stored in cab or wim files. Like any other setup routine it does with large payload.

You could try running Process Monitor from Microsoft and see if there are any other processes reading the file or copying it somewhere like we have seen before on Vista.

Tried Process Monitor and I found out that "consent.exe" reads the entire file before displaying the privilege elevation dialog. So yeah, there I have it...

yep, thats UAC

I wrote the WimImage plugin, so you should be fine. I have also been experimenting with the nsis source code to allow external file support, I have a working prototype but I don't know if it will ever make it into the trunk. If there is enough interest I might fork the code from just after the 3.0b2 release.

I wanted to try the WimImage plugin but everything I am using now is ansi-based and I am not sure if it is possible to combine ansi and unicode inside the same installer or how to "switch" everything to unicode...

The 3.0 series has unicode support, so just put 'unicode true' in the script and see how many errors you get. No errors generally means you're good to go. You do need to generate the .wim file separately with another script file though.

Thanks for the unicode tip. I tried "just" activating it but it throws errors related to some other plugins I use.
I also performed some tests on Windows 7 with UAC disabled and it still needs a lot of time to load. As far as I can tell, in this case the Setup process reads the whole file (twice) before opening it.
If anyone is interested, I attached the ProcMon log. Maybe someone can tell what is going on. In the meantime I will try to see what happens if I were to use NSIS 2.46.

thanks!