Mystery Threads - How do you find out where they come from?
Mark Moeykens
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
Brian Cryer
news:7EDD6F77-A2D8-4CD3...@microsoft.com...
> 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.
I'm sure that the .NET framework uses threads (the garbage collector for
instance), plus I'd expect to see one thread for each active web-request and
I suppose another just listening for requests. So that's three without
thinking giving much thought.
However, I'd expect you to be able to see the same behaviour locally -
perhaps not as many threads because you might not have as many requests, but
I'd expect you to see some. On my development PC according to the Visual
Studio "Threads" windows I currently have 6 threads, two of which are my own
and the other 4 show no-name. The ones with no-name I can't switch to, so I
know I'm not generating them and I'm sure they are ones the framework has
generated for itself.
If your application is only supposed to log information about threads that
your application spawns then you probably need a different way of telling
apart your threads from those created by the framework. Whether the name is
empty seems like a reasonable way, but might not be reliable in future
because Microsoft might start to name the threads used by the framework. In
my application to assist with debugging I always name my threads so I can
tell at a glance what each thread is.
> 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.
No idea, sorry :(
--
Brian Cryer
http://www.cryer.co.uk/brian
Mark Moeykens
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.
"Brian Cryer" wrote:
> .
>
Mark Moeykens
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.
"Brian Cryer" wrote:
> .
>