#1
|
|||
|
|||
VBP process delays terminating
I have a somewhat strange problem with VBP 6.1 that only reproduces itself on our Build machine. When VBP finishes and exits the build, its process still hangs around in memory for about 10 seconds.
Here's how I reproduced the problem: ...* Start the VBP GUI ...* Open up Windows Task Manager and navigate to the VBP process in the “Processes” tab ...* Close the VBP GUI ...* VBP process will stay in-memory for another 10 seconds, even though it drops off the “Applications” tab immediately. Again, this only happens on one machine (unfortunately our build machine), which is a Windows 2003 R2 SP1 box. Another Windows 2003 R2 SP1 box we have, however, works just fine. Why is this important? We have a .NET web service that launches the VBP command-line process, monitors status, and waits for the task to signal completion. There is even a part of the service that runs a quick VBP build script that normally should take about 2 seconds, but because of this delay, it takes 12 seconds on the build machine. This is making our Web build far more painful than it should be. Is there some setting that is causing this? Any ideas? Any possible workarounds? All other processes on the system seem to be behaving "normally". Last edited by Dave_Novak; 08-21-2006 at 06:50 PM. |
#2
|
|||
|
|||
It may not be relevant, but I've noticed that if I am saving a VBP script across our network that it takes of the order of 10 seconds. A local save happens in "no time".
We are using a Mac server with Samba - which also may, or may not, be relevant. |
#3
|
|||
|
|||
To be clear, our Web Service simply executes VBP scripts but does not save them. The most telling demonstration, however, is the one I listed previously, which simply starts and exits the VBP GUI with no build whatsoever.
|
#4
|
|||
|
|||
It does sound like some sort of network access that is slow or timing out, or perhaps some monitoring process (anti-virus, etc.) that is interfering with VBP. The only file access that would normally occur on exit (and typically only if some data or setting was modified during the session) are:
* Write user options and GUI layout info (local registry/file system) * Write modified application data files [1] Some suggestions: * Use FileMon [2] filtered on VisBuildPro to see if there are any network reads/writes on exit. * Try using the console app [3] rather than the GUI app to see if it makes a difference. * Check the Windows Event Viewer to see if VBP reported any errors at the time of exit. [1] http://www.visualbuild.com/Manual/co...ationfiles.htm [2] http://www.sysinternals.com/Utilities/Filemon.html [3] http://www.visualbuild.com/Manual/consoleapp.htm |
#5
|
|||
|
|||
Problem Resolved
It definitely has nothing to do with network access as no network access is performed in the VBP script. Also, you don't even have to run the script to see the problem. I have the exact same result in the command-line version. Also, nothing obvious showing up in Windows Event log. We've even disabled virus protection and set up exclusions -- all to no avail.
Yet it works great on our other machine (which is pretty much identical). The ONLY difference between the two machines is our Build machine has McAfee installed on it (with certain features disabled and various directories programs excluded). But as a test, I decided to uninstall it to see if anything would change. And wouldn't you know it -- IT WORKS FINE WITHOUT MCAFEE!!! Thanks for making me re-think my assumptions. |
|
|