2. NSIS Discussion
  3. ExecWait doesn't wait (on Windows 7)

Archive: ExecWait doesn't wait (on Windows 7)


nsnb
28th June 2010 14:27 UTC

ExecWait doesn't wait (on Windows 7)
  I came across this problem while testing the uninstall part of an NSIS script:

Despite not changing anything in the -un.post section that takes care of removing all Start Menu entries:

 ;Delete empty start menu parent diretories

  StrCpy $MUI_TEMP "${D_STARTMENU}"

>SMDELOOP:

    ClearErrors

    RMDir $MUI_TEMP

    GetFullPathName $MUI_TEMP "$MUI_TEMP\.."

    IfErrors SMDELDONE

    StrCmp $MUI_TEMP $SMPROGRAMS SMDELDONE SMDELOOP

SMDELDONE:
The uninstaller no longer deletes the last (topmost) entry in the Start Menu. In my attempts to troubleshoot this I discovered that this is not always consistent: Sometimes it deletes and sometimes it doesn't.

So, I decided to place a MessageBox line right after the 'RMDir $MUI_TEMP' line:
    RMDir $MUI_TEMP

MessageBox MB_OK|MB_ICONEXCLAMATION "Removed $MUI_TEMP"    ; for debug only

    GetFullPathName $MUI_TEMP "$MUI_TEMP\.."
And I was surprised to see that this message box is displayed while an ExecWait from a previous un.Uninstall section was still in progress...
ExecWait '"$INSTDIR\vcredist_x86.exe" /q:a /c:"VCREDI~1.EXE /q:a /c:""msiexec /x vcredist.msi /qb!"" "'
Obviously, something is happening here in parallel but how could this be?
  1. Isn't ExecWait supposed to wait?
  2. Isn't Section -un.post supposed to start after all Section "un.Uninstall"s?

Most importantly: How would you suggest that I solve (or workaround) this problem?

Thanks!

Anders
28th June 2010 14:55 UTC

ExecWait ALWAYS waits, I have not seen a single case yet where it is actually broken (and it will probably never happen, it is just WaitForSingleObject on a process handle) If you think it does not wait, the command you are executing is probably wrong (Or it spawns subprocesses and has no option to wait on them)

thek
28th June 2010 17:03 UTC

Hello nsnb

Anders is right with is assumption, vc_redist spawns his own process
actually I don't understand what you try to achieve with your command
with your command you decompress the contents of vc_redist, there you start again a vc_redist where you decompress the contents and start the MSI installer!!!

so there are probably 3 childprocess spawend!
I simply use '"$TEMP\VS2008_SP1_vcredist_x86.exe" /q'

if a real feedback for the user is needed you should install the redistributable files manually
decompress the content and add it file by file to your installer.


Also I wouldn't uninstall the VC redist
Because other programms installed after your application my depend on it!!
so your uninstaller will probably break other apps!

nsnb
28th June 2010 17:58 UTC

Thank you Anders and thek for your answers.

Originally posted by thek
I don't understand what you try to achieve with your command... you should install the redistributable files manually decompress the content and add it file by file to your installer.
It's a legal issue dictated by Microsoft's EULA.

After experimenting with this a little more, I discovered that the MessageBox actually solves the problem... This is not practical of course for the real installer, so I wonder what types of workarounds can I come up with?

Perhaps placing a delay of several hundreds milliseconds?

nsnb
28th June 2010 18:38 UTC

Originally posted by nsnb
so I wonder what types of workarounds can I come up with? Perhaps placing a delay of several hundreds milliseconds?
Answering myself: Sleep() is ugly (in any programming language...), so I took the asynchronous approach: Right after the RMDir $MUI_TEMP line I check for errors:
RMDir $MUI_TEMP

IfErrors L_SM_ERROR

>...

...

...

>L_SM_ERROR:

>MessageBox MB_OK|MB_ICONEXCLAMATION "Error in RMDir $MUI_TEMP."
It turns out that by mere checking for the error, it never occurs anymore... (the message box is never displayed and the entire Start Menu entry is removed cleanly just as it used to be).

Suggests a timing problem?

CrushBug
28th June 2010 18:47 UTC

We have unpacked the vcredist.msi and vcredist.cab files and ExecWait the following:

vcredist.msi /passive /norestart

That works for us.

nsnb
29th June 2010 17:25 UTC

Originally posted by CrushBug
We have unpacked the vcredist.msi and vcredist.cab files and ExecWait the following:

vcredist.msi /passive /norestart

That works for us.
Of course it works but is it legit? i.e. according Microsoft's EULA distributing the files individually is not allowed.

As I described above, testing for errors after RMDir $MUI_TEMP solves the (timing) problem, so I am able to deliver a working uninstaller using Microsoft's required method.

CrushBug
29th June 2010 22:18 UTC

Well, we got the instructions on how to extract the two files from within the redist from an MSDN blog article. We have shipped 2 retail products like this. I cannot see how this could violate a MS EULA. All we are doing is unpacking an archive we are NOT redistributing the actual VC runtime files themselves.

Fork me on GitHub