Interesting. I will pass this on.

Hi,

I ran into a very similar problem that Johan described above. I use WiseScript (Wise Installation Studio 7SP2) as a bootstrapper EXE to an MSI, where it extracts the MSI and executes it appended with the built-in var %CMDLINE% (Execute Program, EXE Path: msiexec.exe, Command line: /I %MSIPATH% %CMDLINE%)

A few cases have been reported to Support where a user double-clicks on the EXE and gets the "Windows Installer" help screen due to a bad command line, where there really is no command line to begin with. I was unable to reproduce this, but after working with an end-user and getting a process monitor output, I saw an msiexec.exe query like below:

C:\WINDOWS\system32\msiexec.exe" /I "C:\DOCUME~1\Admin\Local Settings\Temp\MySetup\MySetup.msi" Settings\Temp\GLB203A.tmp

where the "Settings\Temp\GLB203A.tmp" is what gets appended via the %CMDLINE%, even though %CMDLINE% should have been empty. The problem sounds very similar to Johan's above, with the additional .tmp file that wisescript executables always produce.

I was not able to reproduce either this issue or Johan's (I followed the steps to reproduce). Johan; if you see this post, can you tell if this was specific to a certain OS version? And I wonder if there could be another piece to the puzzle (a certain anti-virus program/scanner in the environment).Our end-users with the problem seem to be all XP.

At this point, my work-around will be appending an innocent,  non-existent MYVAR=0 to the %CMDLINE% value, just so that it's never empty (assuming that this only happens when the %CMDLINE% is empty. Johan, do you mind verifying this assumption as well?)

Thank you.

-Fatih

Hi,

I think this might be the same bug. "My bug" was observed on a customer PC (I think it was Windows 2003 server) where the NtfsDisable8dot3NameCreation was enabled in the registry. This means that Windows doesn't create short file names (8.3 names) for folders. The problem happens then when a long folder name with a space in the name is not interpreted right by Wise. By default, Wise use to 8.3 file names to interpret the command line. But in such an environment, the 8.3 file name doesn't exist.

In my testing I observed this behaviour on any OS when the NtfsDisable8dot3NameCreation was enabled in the registry. Note that this is not enabled by default, but might be because of performance or other reasons.

You could check this registry entry in the end-user computer. It could of course have been disabled again at some point, so to be sure, also check the temp directory with DIR /X to show if it has an 8.3 name. If it only has a long name, you have the issue pinpointed.

You could check the logic that Wise uses for interpreting command lines. You can bypass the part that is passed on to the MSI by creating your own script that parses the command line.

Thank you both for clarifying the scenarios where you experience this problem. I have emailed the Wise PM with a link to this thread so that the error can be logged with the developers, as I would expect a service pack release to appear for WPS8 at some point in the future. Meanwhile, the workaround would appear to be some careful editing of the stub wrapper code that compiles into the EXE, or even generating your own custom wrapper.