Reboot & Resume problem

[NewsArchive]

Hi Friedrich

Using that script I emailed you over the weekend, the OSQL commands (lines
217-224) dont work if the installer program has done a reboot & resume.

At the end of installation, if I cancel the reboot and run the same
installer program again, the OSQL commands works.

Any ideas how I can get around this problem, is this some sort of elevation
problem?<g>

BTW its on XP I've noticed this problem havent tested any other OS's yet.

--
--
Cheers
Richard

[NewsArchive]

Hi Richard,

> Using that script I emailed you over the weekend, the OSQL commands (lines
> 217-224) dont work if the installer program has done a reboot & resume.
>
> At the end of installation, if I cancel the reboot and run the same
> installer program again, the OSQL commands works.
>
> Any ideas how I can get around this problem, is this some sort of
> elevation problem?<g>
>
> BTW its on XP I've noticed this problem havent tested any other OS's yet.

The question is, is the OSQL command executed at all?

"Reboot and Resume" does the following (nothing more and nothing less). It
stops the script and writes the Run registry key that contains the name of
the setup program to run when the computer starts. Then it reboots the
system and Windows starts the installer again. The installer has now the
%_SB_RESUME% variable set to 1. Please note that it doesn't resume where it
left off!!!

I would add a "Display Message Box" script command one line before your OSQL
call to see if the code is executed at all.

Does this help?

Friedrich

[NewsArchive]

And please check the values for %_SB_ERRORCODE% and %_SB_RETURNEX% after
execution of one of the OSQL commands. Perhaps this gives us more
information.

Friedrich

[NewsArchive]

Hi Friedrich

I'm currently install W7 64 on my host machine (clean install not upgrade)
and have just upgraded to VMware 7 as well to try to eliminate those crashes
I mentioned previously during or after compile in SB7. I'll change the
script to check for errors for the OSQL commands later on today, but in
answer to your previous post, none of the OSQL commands are running if the
system has rebooted but do work if I immediately run the install program
again without a reboot.

I'll let you know how I get on.<g>

Cheers

Richard

[NewsArchive]

Hi Richard,

> I'm currently install W7 64 on my host machine (clean install not upgrade)
> and have just upgraded to VMware 7 as well to try to eliminate those
> crashes I mentioned previously during or after compile in SB7. I'll change
> the script to check for errors for the OSQL commands later on today, but
> in answer to your previous post, none of the OSQL commands are running if
> the system has rebooted but do work if I immediately run the install
> program again without a reboot.
>
> I'll let you know how I get on.<g>

Okay :)

BTW, I noticed two things:

1. You do not have defined a Default Directory for your OSQL calls. I would
suggest to set the default directory to see if this makes a difference.

2. (has nothing to do with this problem) You have hard-coded "C:\Program
Files". This will cause problems if the Program Files folder is not named
C:\Program Files <g>.

Friedrich

[NewsArchive]

You mean... he might get "eighty-sixed" ?? <G>


> This will cause problems if the Program Files folder is not named
> C:\Program Files <g>.
>
> Friedrich
>

Jane Fleming

[NewsArchive]

>
> You mean... he might get "eighty-sixed" ?? <G>
>

Exactly <g>

Friedrich

[NewsArchive]

yuk yuk yuk

Jeff Slarve

[NewsArchive]

Hi Friedrich

I think I've found the problem and have attached an example script to show
the problem.<g>

I've taken your advice and added in some lines to trap for the errorcodes
and returnex code and am using the CSIDL program files in my main script as
well. <g>

Basically if the window is hidden then it doesnt work, but if its not hidden
then it works even though its identical code.<g>

I havent tested this on anything other than XP at the moment, but to test
this you'll need an XP 32bit instance and then install these updates from MS
in the order shown.

http://download.microsoft.com/download/0/6/1/061F001C-8752-4600-A198-53214C69B51F/dotnetfx35setup.exe
http://download.microsoft.com/download/7/3/4/7345bb7d-0b07-40e8-9480-5b8c55b9c8b7/WindowsXP-KB926139-v2-x86-ENU.exe
http://download.microsoft.com/download/2/6/1/261fca42-22c0-4f91-9451-0e0f2e08356d/WindowsXP-KB942288-v3-x86.exe

Then you will need to install MS SQL 2008 Express, you've got a fairly up to
date copy of the script so you can see whats going on in more detail if you
need it. <g>

Then run the attached script. You will get an Error of 1 for the SBErrorcode
for the hidden window and no db will be created, but the unhidden window
will work.

Now I know I could for a workaround run the windows unhidden but these OSQL
commands are being used as a workaround to installing the SQL script on the
users machine, running it then deleting it as I dont want the user to know
what the username & passwords are to gain access to the db.

I've also sent you an email privately as well.<g>

Cheers

Richard

[NewsArchive]

Hi Richard,

> Basically if the window is hidden then it doesnt work, but if its not
> hidden then it works even though its identical code.<g>

I fear there is nothing that I can do to help :-( If you are using
ShellExecuteEx to run OSQL "hidden", then the nShow fMask is set to SW_HIDE.
Nothing more or less.

http://msdn.microsoft.com/en-us/library/bb759784(VS.85).aspx

Perhaps this is a bug in OSQL? I don't know. What you can try is to use
CreateProcess instead of ShellExecuteEx (unmark the "Use ShellExecuteEx
option in your "Run Program" function). Does this give a different result?

Friedrich

[NewsArchive]

And please set the Default Directory!

Friedrich

[NewsArchive]

Hi Friedrich

If you comment out the Reboot line in the script then OSQL runs fine
regardless of whether the window is hidden or not.

Its only when the installation resumes from a reboot that the hidden window
doesnt work, thats why I said is it an elevation problem?

I'm going to try some other command lines as well and see if I can find some
other examples which show this, so we can rule out a problem with OSQL.<g>

Cheers

Richard

[NewsArchive]

Hi Richard,

> If you comment out the Reboot line in the script then OSQL runs fine
> regardless of whether the window is hidden or not.
>
> Its only when the installation resumes from a reboot that the hidden
> window doesnt work, thats why I said is it an elevation problem?
>
> I'm going to try some other command lines as well and see if I can find
> some other examples which show this, so we can rule out a problem with
> OSQL.<g>

As I understand it, you are running XP and I think (I am not 100% sure) that
XP does not have such a protection mechanism (if you are running from the
admin account).

RunOnce actions are always written to the
HKLM\Software\Microsoft\Windows\CurrentVersion\Run Once registry key.
Windows Defender blocks software that requires elevation from running from
other keys, but software in this key is treated as if it was part of an
installer and is elevated automatically on UAC-aware systems.

But you can try it. Develop a simple test.exe script that executes one of
your OSQL commands and displays the error code from the OSQL call. Place
this test.exe in, say, c:\test. Then write another dummy.exe (New | Blank
Script...) that only has one "Add RegistryRunOnce Entry" function to add
c:\test\test.exe to the RunOnce key. Reboot the machine and Windows will
execute c:\test\test.exe.

Friedrich

[NewsArchive]

Hi Friedrich

I havent got Windows Defender installed on this test XP machine but I'll
give this a go.

Cheers

Richard

[NewsArchive]

Hi Richard,

> I havent got Windows Defender installed on this test XP machine but I'll
> give this a go.

From the technical point of view, there should not be a reason that OSQL
executes fine if the ShellExecuteEx nShow fMask is not set to SW_HIDE but
fails if SW_HIDE is enabled.

I am sure using CreateProcess() gives the same results, right?

Friedrich

[NewsArchive]

Hi Friedrich

Ok your suggestion of having a separate install program called from the
RunOnce to run the OSQL commands works.

IIRC Create Process didnt work when I called the OSQL commands.

What I think I will do is put the OSQL commands in a separate installation
and then call them from the main install script, I cant see why that wouldnt
work either and would be easier than trying to coordinate two install
programs run independently at the same time.

Cheers

Richard

[NewsArchive]

Hi Richard,

> Ok your suggestion of having a separate install program called from the
> RunOnce to run the OSQL commands works.
>
> IIRC Create Process didnt work when I called the OSQL commands.
>
> What I think I will do is put the OSQL commands in a separate installation
> and then call them from the main install script, I cant see why that
> wouldnt work either and would be easier than trying to coordinate two
> install programs run independently at the same time.

The separate install program called from the RunOnce to run the OSQL
commands simulates exactly what your main install is doing. setup.exe
registers itself in the RunOnce key and Windows re-executes it at restart.

So if this works then there is another cause for it if it fails in your real
install.

Next thing I would try is to see if it helps if you comment-out your 'Wait
Dialog: Display "Creating Database Files..."' function (or start it on a
separate thread) before running your OSQL commands.

Friedrich

[NewsArchive]

Hi Friedrich

> So if this works then there is another cause for it if it fails in your
> real install.
>
> Next thing I would try is to see if it helps if you comment-out your 'Wait
> Dialog: Display "Creating Database Files..."' function (or start it on a
> separate thread) before running your OSQL commands.


In the example script I posted earlier I dont have anything else to confuse
the situation like wait dialogs its just literally reboot, then run the OSQL
commands so I dont see how the above suggestion can help do you?<g>

I can give it go but I dont think I'll get the results I'm looking for.<g>

Cheers

Richard

[NewsArchive]

Hi Richard,

> In the example script I posted earlier I dont have anything else to
> confuse the situation like wait dialogs its just literally reboot, then
> run the OSQL commands so I dont see how the above suggestion can help do
> you?<g>
>
> I can give it go but I dont think I'll get the results I'm looking for.<g>

I agree. I was playing with your real install, not with the smaller
example. So my suggestion will definitely not change anything.

Unfortunately, I am running out of ideas. This is not a SetupBuilder issue,
but I hate it if it's not possible to find the cause for a problem <g>

Friedrich

[NewsArchive]

HI Friedrich

I've got a workaround so I'm able to get this out to beta testers which is
the main thing.<g>

Cheers

Richard

[NewsArchive]

Richard,

> I've got a workaround so I'm able to get this out to beta testers which is
> the main thing.<g>

Okay <g>

Friedrich

[NewsArchive]

Hi Richard,

> In the example script I posted earlier I dont have anything else to
> confuse the situation like wait dialogs its just literally reboot, then
> run the OSQL commands so I dont see how the above suggestion can help do
> you?<g>
>
> I can give it go but I dont think I'll get the results I'm looking for.<g>

I compiled your example script with a debug version of SetupBuilder and all
parameters are correctly passed to the OSQL command line program.

Friedrich