CODEWITHSUNDEEP
wixwindows-installer
karfus
karfus

Reputation: 939

MSI fails to run executable at end via CustomAction, tries to open .tmp file instead

I've created an MSI via WIX that uses the following code to run an executable at the end of the installation process:

    <CustomAction Id="ExecAction" Return="asyncNoWait" Execute="deferred" BinaryKey="ApplicationExe" ExeCommand="" />

    <InstallExecuteSequence>
        <Custom Action="ExecAction" After="InstallInitialize"><![CDATA[Not REMOVE]]></Custom>
    </InstallExecuteSequence>

This works as expected when run from the GUI via double-clicking the MSI. It also works on most Windows PCs when run from the command line via msiexec /i.

However, on some Windows PCs, when run from the command line, the installer fails to run the executable, and instead pops up a dialog indicating that it is trying to run a .tmp file and asking which program should be used to run it. This presents as a slightly different UX on Windows 7 vs. Windows 10 but essentially "Windows can't open this file...What program do you want to use to run MSIxxxx.tmp?".

I've looked at the verbose installer logs and compared "good" logs with "bad" logs but there are no errors and there is nothing jumping out as a problem.

Does anyone with familiarity with CustomActions have any idea how to address this? We're really baffled by this one.

Upvotes: 1

Views: 460

Answers (1)

PhilDW
PhilDW

Reputation: 20780

The .tmp thing is normal - a log will show entries such as:

Invoking remote custom action. DLL: C:\DOCUME~1\Fred\LOCALS~1\Temp\MSI540.tmp

and similar with anything streamed from the binary table to call or run. It reduces the chances that somebody will try to run an exe or call a Dll, and APIs such as CreateProcess don't care about the suffix - that's a shell thing.

My guess is that an AV product might be interfering somehow. It might be useful to post the relevant part of the MSI log just in case there's an error that might show something, but that type of process initiation shouldn't be acting as if it was a shell execute clicking on a file. The CreateProcess() call has been failed and reverted to a shell command, and an Explorer-type message box should never show fron a deferred custom action. It may also be useful to see which process owns the message box.

Upvotes: 1

Related Questions