Custom action (run batch file) doesn't execute correctly from setup package

[AndreG]

Without going into the scary details of why I need this, I've created a batch file (attached with extra ".txt" extension) that gets the location of a text-based file from the Windows Registry key, then updates it's contents according to the parameters it gets passed.

When run manually, the working directory doesn't make any difference to the script itself, and as long as the registry key exists and points to the correct file, this script works perfectly on multiple computers (Win 7, Win 8.1, Win 10). My setup package bundles another custom setup which is used to configure the base folder structure (amongst other things) for multiple other packages, so I've left this bundled setup to extract my new script file, simply locating and executing it from the wrapping setup.

My custom actions are configured as "Launch File" with the following settings:

• File to launch: [APPDIR]scripts\scheduler-update.cmd
• Command line: -u "key" "value"
• Working directory: %TEMP%
• (on) Hide program's window
• (on) Run as Administrator
• (on) Wait for custom action to finish before proceeding

After finding this other thread with a similar error, I tried moving my custom actions directly before the "Install Execution Stage > Finish Execution" step, along with making it deferred and with no impersonation, but I still get the exact same behaviour. So, beyond the above details, I've tried the following things:

• Before "Finish execution" with deferred execution time
• After "Finish execution" with immediate execution time
• Not setting a "Working directory"

Running with or without a working directory, I see the following error in my setup log (except for only the "/dir %TEMP%" parameters):

Code: Select all

Action 11:30:29: SchedulerAddMysqlUser. 
Action start 11:30:29: SchedulerAddMysqlUser.
CustomAction SchedulerAddMysqlUser returned actual error code 1 (note this may not be 100% accurate if translation happened inside sandbox)
Error 1722. There is a problem with this Windows Installer package. A program run as part of the setup did not finish as expected. Contact your support personnel or package vendor.  Action SchedulerAddMysqlUser, location: C:\Windows\Installer\MSI9078.tmp, command: /RunAsAdmin /HideWindow /dir %TEMP% "C:\NortechSystems\scripts\scheduler-update.cmd" -a "mysqluser" "null" 
MSI (s) (90:58) [11:30:31:256]: Product: CountIT -- Error 1722. There is a problem with this Windows Installer package. A program run as part of the setup did not finish as expected. Contact your support personnel or package vendor.  Action SchedulerAddMysqlUser, location: C:\Windows\Installer\MSI9078.tmp, command: /RunAsAdmin /HideWindow /dir %TEMP% "C:\NortechSystems\scripts\scheduler-update.cmd" -a "mysqluser" "null" 

Action ended 11:30:31: SchedulerAddMysqlUser. Return value 3.

I've also attached the setup log files (with "/L*X") from the last two test runs for reference, I can't find any other details relating to these custom actions, but perhaps someone else will see something I missed...

What am I doing wrong here?

[Eusebiu]

Hi,

I'm not sure why you encounter this problem. Can you please send us the .AIP (project file) to support at advancedinstaller dot com, so we can have a better view of your project settings?

Best regards,
Eusebiu

[AndreG]

Thanks Eusebiu, just sent the email now.

[Eusebiu]

Hi,

I looked over the files that you sent and I noticed that you have the "Run as administrator" option checked in the "Install Parameters" page and for your custom action, too.

Please keep in mind that the "Run under the LocalSystem account with full privileges (no impersonation)" already sets the custom action to be executed with full privileges, so you do not need to set the "Run as administrator" option anymore. Sometimes they may conflict with each other.

So, can you please uncheck the "Run as administrator" option for your custom action and see if it works?

Best regards,
Eusebiu

[AndreG]

Thanks for the info.. I didn't actually have the "Run as Administrator" option checked when I first created these custom actions, but I did change a number of different settings trying to get it to work. I'd also like to create a new project with only this custom script and see if that makes any difference.

My work day is about to end (GMT+2), so I'll dive into this again first thing tomorrow morning and let you know how it goes.

[AndreG]

So, can you please uncheck the "Run as administrator" option for your custom action and see if it works?

Disabling this option for the custom action itself (no other changes from the file I sent) still doesn't update the file and results in the following log output:

Code: Select all

Action 09:22:22: SchedulerAddMysqlUser. 
Action start 09:22:22: SchedulerAddMysqlUser.
SchedulerAddMysqlUser: 
Action ended 09:22:22: SchedulerAddMysqlUser. Return value 1.

However, when I disabled the custom action "Hide program's window" option, and then commented out the "echo off" line and added a "pause" before the final quit statement in my script, I discovered something interesting. The actions that try alter information in my target text file fail with an "Access is denied" error, as seen below:

Code: Select all

...

C:\Windows\system32>call:UPDATESCHEDULER

C:\Windows\system32>set "SCHEDULER_TEMP=scheduler-temp.ini"

C:\Windows\system32>if "|-a|" == "|-a|" (
echo adding "mysqlpassword=null" to "C:\NortechSystems\scheduler.ini"...
 "C:\Windows\system32\find" /c "mysqlpassword=" "C:\NortechSystems\scheduler.ini
"   1>nul  && echo key already exists   && goto:EOF
 type "C:\NortechSystems\scheduler.ini" 1>scheduler-temp.ini
 echo mysqlpassword=null 1>>scheduler-temp.ini
 move /y "scheduler-temp.ini" "C:\NortechSystems\scheduler.ini"  1>nul
 goto:EOF
)
adding "mysqlpassword=null" to "C:\NortechSystems\scheduler.ini"...
Access is denied.

C:\Windows\system32>pause
Press any key to continue . . .

I decided to make a few duplicates of this custom action and use a different combination of settings, at which point I discovered that setting the execution time to "Immediately" and removing ALL references to running the custom action as administrator was the only way it works. I can't think of any problems with using "immediately" instead of "deferred", and the setup is already launched with administrative access, so I believe this may have resolved my issue.

I'll try this on a few different machines to be sure first, but so far it's looking pretty good.

[Eusebiu]

Hi,

I'm glad you got this working. Thank you for the feedback.

Best regards,
Eusebiu