SB Installer Hanging, then files are deleted

[NewsArchive]

Our support manager sent me a message, commenting that some of our
dlls (like CLARUN.DLL) are mysteriously disappearing. Then we received
some additional information from the customer, where the installer was
run:

>Being curious, I checked Task Manager, and sure enough, I see:
>iesrel.1805.130.exe is still running, under IESADMIN, and is using
>20-25% of the CPU.
>
>It looks to me like your update program never fully closes, and when
>the reboot forces it to close, it removes whatever files it was using.

Note that iesrel.1805.130.exe is the installer. The reboot is an
automatic one that occurs at 4am Sunday morning.

I don't know whether it looks to them like the installer actually
finished. I've asked for clarification on that.

If the installer was "finished", but got hung up before exiting (for
some mysterious reason), would a forced reboot cause any of the
installed files to be deleted?

Does this make any sense? Would it be helpful if I sent you the script
to check it out? How easy is it to turn on logging, so that I can
determine what's happening inside the script?

Mike Hanson
www.boxsoft.net

[NewsArchive]

Hi Mike,

> If the installer was "finished", but got hung up before exiting (for
> some mysterious reason), would a forced reboot cause any of the
> installed files to be deleted?

First of all, if a SetupBuilder installer got hung-up before exiting, a
forced reboot would *not* cause any of the installed files to be deleted.

But, and it seems there is always a 'but' in life <g>, it's very well
possible (99.99%) that Windows removed previously locked files after a
restart.

Scenario: let us assume, we have a "sbuilder.chm" help file located in
folder c:\reboot. We open this CHM file to "lock" it. Now let's run an
installer to replace the file with a new version. The installer detects the
"in-use" file. Because you can't replace "locked" files, the installer
writes the "new" file to the temporary Windows location and register the
"old" and "new" file names in the "PendingRenameFiles" registry. At the end
of the installation, the installer asks the user (that's the default
behavior) for a reboot. Without a reboot you have an incomplete
installation. Of course, you can disable the reboot and you can even let
the installer reboot the machine silently.

When the machine starts up, Windows replaces the "old" file with the "new"
one. And here comes the interesting part: what happens if, for whatever
mysterious reason, the "new" temporary file is not accessible (or does not
exist). Then Windows removes the "old" file without any warning.

The above is a typical "files are mysteriously disappearing" scenario.

> Does this make any sense? Would it be helpful if I sent you the script
> to check it out? How easy is it to turn on logging, so that I can
> determine what's happening inside the script?

Because it's not caused by SetupBuilder, the script would not help. And
installer logging would not help because Windows removes the files.

One way to solve this kind of issue is: set the temporary file folder away
from the standard temporary Windows folder using the "Set Temporary File
Folder..." script action. Make it independent from the "standard" temporary
Windows folder which might (under certain circumstances) only be accessible
from a specific "profile".

Does this help?

Friedrich

[NewsArchive]

Thanks for the detailed explanation, Friedrich. That may explain
what's happening. I'm also wondering whether it could be the
false-positive problem that you resolved resently, with the AV program
holding the installer in a "suspended" state, which might put the
files that it's installing in jeapordy.

I've just upgraded that system to the latest SetupBuilder. I'll ask
the support guys to keep a close eye on it, and see if we can get any
more information.

Note that I'm battling what they're comfortable with. Previously, they
used a self-extracting RAR. There was no intelligence to it (which
meant that it couldn't ask people to get out, etc.) At least it
immediately reported whether files were in-use, and refused to
proceed, which has become a touchy point.

I tried to implement the option to check for inuse files before
proceeding, but with many files in our system, it would become
unresponsive for a long time (sometimes a few minutes), checking for
that.

As an alternative, I've begun logging the in-use files, just so that
we have a record of which files collided. It's not as "good" as the
support guys want it to be (as they fondly recall the days of RAR).

Thanks again.

Mike Hanson
www.boxsoft.net

[NewsArchive]

Friedrich,

>
>Scenario: let us assume, we have a "sbuilder.chm" help file located in
>folder c:\reboot. We open this CHM file to "lock" it.

I assume this goes for any .EXE also.

The Updater I made with SB checks for *.EXE and some .TPS in use and prompts
the admin at the very begin, then quits.

I should be fine then, because its no un-attended installation.

From what I read und understood in Mikes post, his updater is running automated
and un-attended.

Regards,
Wolfgang Orth
www.odata.de

Please note:
From time to time it happens, that I overlook a reply to my postings.
Please don't be angry.
In case of an emergency, try to contact me via mail.

Bitte beachten:
Von Zeit zu Zeit passiert es mir, dass ich Antworten auf meine Postings übersehe.
Bitte nicht böse sein.
Im Notfall bitte Kontakt per Mail versuchen.

[NewsArchive]

Hi Wolfgang,

>>Scenario: let us assume, we have a "sbuilder.chm" help file located in
>>folder c:\reboot. We open this CHM file to "lock" it.
>
> I assume this goes for any .EXE also.

Yes, absolutely. .EXE, .DLL, etc.

> The Updater I made with SB checks for *.EXE and some .TPS in use and
> prompts the admin at the very begin, then quits.
>
> I should be fine then, because its no un-attended installation.
>
> From what I read und understood in Mikes post, his updater is running
> automated and un-attended.

Scenario: your app checks for "in-use" files. At check time, the installer
did not detect any locked file and continues. One millisecond later,
"something" suddenly locks one file (for whatever reason, e.g. real-time
monitoring from the protection software). Replace at reboot kicks in.

In Mike's case there is a very specific reason behind the "files are
mysteriously disappearing" Windows problem. The temporary Windows folder
from the profile that registered the in-use files to be replaced at reboot
was not accessible from the profile that was active after the reboot.

Friedrich

[NewsArchive]

>Scenario: your app checks for "in-use" files. At check time, the installer
>did not detect any locked file and continues. One millisecond later,
>"something" suddenly locks one file (for whatever reason, e.g. real-time
>monitoring from the protection software). Replace at reboot kicks in.

After a reboot, the installation is fully updated then.

Great!

In a network environment you never know, when foilks start a program, that is
accessible for them with a desktop.LNK. So things like you describe with that
"millisecond later" are possible.

In my Updater I tried to cover what is possible from my side - and Setupbuilder
cares for the rest!


Regards,
Wolfgang Orth
www.odata.de

Please note:
From time to time it happens, that I overlook a reply to my postings.
Please don't be angry.
In case of an emergency, try to contact me via mail.

Bitte beachten:
Von Zeit zu Zeit passiert es mir, dass ich Antworten auf meine Postings übersehe.
Bitte nicht böse sein.
Im Notfall bitte Kontakt per Mail versuchen.

[NewsArchive]

Hmmm. I suppose that's possible. The installer will be run by a user,
but I assumed that any queued renames at start-up would be done by
some type of "meta account", with the ability to reach anywhere. If
not, then I may have to experiment with that altered temp folder, as
you suggested.

Mike Hanson
www.boxsoft.net

[NewsArchive]

The installer is not unattended, but according to one report, it was
still sitting in memory chew up a bunch of CPU when an automated
reboot happened. If some files were locked when this happened, then
perhaps Windows deleted them.

I'm hoping to get more information to confirm whether things are
better.

Mike Hanson
www.boxsoft.net

[NewsArchive]

I'm trying to use "Set Temporary File Folder". I've decided to use a
folder beneath the chosen installation folder, as this is the shared
program folder, and they should all have access to it. However, it
didn't seem to put any "In Use" files there. (It used the regular
Windows TMP folder.)

Then I tried creating the folder before installing any files, but that
didn't help.

Do I need to execute that "Set Temporary..." value eary in the script?
Is it too late to do it after I've asked the user for the destination
folder. (I had hoped it would be sufficient to do it right before I
started to install files.)

Mike Hanson
www.boxsoft.net

[NewsArchive]

> However, it didn't seem to put any "In Use" files there.

See attached screenshots. You only have to set it to an existing (writable)
folder before the replace actions take place.

In this case, our temporary file folder is set to %_SB_INSTALLDIR% which
points to c:\reboot. The sbuilder.chm file is in-use and locked. The
installer writes the "new" sbuilder.chm to c:\reboot\~SB419B.tmp. After the
reboot, Windows deletes the "old" sbuilder.chm and renames ~SB419B.tmp to
sbuilder.chm.

Friedrich

[NewsArchive]

Thanks, Friedrich. I'll let you know if this doesn't solve the
problem.

Mike Hanson
www.boxsoft.net