Custom Actions not working when public desktop not present

[alhenderson]

I have an installshield 2013 installer which does not work on machines when the 'C:\users\public\desktop' folder is not present. Extract from the installer log is below. Doesn't tell me a great deal. I don't think the custom action is being called - seems to fail before it gets there. The event log on the machine contains entries with event ID 1000 saying that msiexec has faulted, pointing the finger at ole32.dll.

I used Process Monitor to see what the installer was doing and eventually found out that the public desktop folder (C:\users\public\desktop) was missing. If I created this folder, then the install works fine. What I don't understand is what is that folder being used for, and how I can change this behaviour? I created a new install project from scratch that just delivered a single file. It worked absolutely fine until I added a custom action (which does nothing more than call SprintfMsiLog()). As soon as I added that, this new installer crashed in the same way.

So.. can anyone explain the reliance on this public desktop folder? I can't even work round it by writing a custom action to put it there, as the custom action will never get run due to the crash! The target OS for this installer is Server 2008 R2.

I'd really appreciate any input - tearing my hair out here!

Thanks,
Al.

Action 6:17:16: GetNodeType.
Action start 6:17:16: GetNodeType.
MSI (c) (10:A0) [06:17:16:708]: Invoking remote custom action. DLL: C:\Users\xxxxx\AppData\Local\Temp\2\MSI5124.tmp, Entrypoint: f3
InstallShield 6:17:16: Running InstallScript function f3
InstallShield 6:17:16: Opening stream of file C:\Users\xxxxx\AppData\Local\Temp\2\MSI5124.tmp
InstallShield 6:17:16: Extracting support file IsConfig.ini to C:\Users\xxxxx\AppData\Local\Temp\2\{F44153CC-B60B-4024-8367-B898F09B70BF}\IsConfig.ini
InstallShield 6:17:16: Extracted isconfig.ini to C:\Users\xxxxx\AppData\Local\Temp\2\{F44153CC-B60B-4024-8367-B898F09B70BF}\IsConfig.ini
InstallShield 6:17:16: Got '{DEC7FF08-D171-45C3-A160-5B86BC5D52B6}' for TempPathGuid from isconfig.ini
InstallShield 6:17:16: Attempting to use temp path 'C:\Users\xxxx\AppData\Local\Temp\2\{DEC7FF08-D171-45C3-A160-5B86BC5D52B6}'
InstallShield 6:17:16: Using new temp path
InstallShield 6:17:16: Cleaning up temp file C:\Users\xxxxx\AppData\Local\Temp\2\{F44153CC-B60B-4024-8367-B898F09B70BF}\IsConfig.ini
InstallShield 6:17:16: Using temp folder C:\Users\xxxxx\AppData\Local\Temp\2\{DEC7FF08-D171-45C3-A160-5B86BC5D52B6}
InstallShield 6:17:16: Installing engine...
InstallShield 6:17:16: Using product language 1033
InstallShield 6:17:16: Detected X64 OS
InstallShield 6:17:16: Extracting support file ISBEWX64.exe to C:\Users\xxxxx\AppData\Local\Temp\2\{DEC7FF08-D171-45C3-A160-5B86BC5D52B6}\ISBEW64.exe
InstallShield 6:17:16: Skipping optional support file _isuser_0x0409.dll
InstallShield 6:17:16: Setting script cmdline...
InstallShield 6:17:16: ProductCode is {615EECF6-9DAC-445F-98F8-49AE86646CF0}
InstallShield 6:17:16: Initializing Engine
CustomAction GetNodeType returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)
Action ended 6:17:17: GetNodeType. Return value 3.
MSI (c) (10:04) [06:17:17:848]: Doing action: SetupCompleteError

[alhenderson]

Yet again, another messy workaround for some installshield/msi behaviour I don't understand. I have added a Powershell custom action before my installscript ones which looks for the public desktop folder and creates it if it is not present. When creating that custom action, I chose to store it in the installer binary table. Powershell custom actions appear to be OK without the public desktop folder, maybe it's just the installscript ones that can't cope.

Top defensive coding somewhere by someone..

Anyway, hope that helps someone (might well be me next time I end up googling for this!).

Al.