How to know who kills my threads

Question

I got a thread that is just banishing.. i\'d like to know who is killing my thread and why.

It occurs to me my thread is being killed by the OS, but i\'d like to

Answer 1

The process might be terminating. That would be what worker.IsBackground = true; is designed to do, kill your thread when the main thread exits.

Answer 2

Try use app domain UnhandledException event: http://msdn.microsoft.com/en-us/library/system.appdomain.unhandledexception.aspx

it may give you some information if you miss some exceptions

Answer 3

A potential way to get more information: attach a debugger and break on thread termination. Depending on how your thread is being terminated, this might not work.

1. Download Debugging Tools for Windows if you don't already have it
2. Run windbg.exe, attach to your process
3. Break into windbg, type sxe et to enable breaking on thread exit
4. When the debugger breaks, inspect the state of the system, other threads, etc.
5. To get the managed stack, load sos.dll (.loadby sos mscorsvr, .loadby sos mscorwks, or .loadby sos clr should work), then run !clrstack (see !help for other sos commands)

If you get a lot of noise from other threads exiting, script windbg to continue after breaking if it's not the thread ID you care about.

Edit: If you think the thread is being terminated from within your process, you can also set a breakpoint on TerminateThread (bp kernel32!TerminateThread) and ExitThread (bp kernel32!ExitThread) to catch the stack of the killer.

Answer 4

Your edit reveals the answer:

It's the butler web server.

How exactly do you host these threads? A webserver environment isn't exactly designed to host long living processes. In fact, it is probably configured to halt runaway sites, every 40 minutes maybe?

Edit:
For a quick fix, your best chance is to set worker.IsBackground = false; because your current setting of true allows the system to kill the parent-thread w/o waiting for your bgw.

On another note, there is little point in using a BackgroundWorker in an ASP.NET application, it is intended for WinForms and WPF. It would be better to create a separate thread for this, since you are changing some of the Threads properties. That is not advised for a ThreadPool (Bgw) thread.

Answer 5

If checking for an exception doesn't show anything useful, get your thread code to write to a log file at key points. You'll then be able to see exactly when it stops working and hopefully why.

Answer 6

A background thread will only run as long there are foreground threads runnnig.

As soon that all foreground threads end, any background thread still running will aborted.