Mystery Threads - How do you find out where they come from?

  • Thread starter Thread starter Mark Moeykens
  • Start date Start date
M

Mark Moeykens

In this web app I’m working on there is this place that logs some information
about Thread.CurrentThread. This logging is supposed to only happen on
threads that the application spawns. The application assigns
Thread.CurrentThread.Name a name and then later logs that name into a SQL
Server table.

But sometimes when we log the thread’s name it isn’t our assigned name.
Instead it is “Thread-1†all the way up to “Thread-26â€. By default
Thread.CurrentThread.Name is null so we can’t figure out where these other
threads are coming from. We can only reproduce this problem on a web server,
not locally.

Anyone know how we can find out more information on these mystery threads
and where they are coming from? I’ve explored the Thread object but can’t
seem to find any useful properties I can inspect for clues.

Thank you,
Mark Moeykens
 
Thanks for your reply, Brian. I had forgotten all about the “Threads†window
and we immediately put it to use to observe what was happening.

From what we can see we too have a handful of <No Name> threads that get
picked up at our break points. Then as our breakpoints are hit we see some of
these <No Name> threads getting renamed automatically to “Thread-##†(we
track the renaming by the thread's ID). Our processes (IIS I guess) are
picking up and using these renamed threads. Since the thread.Name property is
write-once we cannot rename it and there is the problem. We can no longer
track the thread with an unpredictable name.
 
Thanks for your reply, Brian. I had forgotten all about the “Threads†window
and we immediately put it to use to observe what was happening.

From what we can see we too have a handful of <No Name> threads that get
picked up at our break points. Then as our breakpoints are hit we see some of
these <No Name> threads getting renamed automatically to “Thread-##†(we
track the renaming by the thread's ID). Our processes (IIS I guess) are
picking up and using these renamed threads. Since the thread.Name property is
write-once we cannot rename it and there is the problem. We can no longer
track the thread with an unpredictable name.
 
Back
Top