Graceful close of Inno Setup install running in silent mode

109 views
Skip to first unread message

Shawn Coffman

unread,
Oct 19, 2021, 9:17:32 AM10/19/21
to innosetup
I have a program that performs automatic updates of software. On occasion, the install will stall for various reasons (such as a machine reboot is needed). I can kill the install process without a problem. I was wondering if there was a graceful way of cancelling the installation rather than a hard kill of the install process such as a way to pass a cancel command to the install process. I know I might be reaching but I thought I would ask.

Any suggestions?

Gavin Lambert

unread,
Oct 19, 2021, 5:58:53 PM10/19/21
to inno...@googlegroups.com
When a reboot is required, the install won't stall (if run correctly),
it will exit with a particular exit code (in some cases, a different
code depending whether the reboot request is before or after the actual
install).

There are pretty much zero circumstances where killing an install
process is a sane thing to do. It sounds like you need to fix how
you're running them in the first place.

Shawn Coffman

unread,
Oct 22, 2021, 7:17:39 AM10/22/21
to innosetup
Would this be the same if a sub-installer was being called from another installer? In other words, our software has two installers. One is s sub-installer (child) that is called from w/in the other installer. On 98% of the time when run in silent mode, the install completes successfully. But there is 2% of times where it seems to stall on the sub-installer. Unfortunately, we are unable to find any logging that indicates why the sub-installer has stopped. In our investigation, we discovered the machine needed to be rebooted which lead to my statement about a reboot. 

Bill Stewart

unread,
Oct 22, 2021, 12:54:18 PM10/22/21
to innosetup
On Friday, October 22, 2021 at 5:17:39 AM UTC-6 coff...@gmail.com wrote:

Would this be the same if a sub-installer was being called from another installer? In other words, our software has two installers. One is s sub-installer (child) that is called from w/in the other installer. On 98% of the time when run in silent mode, the install completes successfully. But there is 2% of times where it seems to stall on the sub-installer. Unfortunately, we are unable to find any logging that indicates why the sub-installer has stopped. In our investigation, we discovered the machine needed to be rebooted which lead to my statement about a reboot.

IMO, the best way to troubleshoot this is that you will need to produce a minimal working example[1] that can reliably reproduce the problem.

You will need to decide if the LOE to reliably reproduce the problem with a minimal example is worth it considering you have the issue in only 2% of cases.

The problem might be sympomatic of other things, so it may be worth the effort in any case.

Gavin Lambert

unread,
Oct 25, 2021, 6:21:08 PM10/25/21
to inno...@googlegroups.com
On 23/10/2021 00:17, Shawn Coffman wrote:
> Would this be the same if a sub-installer was being called from another
> installer? In other words, our software has two installers. One is s
> sub-installer (child) that is called from w/in the other installer. On
> 98% of the time when run in silent mode, the install completes
> successfully. But there is 2% of times where it seems to stall on the
> sub-installer. Unfortunately, we are unable to find any logging that
> indicates why the sub-installer has stopped. In our investigation, we
> discovered the machine needed to be rebooted which lead to my statement
> about a reboot.

Most likely, you're missing some command line parameter telling the
child install to run fully silently and it is stopping with an error
dialog or something.

Read the docs on the command line parameters and make sure that you're
passing everything necessary. Also ensure that your child script does
not contain any calls to MsgBox or similar blocking dialog functions.

If you want more help with this, then at minimum you'll need to post
exactly what you're doing at the moment (including example code and
parameters). As Bill said, the best way is to reproduce the problem
with a MCVE -- not only does that make it easier for people to
understand and assist, but usually during the course of trying to build
one you will figure out the solution on your own.
Reply all
Reply to author
Forward
0 new messages