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!

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)

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!

Thank you Anders and thek for your answers.

Originally Posted by thek View Post

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?

Originally Posted by nsnb View Post

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?

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

vcredist.msi /passive /norestart

That works for us.

Originally Posted by CrushBug View Post

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.

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.