Mystery Reboot request

[NewsArchive]

I was playing with the idea of Rebooting after install.. decided in the
end not to go for it.
So I commented out the code (see pic).

However, after compiling and running (server times!) SB tells me that a
reboot is required and offers the dialog for that.
Why is this?
And how can I stop it?

Steve Bywaters

[NewsArchive]

[ more]
Sometimes the installer is called (CHAINed) directly from the program it is
designed to install.
I'm wondering if, in those circumstances, SB is being 'fooled' into thinking
that the program is still running.

Looking at the screen shot of script extract, you can see that I put a 3
second pause for the calling exe to 'disappear' - but I still usually get
*one* appearance of the message dialog telling me that the program is still
running!
When I retry, all is well.

But is that one failure enough to indicate to SB that a Reboot is required?

Also, any idea how I can stop the first *erroneous* detection (and thus
appearance of the 'already in use' message)?

Hope this is clear..... <g>

Steve Bywaters

[NewsArchive]

> However, after compiling and running (server times!) SB tells me that a
> reboot is required and offers the dialog for that.
> Why is this?
> And how can I stop it?

It happens because your installer replaced one or more locked (in-use)
files. Windows has to be rebooted in order to complete the installation.
The installer does not display this message just for fun, so you should not
ignore it. To disable this reboot message (not recommended!), you can
disable the reboot feature.

Set Installer Flag $SB_RESTARTFLAG$ to "0"

Again, not recommended at all!

Regards,

--
Friedrich Linder
Lindersoft
www.lindersoft.com
+1.954.252.3910

SetupBuilder "point. click. ship"
Create Windows Vista ready installations in minutes

-- Official Comodo Code Signing and SSL Certificate Partner

[NewsArchive]

I understand your point re. the danger, and I wish to do this the 'correct'
way.

Sometimes, the circumstance of upgrade will be that the installer *will* be
called from the program-it-is-designed-to-replace (.exe)
Now surely, if the installer is being CHAINed from the (previous version)
target EXE, then it is no longer "in use"?

And that is why I put in the initial 3 second delay - to give the CHAINing
program (the caller) time to properly 'disappear' from the O/s, so there
would be no locked/in-use files!

But I'm not getting that result - is there somethting else I should be
doing or checking?

Steve Bywaters

[NewsArchive]

> Sometimes, the circumstance of upgrade will be that the installer *will*
> be
> called from the program-it-is-designed-to-replace (.exe)
> Now surely, if the installer is being CHAINed from the (previous version)
> target EXE, then it is no longer "in use"?
>
> And that is why I put in the initial 3 second delay - to give the CHAINing
> program (the caller) time to properly 'disappear' from the O/s, so there
> would be no locked/in-use files!
>
> But I'm not getting that result - is there somethting else I should be
> doing or checking?

Perhaps your application needs more time to completely close down. What you
can do from the installer is to check (in a Loop) if the application is
still active.

--
Friedrich Linder
Lindersoft
www.lindersoft.com
+1.954.252.3910

SetupBuilder "point. click. ship"
Create Windows Vista ready installations in minutes

-- Official Comodo Code Signing and SSL Certificate Partner

[NewsArchive]

Hi Steve,

> Now surely, if the installer is being CHAINed from the (previous version)
> target EXE, then it is no longer "in use"?

Don't use Clarion's Run or Chain to start the installer. Use ShellExecute
and then halt the program. That will force termination of the application.

Best regards,

--
Arnór Baldvinsson - Icetips Alta LLC
Port Angeles, Washington
www.icetips.com - www.buildautomator.com

Icetips product subscriptions at http://www.icetips.com/subscribe.php

[NewsArchive]

> Don't use Clarion's Run or Chain to start the installer.

Ok...
... why not?

Steve Bywaters

[NewsArchive]

Hi Steve,

>> Don't use Clarion's Run or Chain to start the installer.
>
> Ok...
> ... why not?

Because internally they use CreateProcess api which cannot run an elevated
program correctly from a non-elevated program in UAC mode in
Vista/W2K8/Win7. ShellExecute and ShellExecuteEx do not have that problem.
See my blog about this at:

http://www.icetips.com/blog/index.php/2008/11/11/run-programs-elevated-on-vista

and some more resources:
http://www.codeproject.com/KB/vista-security/UAC__The_Definitive_Guide.aspx
http://www.codeproject.com/KB/vista-security/VistaElevator.aspx

Best regards,

--
Arnór Baldvinsson - Icetips Alta LLC
Port Angeles, Washington
www.icetips.com - www.buildautomator.com

Icetips product subscriptions at http://www.icetips.com/subscribe.php

[NewsArchive]

That's what I thought.. but my 'mystery reboot' is occurring on standard XP.

Steve Bywaters

[NewsArchive]

Hi Steve,

> That's what I thought.. but my 'mystery reboot' is occurring on standard XP.

No idea, I was simply commenting about your statement about chaining the
installer/webupdater. If you are building a general installer, you will run
into this issue on Vista, Windows Server 2008 and Windows 7.

Best regards,

--
Arnór Baldvinsson - Icetips Alta LLC
Port Angeles, Washington
www.icetips.com - www.buildautomator.com

Icetips product subscriptions at http://www.icetips.com/subscribe.php

[NewsArchive]

> It happens because your installer replaced one or more locked (in-use)
> files.

I can't see where that would have happened (since I'm checking the 'active'
status of the target app and blocking install until clear).

Maybe you can shed a little light on the inner workings of what sets
$SB_RESTARTFLAG$ : in this script extract below, do I
assume that $SB_RESTARTFLAG$ is set to 1 when the function Detect Active
Application("%APPLICATIONEXE%") returns 1?

And if subsequently (upon user-retry) that function returns 0, does
$SB_RESTARTFLAG$ get reset back to 0?


Sleep for "3" seconds
Loop
Set Variable %ISRUNNING% to FUNCTION:Detect Active
Application("%APPLICATIONEXE%") [Application File Name]
If %ISRUNNING% Equals "1" Then
Display Message Box "You must close Store Manager before trying to
inst..." -- "Store Manager is already running!"
If %_SB_RETURN% Does Not Equal "$IDRETRY$" Then
Exit Installation
End
Else
Break Loop
End
Sleep for "1" seconds
End


thanks
Steve

[NewsArchive]

CHAIN is not a good idea for updates in the Vista era anyway, because a
process started asInvoker cannot directly launch a requireAdministrator
process.

Better for your app to use ShellExecute to launch the update. Then you can
have your app terminate after it launches the update, and/or have the update
check whether the main program is running. (You've no doubt noticed that
SetupBuilder's own update will tell you that you need to close the app
before the update can continue).

Jane Fleming

[NewsArchive]

Yes - however for now I'm trying to isolate what's causing the reboot
trigger on a 'simpler' O/s, without the extra complications of Vista et al.

Steve Bywaters

[NewsArchive]

> I can't see where that would have happened (since I'm checking the
> 'active' status of the target app and blocking install until clear).

It's very simple. The restart flag is set if a locked file has to be
replaced. That's it -- nothing more or less. The installer asks for a
reboot, so it detected one (or more) in-use files.

BTW, your use of "Detect Active Application" does not have anything to do
with the status of $SB_RESTARTFLAG$.

Check the PendingFileRenameOperations registry value to see what has to be
replaced at restart.

HTH,

--
Friedrich Linder
Lindersoft
www.lindersoft.com
+1.954.252.3910

SetupBuilder "point. click. ship"
Create Windows Vista ready installations in minutes

-- Official Comodo Code Signing and SSL Certificate Partner

[NewsArchive]

> Don't use Clarion's Run or Chain to start the installer. Use ShellExecute
> and then halt the program. That will force termination of the
> application.

Went to check the two installed exes - found I had already done this
replacement on one but not the other... I'm half-ahead of the game <g>

Not the cause of this problem, but something to fix up anyway.

Tx

Steve Bywaters

[NewsArchive]

> Check the PendingFileRenameOperations registry value to see what has to be
> replaced at restart.

What a fantastically useful piece of info! Thanks for that.

Ironically, the file in question was *not* one of my own creation but a font
file - referring to another of our threads - because I did NOT (yet) wrap it
in a 'check if font is being used' <G>

Steve

PS May I strongly suggest that you add this little nugget into the help
file?
(Perhaps in the 'Detect Active app' or Reboot sections)
It enabled me to go directly to the file causing the reboot - I am sure I
would not be the only one that this would help and who doesn't yet know
about this.