The method StartWatch uses to monitor an application should not affect the monitored application at all. StartWatch uses the standard method of sending the application a do-nothing message, a technique which has been in Windows for ages, and is even used by Windows. If this was the case, it would be a very sloppy flaw on the part of the monitored application. I don't think that's what's happening though. I think the more likely explanation is that VWS is routinely entering unresponsive states that StartWatch is interpreting as it being hung, so it is trying to close and restart it.
There are two ways for one program to close another. The polite way is to send the program's main window a "Close" message. Unfortunately, windows provides no mechanism for finding out what the main window of a program is. The programming tool that was used to create VWS uses an uncommon windowing strategy. It creates a score of windows, most of them not visible. Programs can make invisible windows by setting their "hidden" flag, or by leaving them visible but making their position way off the visible screen, or making their size 1 pixel by 1 pixel. Since StartWatch has to be able to deal with any program, it has a rather involved algorithm for sorting through all the windows that belong to a program to try and identify the "Main Window", i.e. the one you send the close message. Because VWS is a little odd, I even have some code in there specifically for handling it. Sending the message to the wrong window can put the program into an open but not functioning "zombie" state.
The result is that it's not always possible to locate the right window to talk to, and even if you do, the program may simply ignore the message. That is where the second method comes in. That is killing or terminating the program. This is not polite, but much more effective. But even that doesn't always work. Because of an unfortunate design decision by Microsoft (since fixed in Vista) if a program hangs while waiting on certain calls into drivers (such as communication), then the program can become unkillable by any method.
StartWatch uses the first method, but only uses the second method if given the permission in the configuration where you set the monitor options for a particular program in StartWatch.
If StartWatch is detecting VWS as hung when it really isn't, you can use the slider control in the configuration to make it less sensitive in this respect. In other words a program would have to be unresponsive for a longer period of time before it's considered "hung". Ideally, if a program is written using best practices, it shouldn't ever become unresponsive for more than a couple seconds. But in reality, many (most?) programs don't go to the extra trouble to meet that standard. That said, a program that's unresponsive for a long period of time (more than 20 or 30 seconds) is doing their users no favors just to save a little programming effort.
Enabling the option that lets StartWatch kill a program that can't be closed should reduce the situation of a zombie program (half stopped) which it sounds like you were experiencing.
As a test, I would be interested in finding out what happens if you go back to having StartWatch monitoring VWS, but uncheck the hang detection for VWS. If this doesn't cause VWS to get in the hung state you originally described, then you could try enabling hang detection but use the slider to decrease the sensitivity, and also enable the option to kill the program if it can't be closed.
Steve
SoftWx
