Thanks, I'll see if I can get it. I have version 4.0c version 5.1, and 6.6... no luck so far..

You indicated that you're accessing the build box via Remote Desktop. Is the RD connection remaining open, or does this occur after disconnecting and reconnecting? Are the builds launched manually, from a Scheduled Task, or something else? Does the problem occur when using the console app rather than GUI app? Please ZIP and send to support@kinook.com:
1) The info from Help | About | Install Info
2) The .bld file
3) A build log file from a hanging build

Thanks.

Ok, thanks for the location of the previous versions. As for you other questions:

I have only used this version thru the gui app. I can run it from the command line if you think that would help. Isn't it just the same .exe but giving the bld file as an argument?

The remote desktop stays longed in, however the screen saver puts me into the userid/password page. So when I log in it refreshes the screen and that is when I see the white screen UI hung.

I'll get you the other info on the next hang..zip it up and send it to you.

thanks

I've been seeing this for a couple weeks. It consistently hung during our nightly build that we ran from the task scheduler. We downgraded to 6.4 and it no longer hangs.

We run builds from the command line.

The odd thing is I've seen the hang when VisBuildPro was executing a compile through devenv and also when executing one of our own tools. It just stops responding and seems hung just as it excuted the command. Terminating the command VisBulidPro spawned does not resume VisBuildPro, it remains hung. I end up having to terminate VisBuildPro itself.

We'll be sticking with 6.4 for now until this problem has been addressed in newer builds. Fortunately we are not dependent on new features of the later versions.

We have implemented a change that may resolve this issue. Please download the latest from http://www.kinook.com/Download/VisBuildProEval.exe to try it.

Also try launching all VisBuildPro.exe/VisBuildCmd.exe instances with the /mta flag.

And something that apparently helped one other user was to add a Run Script (VBScript) step like this to the project:

Application.Options.RunProgramOutputWaitTimeout = 1000
Application.Options.RunProgramInputWaitTimeout = 1000
Application.Options.EnableEventErrorLogging = False

Ok, I downloaded version 6.4 and it consitently hangs after the same step. I was about to post the information, but then saw this new "test" fix. So I installed it and ran it. The first time it ran in the UI it hung on an earlier step :(

Ok, I sent you the .bld file and info files. Hopefully we can see why it is hanging.

/mta
 

Well I installed version 6.7 and running VisBuildPro.exe with the /mta option seems to do the trick. At least in the last 3 tries it did not hang. It was hanging every time at the same step. It was interesting that it only hung whan I ran it thru the UI and not while running it from the command line (with the /s /b switch).

I don't know what the /mta switch does though. You might want to try it.

I'm unfortunately still seeing hangs running this tool. I was wondering if any progress has been made on identifying the cause and fixing this freeze.

We have not been able to reproduce the problem (and not for a lack of trying), but as far as we know, one or more of the following resolved the problem for others who have reported it:

1) Updating to v6.7a

2) Adding a Run Script (VBScript) step like this at the beginning of with this code:

Application.Options.RunProgramOutputWaitTimeout = 1000
Application.Options.RunProgramInputWaitTimeout = 1000

3) Removing the VBP DEP exclusions (Control Panel -> System -> Advanced -> Data Execution Prevention -> Turn on DEP for all programs and services except those I select, Remove Visual Build Professional and Visual Build Professional 6 Console App from the list, OK, and restart Windows) and then configuring Windows to 'Turn on DEP for essential Windows programs and services only' (in that same dialog) and restart again.

4) Adding a Wait step (5 seconds) at the end of a chained (child) build or before and/or after a step that hangs.

If none of those help, please provide the following information:

Are you building from a Scheduled Task, starting manually, or? Any ideas on anything that may have changed when the problem returned? Please ZIP and send:
1) The info from Help | About | Install Info (after updating to v6.7a)
2) A screen shot of System properties (Windows+Break)
3) A reproducible test case, including VBP project(s) that demonstrate the problem.

Thanks.

Thanks, i will try those steps. I am at 6.2a right now. I will upgrade. I tried the 7a before, with worse luck last time. But I'll start again. The 7a version i have is a different size then the one on the download site now. I'll let you know.

We've been experiencing something along these lines too. The exact behavior is best described at this site, which I found while Googling for a solution:

http://jira.public.thoughtworks.org/...s:all-tabpanel

Others in this thread had builds freezing on steps, whereas our builds complete, but the EXE never closes. This seems to have only become an issue in the last few weeks... Unfortunately I can't track down any specific changes in our build environment (Windows Updates could be the culprit).

Ok, I upgraded to v6.7a and it has hung twice in two runs. So know I will do the other steps. I got to step 2 which is adding the
Application.Options.RunProgramOutputWaitTimeout = 1000
Application.Options.RunProgramInputWaitTimeout = 1000

Is this setting how long to wait for a process to end? is it in minutes or seconds? Some of the processes take over an hour to run. Could that be it?

It does seem to always hang after a long running step.

thanks

It is the time, in milliseconds, to wait for output from a called process's standard output pipe. This wait occurs in a loop until the process completes (or the build is canceled). The setting just changes how long to wait within each loop iteration, but one user indicated that it may have made a difference for them.

Looking at the files you submitted in April, it appears the problem occurs when invoking devenv (VS2008) from a Run Program action. Some other things to try if the previous suggestions don't help:

1) Change the Run Program action command to:

%DOSCMD% original cmd here >%TEMP%\out.txt

and Read program output from 'A file' of %TEMP%\out.txt

2) Replace the Run Program action with a Make VS 2008 action (which calls MSBuild instead of devenv by default).

Any information on what might have changed from when it was working and then stopped working (you indicated in April that using the /mta switch w/ v6.7 resolved the problem) or details on how to reproduce the problem (we've run numerous tests with long-running Run Program steps on Windows 2003 SP2 virtual machine guests without any problems) could be helpful.

Also, yesterday we made one tweak to VBP v6.7a which could conceivably make a difference. If Help | About | Install Info does not show

VisBuildPro.exe version 6.7.1.1

try re-downloading and installing http://www.kinook.com/Download/VisBuildProEval.exe to get this update.

Also, back in April you indicated:

VisBuildPro.exe" /mta /s /b coleto.bld (no hang)
VisBuildPro.exe" /s /b coleto.bld (no hang)
VisBuildPro.exe" /mta coleto.bld (no hang)
VisBuildPro.exe" coleto.bld (hangs)

Is that still the case, or under what conditions does it now hang?

Thanks.

The step that consistantly fails is after all the devenv/msbuild lines are built. One thing we build is a database tool and we execute that which takes about 1.5 hours. The process seems to run to completion. I say this because built tool outputs "BuildPublishBOs completed" to the log and the process is no longer show using ps. But the next step in the .bld file is never run. I'm rerunning the build with the added

Application.Options.RunProgramOutputWaitTimeout = 1000
Application.Options.RunProgramInputWaitTimeout = 1000


lines, but after your explaination, i don't hold out much hope. I can upgrade to your latest tweek and run again. Turn around for me is about 4 hours to get to this point.

I'll let you know what happens.