|
#1
|
|||
|
|||
#2
|
|||
|
|||
Thanks for the quick reply. I'll give some of those a try.
Jeff |
#3
|
|||
|
|||
I tried the following from that thread:
- I called the child scripts as a console app (made the problem worse) - Added the /mta option (no change) - Set the affinity to 1 (no change) Since the problem was on a Win XP machine with 512 MB RAM, I tried the scripts on a Win 7 machine with 4GB RAM. The hang-up still occurred. However, I was able to get some additional information with Win 7 that is shown below. Problem Event Name: APPCRASH Application Name: VisBuildPro.exe Application Version: 7.7.1.1 Application Timestamp: 4e0a3b95 Fault Module Name: ScriptSn.20110620173350.dll_unloaded Fault Module Version: 0.0.0.0 Fault Module Timestamp: 4d2ce466 Exception Code: c0000005 Exception Offset: 69db5262 OS Version: 6.1.7600.2.0.0.256.48 Locale ID: 1033 Additional Information 1: 0a9e Additional Information 2: 0a9e372d3b4ad19135b953a78882e789 Additional Information 3: 0a9e Additional Information 4: 0a9e372d3b4ad19135b953a78882e789 Since the Win 7 machine has 4GB of RAM, I doubt that is the problem. As mentioned in the first post, the child script does not hang at any particular step. It finishes completely, but never seems to exit. |
#4
|
|||
|
|||
It doesn't sound like a hang, more like the build completes but the process doesn't go away for some reason (not something we've seen before). Did the problem just start occurring recently, and any ideas what might have changed when it started?
One possible workaround would be to configure the step that calls the child build to terminate after some amount of time (longer than what the build would normally take). http://www.kinook.com/VisBuildPro/Ma...tepfailure.htm Please send the .bld files, details on how they are launched (scheduled task, manual launch, etc.) and any other info from http://www.kinook.com/Forum/showthre...?threadid=3044 that could help us reproduce the problem. Thanks. |
#5
|
|||
|
|||
Nothing has really changed. I am in the process of developing the scripts and now that I started to do some heavier-duty testing, I have been seeing this issue.
I decided to start simplifying things and got down to a 'master' script that loops 20 times calling a dummy child script (the child script does only a 2 second wait). I have not had any success in completing 20 iterations of the loop yet. Those files are attached. EDIT: The simplified test scripts work fine on the WinXP machine. The About/Install Info: Visual Build Professional 7.7a Registered to: xxxxxxxxxxxxxxxxx (2-computer license) Windows Version: 6.1.7600.0.0 Install path: C:\Program Files\VisBuildPro7 HideConsole.exe version 1.0.0.0 SftPrintPreview_IX86_U_20.dll version 2.03 VisBuildCmd.exe version 7.7.1.1 VisBuildPro.exe version 7.7.1.1 VisBuildAct.dll version 7.7.1.1 VisBuildCore.dll version 7.7.1.1 VisBuildDotNET.dll version 7.7.0.3 VisBuildExt.dll version 7.7.1.1 VisBuildMisc.dll version 7.7.1.1 VisBuildMS.dll version 7.7.1.1 VisBuildMS2.dll version 7.7.1.0 VisBuildNet.dll version 7.7.1.1 VisBuildSvr.dll version 7.7.1.1 VisBuildSvr.Interop.dll version 1.0.0.0 VisBuildVCS.dll version 7.7.1.1 Last edited by snapjeff; 03-21-2012 at 04:17 PM. |
#6
|
|||
|
|||
In our tests, the scripts always complete as expected (tested on Win XP SP3 and Win7 x64, via Remote Desktop).
|
#7
|
|||
|
|||
I started removing parameters passed to the child script (I continued to use the dummy child script that does only a 2 second Wait) and found that by not passing the global script file to the child script, the child script will always return.
Thinking that perhaps the parameter ordering was an issue, I put the /script switch in the additional options and it behaves the same as if I added the global script file 'normally'. I have created my own global macros, scripts and subroutine steps files that are not stored in the configuration files path, but I am supplying the full path for these files in the options tab of the VisBuildPro action. Any ideas? Jeff |
|
|