Windows Service grinding to a hault

[JJ]

I have written a multi-threaded Windows service. I developed it in such a way that the core logic is a separate class library from the actual service project, so I could test the .DLL in a console. In the console test app, the app will run for days on end without a problem. All necessary calls are thread safe (lock). However, when plugged into the Windows service, the darn thing simply grinds to a halt i a matter of minutes. No exceptions, no logging, nothing.

A processing thread is manually spawned that polls a DB every so often. the information obtained from the db is then queued up in another thread that is spawned manually. I manually create the threads since these processes can run for several minutes each. I internally manage the number of threads created and limit it to a set amount. If max number of thread are running, it waits until a thread dies, then launches itself. I was using the ThreadPool, but thought that I maybe having conflicts and ldead-locking since I do my I/O asynchronously delegate calls - that being why I create the threads manually (I read in an article by John Skeet that the ThreadPool should only be used for short lived processes, and that it is used by async delegate calls). If anybody can point me in the right direction on getting this thing to run, it would be greatly appreciated.

[John Wood]

There's a free utility called cslint that I've come across for detecting
deadlocks in C# apps.
You can get it at:
http://www.garret.ru/~knizhnik/lang.html
(scroll down for cslint)

There's some other utilities there of interest too.

Hope that helps. Deadlocks are evil.

"JJ" <JJ@discussions .microsoft.com> wrote in message
news:D1******** *************** ***********@mic rosoft.com...

I have written a multi-threaded Windows service. I developed it in such a way that the core logic is a separate class library from the actual service
project, so I could test the .DLL in a console. In the console test app,
the app will run for days on end without a problem. All necessary calls are
thread safe (lock). However, when plugged into the Windows service, the
darn thing simply grinds to a halt i a matter of minutes. No exceptions, no
logging, nothing.
A processing thread is manually spawned that polls a DB every so often.

the information obtained from the db is then queued up in another thread
that is spawned manually. I manually create the threads since these
processes can run for several minutes each. I internally manage the number
of threads created and limit it to a set amount. If max number of thread
are running, it waits until a thread dies, then launches itself. I was
using the ThreadPool, but thought that I maybe having conflicts and
ldead-locking since I do my I/O asynchronously delegate calls - that being
why I create the threads manually (I read in an article by John Skeet that
the ThreadPool should only be used for short lived processes, and that it is
used by async delegate calls). If anybody can point me in the right
direction on getting this thing to run, it would be greatly appreciated.

[Jon Skeet [C# MVP]]

JJ <JJ@discussions .microsoft.com> wrote:

I have written a multi-threaded Windows service. I developed it in
such a way that the core logic is a separate class library from the
actual service project, so I could test the .DLL in a console. In the
console test app, the app will run for days on end without a problem.
All necessary calls are thread safe (lock). However, when plugged
into the Windows service, the darn thing simply grinds to a halt i a
matter of minutes. No exceptions, no logging, nothing.
Can you run as a Windows service under the debugger, and see where it's
locking up? Alternatively, can you add *loads* of logging to get at the
problem that way?
A processing thread is manually spawned that polls a DB every so
often. the information obtained from the db is then queued up in
another thread that is spawned manually. I manually create the
threads since these processes can run for several minutes each. I
internally manage the number of threads created and limit it to a set
amount. If max number of thread are running, it waits until a thread
dies, then launches itself. I was using the ThreadPool, but thought
that I maybe having conflicts and ldead-locking since I do my I/O
asynchronously delegate calls - that being why I create the threads
manually (I read in an article by John Skeet that the ThreadPool should
only be used for short lived processes, and that it is used by async
delegate calls). If anybody can point me in the right direction on
getting this thing to run, it would be greatly appreciated.

Apart from the above, I'd suggest copying the whole solution and then
removing bits left, right and centre until you've got a small program
which still displays the symptoms. The problem will either be obvious,
or you'll have it in a form which is suitable for posting by that
stage.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too