Setup dying at the end of a Maintenance setup
Posted 05 October 2004 - 19:39
IS DevStudio 9, Win2K pro. Setup is dying at the end of script processing during a maintenance setup. Debug shows the script executes to completion, and at that point, Setup simply stops. No window closing, no errors thrown, nada. Task manager shows it there, using memory, but absolutely no CPU. I've let this sit for a good 10 minutes or so with no changes.
Any ideas, or did I just stumble, and miss something...
Tod A. Hilty
Posted 06 October 2004 - 14:17
Hmmm. How would one go about finding an invisible dialog, that IS may've produced? Task manager shows no CPU activity, but I guess I could check to see if GDI is being used up by something. I've inherited this code from another developer, and it does get a little crazy during execution, but it's not really too nuts.
Thanks much for your response!
Tod A. Hilty
Posted 06 October 2004 - 22:46
List the processes running in memory before you run the install and compare that list to the list of processes running when your script 'dies'.
If there is an extra process still running, it could be the cause.
Posted 07 October 2004 - 14:22
Tod A. Hilty
Posted 08 October 2004 - 15:11
First off, thanks for all the help thus far. Unfortunately, after spending some quality time with the IS install, Task Manager, and Spy++, there's really nothing out of the ordinary occuring as far as batch files, or hung dialogs. The install application doesn't call any batch files, and Spy++ and Task Manager are not showing any extraneous dialogs hanging about.
I tried Stefan's suggestion of hanging setup, and killing off any processes that are running until setup frees up. At the stalling point, I killed off everything Win2K would let me kill, and setup was still sitting there, holding ~24MB of memory, and not utilizing any CPU. Spy++ reports that it's in a wait state with a wait reason of User Request. Messaging to the process is apparently occuring by Windows, so it considers setup to be alive, but setup is not talking back.
OBTW, this has now been duplicated on to other, absolutely clean Win2K machines.
It's truely bizarre. Setup runs in full screen, and when it finishes/hangs it's still in full screen. Once minimized to the task bar, it cannot be maximized again, and as a matter of fact, one cannot do anything with it. It simply remains a button, until it's finally killed with Task Manager. Even the "right click on button" menu is greyed out. The application itself has completely installed, as expected, and runs normally.
I'm stuck. But hey, at least it's Friday, eh?
Again, thanks for all of you folks' brain cycles you're letting me utilize for this problem!
Posted 11 October 2004 - 17:00
Yep, I hit return about a thousand times. Dead. Could my DevStudio 9 be corrupted somehow? I mean, actually creating a flawed installation build? I had Developer 8 installed on this machine along with DevStudio 9, and I uninstalled 8 thinking that maybe the two were creating some sort of inbred installation build.
Same problem occurs under exactly the same circumstances.
We are supposed to upgrade to ISX very soon, so I might wait and "see if the problem goes away with the upgrade". I'd still like to know just what the heck is happening, though.
Tod A. Hilty
Posted 12 October 2004 - 07:48
Posted 18 October 2004 - 13:32
Well, the re-install of DevStudio 9 produced the same results. I'm thinking that that may be a blind alley. As to whether or not this has been reproduced on other machines, the answer would be yes, with exactly the same effects.
Things that make you go "hmmm...."
Tod "Still stumped" Hilty
Posted 19 October 2004 - 17:15
Yeah, I'm running out of ideas too. It's really weird. Even when I step through the installation in the debugger, everything executes perfectly -- the only odd thing that is in that case the *debugger* hangs too -- right at the end of the OnEnd function.
It's almost like setup, for some unknown reason, doesn't think it's done when it really is. The app installs perfectly, the upgrade installs perfectly, and everything that IS put on is in it's correct place. I get the SdFinishEx dialog, displayed in the correct way. Choose to reboot, and the thing just dies.
When all the IS stuff is killed off, and the application run, it runs exactly as expected. Everything that is executed via LaunchAppAndWait, or HideAppAndWait loads perfectly without any errors. There are no batch files, no dialogs (that I can see), or any other extraneous processes running. This has been recreated about a dozen times now across a bunch of different machines.
Could it still be something in the script that's causing this?
Thanks again everyone for your help, and input. I sincerely didn't think this thread would drag out for this long.
Tod A. Hilty
Posted 19 October 2004 - 20:17
I use program block script for our companies installations. At the very end of the script I have always used the following code. As the remarks state, it was placed at the end of the script to make the last forms clear faster...
|// These four commands force the last dialog box to clear faster....|
Disable( DEFWINDOWMODE );
Disable( BACKGROUND );
Other simple things could be that the return value from SdFinishReboot() is not being passed back to the script to evaluate the value as WILL_REBOOT or NEXT (1) or < 0.
|// Debug the SdFinishReboot dialog return value.|
if (SdFinishReboot (szTitle, szMsg1, nOption, szMsg2, nReserved) < 0) then
// Indicates that the user chose to either reboot the system
// or restart Windows, but the reboot or restart failed.
MessageBox ("SdFinishReboot failed.", SEVERE);
Or, maybe there is a SdShowMsg(szMsg, TRUE) that is not closed with a SdShowMsg(szMsg, FALSE). It could have been skipped due to an opening in an if..then operation.
Thats my best last shot....
Posted 25 October 2004 - 14:03
And Stefan too...
I worship the ground on which you walk!
It *was* the SdShowMsg! Here's what was happening:
SdShowMsg was being called in the OnMoved event function. It was being taken down in the OnFirstUIAfter event function. Now, on a maintenance install, the original developer simply called the OnFirstUIBefore function if the install was an update to and existing installation. This app uses some app specific registry settings to determine if what's coming off the CD is an update, rather than the standard Installshield version checking facility. So, since IS was in maintenance mode, *and* since there was no OnMaintUIAfter function, the SdShowMsg FALSE was never being executed! I added an OnMaintUIAfter function with the corresponding takedown of the message window, and away she went! So you guys were absolutely right. It was an "invisible dialog".
So, I guess this message box is running *within* setup.exe, so that's why I wasn't seeing it in any of the "external" tools I was using?
I can't thank you both enough, and I promise to hang out on this forum, and offer any assistance I can in the same way that you guys helped me.
I've learned much from this, and also from this forum...
Tod A. Hilty