InstallAware

BUG: Intermittently when using the RunProgram call in our Installaware script with...
Hide Program Window: Checked
Wait for Program To Finish: Checked
The program executes however the RunProgram call seems to randomly display a MessageBox
with an error displayed as....
'The operation returned because the timeout period expired.'
OR
this error...


Once this error messagebox is dismissed, the next page is displayed and proceeds as usual.

Environment: Windows Server 2008 R2 (x64)
Installaware Build Environment: Installaware 9 R2

Anybody seen this?
Any information related to this issue is appreciated.

Can you reproduce this with any program, or is it specific to the program you are using?

Does it occur only with Run Program, or also with Run Program As?

In a script that does nothing other than call your program, is the issue still present?

Hi Michael,
thanks for responding.
Unfortunately, this doesnt always reproduce.
This seems to happen once every 4-5 times.
We havent seen this happen except with the execution of the specific app during this section in the code.
We have not seen this occur on x86 platform.
We dont use the Run As command, so I couldn't really say if it happens there too.
I havent run this in a IA script stripped down to just making this call, however I have my doubts that it is the application we are calling the Run Program with as the root cause.
FYI, the application the Run Program command is running works just fine and produces the correct output that it should.
It is the pesky error messages that are randomly popping up.
So, to be clear, this is happening IN the Run Program code, not our script code, so we have no control over it.
IOW, it is in the Run Program call itself or your IA runtime engine.

Is there verbose logging from the install command line that can be used to generate a verbose log to help get to the root cause?
We are closing in on our release date and this is going to be an issue for our customer support.

Even if the issue is not always happening, if you are to send us a minimum script that launches your program over and over for instance, we should be able to see the problem.

Run Program is a straightforward operation and there is nothing in it that could cause the message you are seeing to be displayed. This hasn't been reported by anyone else either - I am sure we would have had a few more reports by now. This is why I inquired about the application you are running.

Did you try the Return Result in Variable field in the command window to see whether you can obtain an error code that way when the dialog is actually shown? The call already has its own internal error trapping and checking, which points me towards the application being run yet again as to the source of the dialog.

Finally, the title of the dialog does not match the title of your installation wizard or your project name - I strongly doubt this message is coming from InstallAware.

Hi Michael,
First, it would be very helpful if you could answer my last question regarding logging...
Is there such a logging setting in IA that will allow us to get a verbose log?
Does this verbose logging allow for detailed information about the execution of the IA script?

Secondly, you are assuming we dont change the title of the install at runtime, which we do.
Here is snapshot of the project info...

This title, other than a case change of the text, matches the MessageBox title window as you can see.
So, saying this isnt being generated from IA doesnt seem correct.

The Run Program is calling a .NET based console application called SQLServerHelper.exe.
This CLI app does NOT display ANY messageboxes during execution, certainly not one with that caption.
Here is a snapshot of the code where this issue is happening...




So, from the code, you can see that we DO trap the return value/message and we DO display a message box if there was a failure.
Here is the message box property dialog...


So, as you can see, that message box would NEVER display the message you are seeing, but rather something quite different.
What is interesting is what you are saying about the trapping and checking of the application that you are running?
How does this work exactly?

Also, notice that based on the return value we read from the ini file, we do forward to another page with a GoToLabel.
Could there be something else here?
Also of note and quite possibly irrelevant is that this page has an animation on it as does the page it is forwarding to.

Please keep an open mind here.
It is entirely possible that the interaction with our CLI is manifesting this issue.
Based on the information I have, it seems like this is not something within our control, hence going to the trouble of bothering y'all in the first place.
If I thought it was something we were doing, I would make changes to address it.
I am certainly willing to make any changes to the CLI app if it would help find the root cause.
Also note that this same CLI app is called on the next page again.
We havent seen that page throw this error
I understand that you are saying that nobody else has reported this, however that doesnt mean there may not be an issue here.
I am trying to find a solution to the problem just like you.

There is no logging for Run Program - since the function already has its own return parameter.

The casing of the message box and your project title is still different - which doesn't help identify the issue.

I am as curious as you are to find the cause of this problem! Unfortunately there's nothing to go on so far.

I think it'd still be worth your while to write a setup that just loops on and on calling this program so you can get the error message and find out what the return value of the function is. If you can get it reproduced with any consistency, we can be of further help at our end

Michael,
you are pretty convinced that this is our CLI app that is displaying the MessageBox.
OK, so if it IS displaying a MessageBox, the process would have to be running, right?
Well, it is not.
It is not our CLI app creating this MessageBox, period.

I cannot get this to repro everytime.
Writing a sample install seems like a Red Herring as it isnt representative of what we are doing in the code.
It is very possible we are doing something in our script that is causing this to sometimes happen, however it isnt a direct correlation.

We never saw this issue until migrating to IA9R2 and running it on x64.
Also, I am not asking for a log file for the Run Program call but rather the entire execution of the IA engine to see if it indicates any issues.
Are you telling me there is no logging at all that can be enabled that shows the IA engine execution?
So what do you when you run into issues with customers and need to triage the issue?

Also, I ran the program we are calling with Run Program dozens of times in a loop and it always runs without issue.
There is NOTHING in our code that displays this MessageBox and we do check all the return values from the Run Program call.

Your last statement is a bit disturbing.
I am pretty convinced there is an issue here and you are telling me unless I can get consistent repro, Installaware is not willing to have a look at it.
IOW, unless an issue occurs all the time, there is no bug in IA?
Are you kidding me?
I understand that it is more difficult to triage and debug the issue here because of the lack of a consistent repro, but you are pushing back on every one of my requests.
I am more than willing to ship you the IA code, project, and completed install to get to the bottom of this if that will help.

What is the error code you get from the Run Program call? If there is no error code returned, this means the API call is actually succeeding. This is all we can know for sure.

Again, I would suggest you to try Run Program As, to see if that solves the problem.

Hi Michael,
couple of clarifications...
First, this project was migrated from IA7, not IA9.
Second, the process is always being properly executed by the Run Program and hasn't ever returned an error, simply success.
My point in telling you about the process not being present (in the active process list) when the MessageBox is actively displayed rules out any possibility that the CLI app is displaying the MessageBox.

Remember, the REAL problem here is the IA setup is displaying an MessageBox indicating there was a problem.
Sometimes the error in the MessageBox is...
'The operation returned because the timeout period expired'
sometimes the error in the MessageBox is...
"Unspecified error'
Upon clicking the OK button to this Messagebox, the setup continues without issue.

So, you are telling me there is NOT logging we can enable to get more information? Is that correct?
You are telling me there are no tools that you have to attach to the IS setup to get more information?

Michael,
FIrst, I think that you are right, this forum is not the best vehicle for resolving the issue.
I am willing to try anything to fix this
I am happy to change from Run Program to Run Program As if that will solve the problem (assuming the username and password can be empty).
As far as where this is actually occurring in the IA script/code, I can't really say.
It may be related to the code immediately after the Run Program returns when the next page is being forwarded to.
I have removed a AVI that was being displayed on that page to show progress in the off chance that it may be related.
I replaced it with the standard progress bar in Marquee mode.

In terms of your statement about logging, every software development company I have worked with/for has integrated the ability to log additional information in their platform.
Microsoft, Symantec, etc. all have the ability to enable logging for different subsystems in their code.
If this isnt built into your runtime engine, thats fine, I will move on to a different strategy to see what is going on.

We have a site where we can upload the kit and you will be able to download it from that location.
Also, not a problem on the support incident, understood.

We are continuing to QA with the a new build that came out today.
I will be getting the WinDbg debugger on the next repro of this issue and will create a memory dump.
If the message box is within the setup.exe, we will see it.
This may may be helpful for your dev team.

Have a good weekend.

As far as logging goes, just run setup.exe with the /l parameter (the help file contains the necessary parameter details).

Cool.
Thanks.

Hi Michael,
We have a Hyper-V virtual machine snapshotted with the error reproduced.
We can also zip up all the project files as well and post them.
We are looking at how to get it up on our site so you can get access.

Also of note, I also used ProcessExplorer to show you the callstack of the IA produced EXE.
Based on the call stack in the main thread of the IA produced setup exe, the MessageBox is definitely coming from it as you can see below.

Can you please produce in VMware - we don't use Hyper-V here.

How big are your files? It may make sense to mail in a DVD instead.

Hi,

Was this issue ever resolved? I'm getting the exact same problem with my setup package. This error only occurs on a 64 bit system, as I've tested it successfully on both XP and 32-bit 7. My error appears at the final screen of the setup, without needing to click Finish.

Any ideas?

Thanks,
Gary