Temp directory issue after wix v 4.0.5 upgrade

[DipakTated]

WiX Version

4.0.5

.NET or MSBuild or Visual Studio Version

latest

HeatWave Version

latest

Windows Version

Win 10 64

Repro Repo

No response

Repro Steps

Am getting this error
SFXCA: Failed to create temp directory. Error code 5
CustomAction CheckingAppIsRunning returned actual error code 1603

I also see, that regarding temp directory some breaking changes fixes are made by wix. But how do i handle this code side issue at my end?

GHSA-rf39-3f98-xr7r

Actual Result

SFXCA: Failed to create temp directory. Error code 5
CustomAction CheckingAppIsRunning returned actual error code 1603

Expected Result

Success

Acknowledgements

• I acknowledge that this is a fully completed bug report. It is not a question or attempt to get help debugging my issue (because those should be sent to Discussions).

[robmen]

Can you please update the information above with your CustomAction element and where it is scheduled (the Custom element)? Those are very important pieces of information.

[richard-frolkovic]

Hi, I am facing the same issue.
My custom action is defined like this

<CustomAction Id="SetInstallFolderFromResponseFileCA" BinaryRef="CustomActionsDLL" DllEntry="SetInstallFolderFromResponseFile" Execute="immediate" />
<Custom Action="SetInstallFolderFromResponseFileCA" Before="CostFinalize" /> // in InstallExecuteSequence 

The issue seems to be, that the custom action server was moved from the temp folder to a system folder. Since immediate custom actions are to my knowledge always run as impersonated, they do not have the necessary elevated privileges.

[Smith00101010]

We have the same issue with Wix 3.14.1.

The Custom action related elements are:

<CustomAction Id="CA_SetupAccounts" BinaryKey="CustomActionsLib" DllEntry="SetupAccounts" Execute="immediate" Return="check"/>
<Custom Action="CA_SetupAccounts" After="CostFinalize"/>

The log output looks like this:

MSI (s) (38:F8) [11:29:24:214]: Doing action: CA_SetupAccounts
Action 11:29:24: CA_SetupAccounts. 
Action start 11:29:24: CA_SetupAccounts.
MSI (s) (38:34) [11:29:24:214]: Invoking remote custom action. DLL: C:\Windows\Installer\MSI18C4.tmp, Entrypoint: SetupAccounts
MSI (s) (38:20) [11:29:24:214]: Generating random cookie.
MSI (s) (38:20) [11:29:24:214]: Created Custom Action Server with PID 4708 (0x1264).
MSI (s) (38:78) [11:29:24:230]: Running as a service.
MSI (s) (38:78) [11:29:24:230]: Hello, I'm your 32bit Impersonated custom action server.
SFXCA: Failed to create temp directory. Error code 5
CustomAction CA_SetupAccounts returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)
Action ended 11:29:24: CA_SetupAccounts. Return value 3.
Action ended 11:29:24: INSTALL. Return value 3.

If we execute the setup from a elevated command prompt it works, but we would like to avoid that if possible.

[robmen]

Interesting. I have this test:

<Binary Id="ManagedCA" SourceFile="TestCA.CA.dll" />

<CustomAction Id="ImmediateCA" BinaryRef="ManagedCA" DllEntry="ImmediateCA"
              Execute="immediate" Return="check" />

<InstallExecuteSequence>
  <Custom Action="ImmediateCA" Before="CostFinalize" />
</InstallExecuteSequence>

The MSI log file shows the Windows Installer using the user temp folder:

MSI (c) (D8:F8) [07:01:21:794]: Doing action: ImmediateCA
MSI (c) (D8:F8) [07:01:21:794]: Note: 1: 2205 2:  3: ActionText 
Action 7:01:21: ImmediateCA. 
Action start 7:01:21: ImmediateCA.
MSI (c) (D8:5C) [07:01:21:796]: Invoking remote custom action. DLL: C:\Users\Rob\AppData\Local\Temp\MSICBED.tmp, Entrypoint: ImmediateCA
MSI (c) (D8:38) [07:01:21:797]: Cloaking enabled.
MSI (c) (D8:38) [07:01:21:797]: Attempting to enable all disabled privileges before calling Install on Server
MSI (c) (D8:38) [07:01:21:797]: Connected to service for CA interface.
SFXCA: Extracting custom action to temporary directory: C:\Users\Rob\AppData\Local\Temp\MSICBED.tmp-0\
SFXCA: Binding to CLR version v4.0.30319
Calling custom action TestCA!WixToolsetTest.TestCA.CustomActions.ImmediateCA
Begin ImmediateCA
Action ended 7:01:22: ImmediateCA. Return value 1.

I am on Windows 11 23H2, but this doesn't seem like something the Windows Installer would change.

[Bysza]

We face the same issue with 4.0.5.
In 4.0.4 it works fine.

Definition:

<CustomAction Id="InstallSmth" DllEntry="InstallSmthDll" Execute="immediate" Impersonate="yes" Return="check" BinaryRef="our_bin" />

<InstallExecuteSequence>
   <Custom Action="InstallSmth" Before="StartServices" Condition="((NOT Installed AND NOT REMOVE) OR (IS_UPGRADE))" />
</InstallExecuteSequence>

[Yaswanth112]

We are also seeing same issue.
it was working fine, with wix version 4.0.4, but failing to install issue with version 4.0.5.

Here is how we defined CustomActions

<Binary Id="CustomActions" SourceFile="$(var.installer.TargetDir)$(var.installer.TargetName).CA.dll" />

<CustomAction Id="CheckingAppIsRunning" DllEntry="CheckRunningAppAction" Execute="immediate" Return="check" BinaryRef="CustomActions" />

<InstallExecuteSequence>
  <Custom Action="CheckingAppIsRunning" Before="LaunchConditions" />
</InstallExecuteSequence>

Issue: installation fails immediately, logs we see:

SFXCA: Failed to create temp directory. Error code 5
CustomAction CheckingAppIsRunning returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)

[demienYu]

Hi, I am facing the same issue. My custom action is defined like this

<CustomAction Id="SetInstallFolderFromResponseFileCA" BinaryRef="CustomActionsDLL" DllEntry="SetInstallFolderFromResponseFile" Execute="immediate" />
<Custom Action="SetInstallFolderFromResponseFileCA" Before="CostFinalize" /> // in InstallExecuteSequence 

The issue seems to be, that the custom action server was moved from the temp folder to a system folder. Since immediate custom actions are to my knowledge always run as impersonated, they do not have the necessary elevated privileges.

I think you are pretty close.
I have been experiencing the same issue (same error) with my custom action. The only difference is my CA was impersonated.
As I changed "Impersonate" property to "no" everything started to work just fine.
Wix and all extension versions = 4.0.5

[richard-frolkovic]

Interesting. I have this test:

<Binary Id="ManagedCA" SourceFile="TestCA.CA.dll" />

<CustomAction Id="ImmediateCA" BinaryRef="ManagedCA" DllEntry="ImmediateCA"
              Execute="immediate" Return="check" />

<InstallExecuteSequence>
  <Custom Action="ImmediateCA" Before="CostFinalize" />
</InstallExecuteSequence>
...
...
I am on Windows 11 23H2, but this doesn't seem like something the Windows Installer would change.

I tested a completely new minimalistic solution and at first got the same result, however after some investigation found, that it was just, that the default vs project for CA used the Microsoft.Deployment.WindowsInstaller and not the wix tools nuget package. After changing that I got the bug again.

Hi, I am facing the same issue. My custom action is defined like this

  
The issue seems to be, that the custom action server was moved from the temp folder to a system folder. Since immediate custom actions are to my knowledge always run as impersonated, they do not have the necessary elevated privileges.

I think you are pretty close. I have been experiencing the same issue (same error) with my custom action. The only difference is my CA was impersonated. As I changed "Impersonate" property to "no" everything started to work just fine. Wix and all extension versions = 4.0.5

Do you use immediate or deferred CA? Using impersonate=no on immediate actions doesn't change anything for me.

[demienYu]

I have deferred CA.

[juvo64]

Will the correction also be made for Wix 3.14.1?

[tve-altx]

Will the correction also be made for Wix 3.14.1?

Also interested in the answer to this question

[CADbloke]

Workaround is to revert to 3.14.0 - https://github.com/wixtoolset/wix3/releases/tag/wix314rtm
Worked on my installation.

[tondrej]

Workaround is to revert to 3.14.0 - https://github.com/wixtoolset/wix3/releases/tag/wix314rtm Worked on my installation.

Not really, as 3.14.0 contains the vulnerability

[robmen]

@tondrej is correct. Going backward will expose you to the security vulnerability. The fix is in WiX v5's custom action handling. You can upgrade only your custom action projects to v5.

[CADbloke]

So there is no fix for Wix v3?

You can upgrade only your custom action projects to v5.

My problem is that I'm using Wix via WixSharp which isn't ready for Wix v5 yet. oleg-shilo/wixsharp#1493

Yes, this is OSS and my problem is MY problem, not yours. Simply putting it here for context.

[birarroshan]

@robmen Any timelines for fix in Wix v3?

[robmen]

@birarroshan No.

[ian-g-holm-intel]

We've been using v4.0.5 with a custom bootstrapper that depends on Wixtoolset.Mba.Core. The problem is there is no version of Wixtoolset.Mba.Core v5.0.0. We can't downgrade to 4.0.4 because of the security upgrade and can't upgrade to 5.0.0. Is there no way this fix can be added to a new v4 release?

[robmen]

@ian-g-holm-intel I understand that would make your life much easier. However, we've spent more time this year fixing issues in the WiX Toolset for free than on anything else. That simply isn't sustainable. So, our focus now is to work for our paying customers for a while.

If you want guarantees and SLAs, purchase a support contract, and you will become one of those customers we work for.

[barnson]

The problem is there is no version of Wixtoolset.Mba.Core v5.0.0.

https://wixtoolset.org/docs/fivefour/oopbas/