stonkers
20th July 2007 22:23 UTC

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 <><

kichik
21st July 2007 02:41 UTC

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

stonkers
23rd July 2007 20:19 UTC

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???

kichik
23rd July 2007 20:25 UTC

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.

stonkers
23rd July 2007 21:20 UTC

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...

stonkers
24th July 2007 16:53 UTC

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)

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

Afrow UK
24th July 2007 17:23 UTC

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

Stu

stonkers
24th July 2007 19:37 UTC

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.

kichik
24th July 2007 20:08 UTC

(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.

stonkers
24th July 2007 20:30 UTC

What happens when "What"?

kichik
24th July 2007 20:36 UTC

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.

stonkers
24th July 2007 22:30 UTC

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

kichik
24th July 2007 22:54 UTC

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.

stonkers
24th July 2007 23:23 UTC

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

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

stonkers
25th July 2007 18:21 UTC

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

Afrow UK
25th July 2007 18:31 UTC

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

Stu

stonkers
25th July 2007 18:56 UTC

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

kichik
25th July 2007 19:51 UTC

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.

stonkers
25th July 2007 19:57 UTC

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

stonkers
16th August 2007 21:08 UTC

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

kichik
17th August 2007 12:43 UTC

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

stonkers
17th August 2007 15:26 UTC

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.

kichik
17th August 2007 16:21 UTC

Are you sure it has no drivers?

kichik
17th August 2007 16:23 UTC

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.

stonkers
17th August 2007 16:43 UTC

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!!!

99999999
18th August 2007 05:10 UTC

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 <><

 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

kichik
18th August 2007 10:01 UTC

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

99999999
19th August 2007 05:46 UTC

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.

kichik
19th August 2007 21:31 UTC

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

stonkers
22nd August 2007 22:04 UTC

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

kichik
23rd August 2007 17:53 UTC

No, you shouldn't use his workaround. And if my script shows both message boxes at the same time for you too, I need every possible detail and preferably direct access to the computer from you too.

stonkers
23rd August 2007 21:04 UTC

When i ran it locally - >test /S, it worked fine. The difference being that when I have these problems, I'm using PSEXEC to kick off the exe's in silent mode from another server. I won't be able to see the popups if I run from PSEXEC, so I'll have to figure out a way to modify the test code to show order without needing human intervention. Can you think of a way to do this kichik?

kichik
24th August 2007 08:13 UTC

Try writing to the same file with both instances on both their beginning and end, and see what comes out first.

stonkers
29th August 2007 20:09 UTC

I don't get what you mean "both their beginning and their end"...

OutFile test.exe
Name test
Section

;Write to file here?

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

;Write to file here?

SectionEnd

Section uninstall

;Write to file here?

SectionEnd

kichik
31st August 2007 09:35 UTC

OutFile test.exe
Name test
Section

# Write here

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

# Write here

SectionEnd

Section uninstall

# Write here

Sleep 2000

# Write here

SectionEnd

stonkers
4th September 2007 17:58 UTC

This isn't giving me anything like the results that I would expect. The following code:

OutFile test.exe
Name test
;Included file(s)
!include "FileFunc.nsh"

Section

  FileOpen $7 "c:\testFile.txt" a
  FileWrite $7 "Write1"
  FileWrite $7 "$\r$\n"
  FileClose $7

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

  FileOpen $7 "c:\testFile.txt" a
  FileWrite $7 "Write2"
  FileWrite $7 "$\r$\n"
  FileClose $7

SectionEnd

Section uninstall

  FileOpen $7 "c:\testFile.txt" a
  FileWrite $7 "Write3"
  FileWrite $7 "$\r$\n"
  FileClose $7

Sleep 2000

  FileOpen $7 "c:\testFile.txt" a
  FileWrite $7 "Write4"
  FileWrite $7 "$\r$\n"
  FileClose $7

SectionEnd

demiller9
4th September 2007 19:04 UTC

4.9.5.2 FileOpen Opens a file named "filename", and sets the handle output variable with the handle. The openmode should be one of "r" (read) "w" (write, all contents of file are destroyed) or "a" (append, meaning opened for both read and write, contents preserved). In all open modes, the file pointer is placed at the beginning of the file. If the file cannot be opened, the handle output is set to empty, and the error flag is set.

stonkers
4th September 2007 19:28 UTC

Thanks DEMiller9! With the following code:

OutFile test.exe
Name test
;Included file(s)
!include "FileFunc.nsh"

Section

  FileOpen $7 "c:\testFile.txt" a
  FileSeek $7 0 END
  FileWrite $7 "Write1"
  FileWrite $7 "$\r$\n"
  FileClose $7

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

  FileOpen $7 "c:\testFile.txt" a
  FileSeek $7 0 END
  FileWrite $7 "Write2"
  FileWrite $7 "$\r$\n"
  FileClose $7

SectionEnd

Section uninstall

  FileOpen $7 "c:\testFile.txt" a
  FileSeek $7 0 END
  FileWrite $7 "Write3"
  FileWrite $7 "$\r$\n"
  FileClose $7

Sleep 2000

  FileOpen $7 "c:\testFile.txt" a
  FileSeek $7 0 END
  FileWrite $7 "Write4"
  FileWrite $7 "$\r$\n"
  FileClose $7

SectionEnd

Write1
Write3
Write4
Write2

stonkers
5th September 2007 17:05 UTC

OK, nothing's changed on the server. I'll have to wait until the next time this issue rears it's ugly head and see if the test.exe exhibits different behavior. Other than that, I have no idea where else to go with this other than always checking the deploy log to see whether it has any errors in it, and if so, deploying locally... Thanks for all the help!

stonkers
6th September 2007 18:00 UTC

OK, so I found the issue again on a different server, ran the test.exe with PSExec and got the same results:

1342

So, I'm thinking that we're barking down the completely wrong path (my dog does that a lot also). One thing that is always the case. It fails creating a folder, and thus, it doesn't write any files to that folder. The only reason I can think of for it not being able to create the folder is because it still thinks the folder is there. So maybe it got deleted in the uninstall, but it's so lightning fast (in silent mode because of the lack of interaction), that the OS lies to NSIS saying that the folder is already there. What if I put a 5 second sleeper at the end of all of my uninstalls to give the OS time to catch up? I'll give it a shot and report back.