Silent Install - Incomplete Releases

I've been having some issues lately and am wondering if it's happened a lot. We're doing silent installs using a website I wrote that uses PSExec to kick off silent installs on test systems. The silent install automatically kicks off the uninstaller and then rolls into the installer. We have the fileoverwrite flag set to ifnewer. What's happening is that the delete of files is lagging, and when the file /r gets started, some of the files haven't disappeared yet, and thus NSI says "SKIPPING" and then we end up with an incomplete app out there. It didn't happen at all at first except on one machine. I figure that machine was slower than the rest. Lately it's been happening on all sorts of machines. I'm thinking my best resolution is to set fileoverwrite on, but just wondering if this is a typical situation.

Thanks,
Eric <><

Sounds like the process is asynchronous. Make sure you execute the uninstaller with ExecWait and _?=.

See: http://nsis.sourceforge.net/When_I_u...he_uninstaller

Yep, we're doing that. Here's an example of one of our uninstall sections:

<!--Code Snippet-->
IfSilent runSilentUninstall

MessageBox MB_OKCANCEL|MB_ICONEXCLAMATION \
"Application is already installed. $\n$\nClick `OK` to remove the \
previous version or `Cancel` to cancel this upgrade." \
IDOK uninst
Abort

;Run the uninstaller
uninst:
ClearErrors
CopyFiles /SILENT /FILESONLY "$INSTDIR\Uninst.exe" "$TEMP\Uninst.exe"
Delete "$INSTDIR\Uninst.exe"
ExecWait '"$TEMP\Uninst.exe" _?=$INSTDIR'
goto done

runSilentUninstall:

ClearErrors
CopyFiles /SILENT /FILESONLY "$INSTDIR\Uninst.exe" "$TEMP\Uninst.exe"
Delete "$INSTDIR\Uninst.exe"
ExecWait '"$TEMP\Uninst.exe" /S _?=$INSTDIR'
<!--End Code Snippet-->

We've been doing these silent installs for about 6 months. The partial release phenomenon originally only happened on one machine, and not consistently (same installer on other machines worked fine). Now it's been moving through all of the machines. Win2k3 OS. Maybe a patch or something is hosing us up???

Can't help much without any method to reproduce this. Try adding some debug messages to make sure it's really synchronized.

If it's really deleting the files only after the installer starts extracting them and it's not a problem with ExecWait, I'd put my money on some anti-virus update.

I'll see if "SetOverWrite on" solves it. It seems like the OS is telling NSIS that things are there that no longer exist. If that's the case, this should fix it (hokey fix, but still a fix). I'm logging (special log build), so I should be able to determine the order of uninstall/install stuff...

OK, now that I've changed it to overwrite, it's getting an error. The log states that it's creating the directory first:

CreateDirectory: "D:\Program Files\AppName\Public" (1)

but this never gets created. So then when it tries to write the files there, it errors:

File: overwriteflag=0, allowskipfilesflag=2, name="MyFile1.aspx"

File: error creating "D:\Program Files\AppName\Public\MyFile1.aspx"

File: error, user cancel

File: overwriteflag=0, allowskipfilesflag=2, name="MyFile2.aspx"

File: error creating "D:\Program Files\AppName\Public\MyFile2.aspx"

File: error, user cancel

Any clue where I go from here to figure out why the CreateDirectory failed?

Thanks,
Eric

Does "D:\Program Files\AppName" exist?

Stu

No, it did, but I deleted it in the uninstaller. Then when the installer tries to create it, it doesn't seem to fail, but it doesn't create it (unless that's what the (1) means after it tries to create the directory).

This is getting more confusing, because we've got a different installer that's doing this same thing (saying error creating such and such file), but the files exist after the installer gets done with the new timestamp and everything.

(1) means it's also SetOutPath. It doesn't actually log directory creation failures. I've added a bit more logging there for the next version.

You should add a few message boxes in there to figure out what happens when.

What happens when "What"?

What happens at what time point. Which files are extracted at what time? Which files are deleted at what time? What happens first? Does the uninstaller really finish by the time the installer starts? Does the file exists when the installer tries to extract it? Does the folder exist when the installer tries to put a file in it? You can even use IfFileExists for that.

Message boxes won't help because this only happens on silent install. I can see what happens, when, by the log file. The uninstaller doesn't log what it does, but it does log that it finished before the installer starts his work.

Exec: command=""C:\DOCUME~1\efetzer\Local Settings\Temp\Uninst.exe" /S _?=D:\Program Files\MyApp"

Exec: success (""C:\DOCUME~1\efetzer\Local Settings\Temp\Uninst.exe" /S _?=D:\Program Files\MyApp")

Section: "Install"

settings logging to 1

logging set to 1

The weirdest thing about this is that we had no problems for 5+ months (except occasionally on one machine out of about 200) and then, all of a sudden, it started happening everywhere... I'll add a few pushes to the log as to whether the directory exists or not when it tries to create it and such.

Message boxes can show in silent installers when /SD isn't used.

The fact Exec finishes doesn't mean the uninstaller really finished executing.

If the problem really came without any change, it's probably a failing anti-virus.

The only change we've identified is the following patch:

http://www.microsoft.com/technet/sec.../MS07-040.mspx

What exactly do you mean by "a failing anti-virus"? That we would have a virus on all of these machines?

No an anti-virus suite that isn't doing it's job correctly.
A false positive is one of them.

Stu

I don't understand what you mean. How can a anti-virus suite affect a release executable.

Ant-virus applications employ a slew of tactics to try and protect your system. Some are simple such as scanning every file on the system once a day and some invasive such as scanning a file when it's modified or even monitor file deletions and modifications and filter those on the basis of known viral behaviors. Sometimes, the more invasive operations can be flawed, either by design or by implementation. That could cause problem such as those you're describing.

Well explained, thanks! I'll dig into it with my systems dudes.

OK, this is definitely not it. We reproduced it this afternoon with the antivirus completely shut off. Any more clues?

How about a machine with no Anti-Virus installed? Not all AVs give you an option to completely turn them off in the GUI.

I didn't use the GUI, I shut off all of the services (runs as multiple services). I reproduced the error with no processes running for Symantec at all. I'm at the mercy of my organization, and thus, not allowed to uninstall antivirus.

Are you sure it has no drivers?

BTW, I have heard of this patch you were talking about as the cause for other problems. I don't remember exactly where, but it's worth searching to see if the problems are related.

I'm having that patch removed from the server that the problem happens on consistently. We'll see where this puts us... Thanks again Kichik!!!

Re: Silent Install - Incomplete Releases

Originally posted by stonkers
I've been having some issues lately and am wondering if it's happened a lot. We're doing silent installs using a website I wrote that uses PSExec to kick off silent installs on test systems. The silent install automatically kicks off the uninstaller and then rolls into the installer. We have the fileoverwrite flag set to ifnewer. What's happening is that the delete of files is lagging, and when the file /r gets started, some of the files haven't disappeared yet, and thus NSI says "SKIPPING" and then we end up with an incomplete app out there. It didn't happen at all at first except on one machine. I figure that machine was slower than the rest. Lately it's been happening on all sorts of machines. I'm thinking my best resolution is to set fileoverwrite on, but just wondering if this is a typical situation.

Thanks,
Eric <><

Okay Eric, I've had this problem before too. It appears that while the uninstaller is described to work where it doesn't start up another copy of itself when you use the _? parameter, that it still does. All _? does is tell it where to uninstall from.

In order to solve this issue, I've posted the following bit of code I used:

 function RunPreviousVersionUninstall

  

  StrCpy $0 "$PROGRAMFILES\MYAPP\uninstall.exe"

  ${GetParent} "$0" $5

  IfFileExists "$0" copyuninstaller loopend

  

  copyuninstaller:

  CopyFiles /SILENT "$0" "$TEMP\tempuninstall.exe"

 

  setdetailsprint textonly

  Exec '"$TEMP\tempuninstall.exe" /S _?=$5'    

  StrCpy $2 "Uninstalling Previous Version..." 

  DetailPrint "$2"

  StrCpy $4 ""



  Sleep 1000



  loopbegin:

    StrLen $5 "$4"

    StrCmp $5 "12" 0 +2

    StrCpy $4 ""

    StrCpy $4 "$4."

    StrCpy $3 "$2$4"

    DetailPrint "$3"

  	${nsProcess::FindProcess} "tempuninstall.exe" $R2

	StrCmp "$R2" "0" loopagain

  	${nsProcess::FindProcess} "tempuninstall" $R2

	StrCmp "$R2" "0" loopagain

    goto loopend

  loopagain:

	sleep 1000

	goto loopbegin

  loopend:

  

  setdetailsprint both

functionend

As you can see I am waiting for the named process to quit, as the uninstaller starts up another copy of itself, with the same name. If you wait until this process has gone away, then the uninstall will be completed. Everyone here told me that _? made the uninstaller run only once, but that's just not true from my experiences.

When you use _?= another process will never be spawned. That can be shown by the following simple script.

OutFile test.exe

Name test

Section

WriteUninstaller $TEMP\uninst.exe

ExecWait '"$TEMP\uninst.exe" /S _?=$TEMP'

MessageBox MB_OK "uninstall completed"

SectionEnd



Section uninstall

MessageBox MB_OK uninstalling...

SectionEnd

If this doesn't work for you, it's one huge bug and you should report it instead of creating such workarounds.

Originally posted by kichik
When you use _?= another process will never be spawned. That can be shown by the following simple script.

OutFile test.exe

Name test

Section

WriteUninstaller $TEMP\uninst.exe

ExecWait '"$TEMP\uninst.exe" /S _?=$TEMP'

MessageBox MB_OK "uninstall completed"

SectionEnd



Section uninstall

MessageBox MB_OK uninstalling...

SectionEnd

If this doesn't work for you, it's one huge bug and you should report it instead of creating such workarounds.

Yeah it doesn't work for me, perhaps it is because I am using it silently as well. However in my case I used the time waiting around, to do something so it's not something I considered a huge issue for me. However I did ask around about it, and everyone just re-iterated the help file, which I can read all by myself (thank you,) and until I figured out that _? wasn't working for me as documented, has exactly the same problems Erik is describing.

As I said, this is a major issue. I need every possible detail.

Yeah, I'm still getting the same thing with the patch off. Looks like we've got something going since I've been gone. I'm really happy about that because this is kicking my butt!!!! Let me know kichik if I should do 9 9's workaround. I'm hoping not because I would have to do it in about 400 places. Thanks - Eric