A Windows Service runs a series of DTS packages programmatically. The
service was written in VB.NET.

Many series-of-packages can get queued up at a time. Only one series can
run at a given time due to the design of the DTS packages within each
series (they use common shared temp tables which get wiped and rebuilt).
Therefore one must complete before another can run. If one hangs in
execution, then the entire queue gets held up, and the focus of my
question. I can not tell the hang condition from a package that is just
taking a long time to do its work.

Part of my recommendation to my DTS developers is to "clean" their DTS
of all MSGBOX and INPUTBOX type calls in script. I've even provided a
tool to search for them. Of course, not everyone will do it (so the
blame comes back to me), and one of the dts developers has cast the
doubt that DTS runtimes can throw up a message box on some unusual error
conditions, which we can not squelch. Can this be confirmed?

To help avoid some hang condions I set each package to run in main
thread prior to running it.

The other day the running DTS setup a deadlock condition, which I was
thinking would eventually cause the conflicting SQL commands to fail.
Either this did not happen, or else, the failing call was made in a loop
without error detection. I don't have enough information about the
running DTS to understand how it was possible for the deadlock to exist,
but I know there was a SQL command running and a BULK INSERT running
that deadlocked with each other. I don't see how this can happen since I
set ExecuteInMainThread=True for all steps prior to executing a package.
This seems like the most prudent mode of execution to avoid deadlocks to
me. My understanding being that any two steps can not simultaneously
execute in this way.

Saftey timers on package execution don't seem to be viable due to the
extreme variations of execution times.

I am seeking approaches, methodologies, tricks, or tips to detect the
following from the VB.NET application which loads and runs the dts
packages programmatically:

1) Detect a msgbox or inputbox call by a script within the dts.

2) Detect a msgbox caused by dts runtimes perhaps due to some unusual
runtime condition or error.

3) Detect that the running dts has caused a deadlock condition

If I could detect all three of these reliably, and then abort, and mark
the series as failed, then I could go on and execute the next series of
dts packages in the queue.

Are there conditions OTHER than the three I can think of?

Any wisdom that can be offered would be EXTREMELY appreciated.

Best regards - Lee Gillie - Spokane, WA