Infrequent program termination

[Jim McGrail]

Background:

I am investigating a problem involving a windows .NET application that is
being developed in C# with Visual Studio 2003.

It is a multi-threaded application that uses MSMQ to communicate between the
threads.

The problem is that the program infrequently terminates with no indication
of why it terminated.

There are no exceptions thrown and it happens very infrequently (1 in 300
executions).

The termination appears to be caused by an interaction of events and cannot
be recreated (doing the same actions will not cause the termination).

Questions:

Can a program terminate with no indication of what caused the termination
(no exception thrown)?

Could this be caused by thread blocking / waiting? (This doesn't seem
likely)

Could this be caused by thread deadlock? (This doesn't seem likely either)

Does anyone have any experiences similar to this one?

[Joe Mayo]

"Jim McGrail" <ji****@attbi.c om> wrote in message
news:iq******** ************@rw crnsc51.ops.asp .att.net...

Background:

I am investigating a problem involving a windows .NET application that is
being developed in C# with Visual Studio 2003.

It is a multi-threaded application that uses MSMQ to communicate between the threads.

The problem is that the program infrequently terminates with no indication
of why it terminated.

There are no exceptions thrown and it happens very infrequently (1 in 300
executions).

The termination appears to be caused by an interaction of events and cannot be recreated (doing the same actions will not cause the termination).

Questions:

Can a program terminate with no indication of what caused the termination
(no exception thrown)?

Could this be caused by thread blocking / waiting? (This doesn't seem
likely)

Could this be caused by thread deadlock? (This doesn't seem likely either)

Does anyone have any experiences similar to this one?

Hi Jim,

Multi-threaded apps are a bear (er...I mean fun) to debug aren't they. :)

The best way I've found for tracking down multi-threaded problems is to use
Tracing, writing the output to a log file and then examining where each
thread is at specified points in time and other information pertinent to the
problem. Relevant information for each Trace write includes the Thread
name, Type/Method, and DateTime along with other specific information.

Although the DateTimes may not be perfectly accurate, they are approximate
and can help you see what is happening on each thread. Here's the docs on
TextWriterTrace Listener for an example of how to get this started:

http://msdn.microsoft.com/library/de...classtopic.asp

Joe
--
http://www.csharp-station.com

[John Saunders]

"Jim McGrail" <ji****@attbi.c om> wrote in message
news:iq******** ************@rw crnsc51.ops.asp .att.net...

Background:

I am investigating a problem involving a windows .NET application that is
being developed in C# with Visual Studio 2003.

It is a multi-threaded application that uses MSMQ to communicate between the threads.

The problem is that the program infrequently terminates with no indication
of why it terminated.

There are no exceptions thrown and it happens very infrequently (1 in 300
executions).

If I were you, I'd make completely sure that there are no exceptions thrown.
Make sure you have a try block around the code of _every_ thread and also
around the code of any thread pool work items.
--
John Saunders
Internet Engineer
jo***********@s urfcontrol.com