One of my customers came across an uninstall issue on Windows 10 and shot me an email. It seems Windows 10 has a new way of adding and removing software:
The problem was users were calling into my customers helpdesk reporting the uninstall being blocked by a custom action. The common theme was that uninstall from the legacy Programs and Features worked but that it failed from the new Apps and Features. My customer provided me log files and the following stood out:
Action start 11:22:33: REDACTED.
SFXCA: Failed to create new CA process via RUNDLL32. Error code: 575
CustomAction REDACTED returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)
This indicated a WiX DTF SfxCA error. 575 means that RunDLL32 failed to initialize.
In my good log I saw:
Action start 11:36:35: REDACTED.
SFXCA: Extracting custom action to temporary directory: C:\Users\REDACTED\AppData\Local\Temp\MSIAFD1.tmp-\
SFXCA: Binding to CLR version v4.0.30319
Calling custom action REDACTED!REDACTED.CustomActions.REDACTED
MSI (s) (30:20) [11:36:36:464]: Doing action: REDACTED
Action ended 11:36:36: REDACTED. Return value 1.
That's what I expected to see. Ok, so what's different? Again I looked at the logs.
=== Verbose logging started: 10/17/2015 11:36:34 Build type: SHIP UNICODE 5.00.10011.00 Calling process: C:\Windows\Explorer.EXE ===
MSI (s) (30:20) [11:36:34:401]: Command Line: REMOVE=ALL CURRENTDIRECTORY=C:\Windows\system32 CLIENTUILEVEL=2 CLIENTPROCESSID=2704
and from the bad:
=== Verbose logging started: 10/17/2015 11:22:31 Build type: SHIP UNICODE 5.00.10011.00 Calling process: C:\Windows\ImmersiveControlPanel\SystemSettings.exe ===
MSI (s) (1C:F0) [11:22:31:794]: Command Line: REMOVE=ALL CURRENTDIRECTORY=C:\Windows\ImmersiveControlPanel CLIENTUILEVEL=2 CLIENTPROCESSID=3420
My customer was using WiX 3.7. I decided to set out to reproduce the problem with 3.7 and 3.10. My first attempt failed as I scheduled the custom action for deferred and it worked. However when I changed it to immediate execution, I was able to reproduce the problem. That's very strong evidence o me that this new "immersive control panel" process has an environment that is impacting DTF's ability to find and launch RunDLL.
Hopefully this write up will help the WiX guys find a resolution. You can find the bug logged here.
Further testing indicates this is limited to 64 bit Windows 10. 32 bit seems to function normally.
I did a simple Type 2 EXE custom action test and it called RunDLL32 just fine.
<SetProperty Id="RunDLL" Value="rundll32.exe" After="AppSearch" />
<CustomAction Id="test" Property="RunDLL" ExeCommand="printui.dll,PrintUIEntry /?" />
<Custom Action="test" After="InstallInitialize">REMOVE="ALL"</Custom>