ToolHelp thread count doesn't match debugger
Scott Gifford
I'm trying to track down a possible thread leak in my code. It takes
various actions on a 30-second timer, and several of them involve
creating new threads, sometimes by other outside of my direct control
(like creating a System.Threading.Timer for timeouts).
After a few days the number of threads has often grown to 10-15 and
stays there, which probably means some threads are getting stuck. I'm
trying to figure out if this is actually what's happening, and if so
which threads are stuck and why.
First, I'm counting threads with the OpenNetCF.ToolHelp.ThreadEntry
method. My call looks like this:
OpenNETCF.ToolHelp.ThreadEntry.GetThreads((uint)System.Diagnostics.Process.GetCurrentProcess().Id).Length;
I'm currently running the code in the debugger, and that returns 10
threads. But when I actually look at the "Threads" pane in the
debugger, it only shows 3 threads. Am I doing something wrong?
Second, I don't see a way to get any other information about the
thread from its ID. In particular, getting the Thread.Name might be
useful, or some other piece of identifying information.
What I'd really like to do is attach with the debugger to see what
threads are running after a while, but that's not working for me.
I'll post about that in a second...
Thanks for any ideas!
----Scott.
Chris Tacke, eMVP
managed process (to be honest I never use it). I know that the ToolHelp
APIs do return the same number of threads that the remove process viewer
tool returns, as I used that for verifying the API when I wrote it.
As for thread identification, I typically use thread priority, since there
is no facility for naming threads. If each has a unique priority, that can
be useful. Anotehr option is that whenever you create a thread, you debug
spit the thread handle/ID as some meaningful name. That way when you look
at the handle list via toolhelp, you have an idea what each is doing.
For your scenario I'd probably hook up kernel tracker as well to see if
those threads are getting schedules at all or if they're all just blocking
in some system call and have gone zombie on you.
--
Chris Tacke, Embedded MVP
OpenNETCF Consulting
Giving back to the embedded community
http://community.OpenNETCF.com
"Scott Gifford" <sgif...@suspectclass.com> wrote in message
news:lymyhl4...@gfn.org...
Scott Gifford
> I'm not certain the threads window in Studio shows all running hteads in a
> managed process (to be honest I never use it). I know that the ToolHelp
> APIs do return the same number of threads that the remove process viewer
> tool returns, as I used that for verifying the API when I wrote it.
OK, yeah, it seems that's the case. I looked with Remote Process
Viewer and it agreed with ToolHelp, not with the debugger. Maybe the
debugger is only showing managed threads.
> As for thread identification, I typically use thread priority, since there
> is no facility for naming threads. If each has a unique priority, that can
> be useful. Anotehr option is that whenever you create a thread, you debug
> spit the thread handle/ID as some meaningful name. That way when you look
> at the handle list via toolhelp, you have an idea what each is doing.
I was hoping to access the "Thread.Name" property, but instead I wrote
a small class to keep a Dictionary<int, string> with thread names in
it, then went through and named all of my threads. That seems to do
about what I want.
What's odd is that when I start my app, at the first line in main,
there are 6 threads running; once it gets up and running there are
9-10. When I ran it a few days ago, while it was running there were
2-3 (I didn't check threads when the program started). I have no idea
what could cause that.
> For your scenario I'd probably hook up kernel tracker as well to see if
> those threads are getting schedules at all or if they're all just blocking
> in some system call and have gone zombie on you.
I haven't used Kernel Tracker before, looks like it's part of Platform
Builder. I'm working on a consumer SmartPhone device, is it still
possible to use it?
Thanks as always!
----Scott.
Chris Tacke, eMVP
> Viewer and it agreed with ToolHelp, not with the debugger. Maybe the
> debugger is only showing managed threads.
That's my assumption, which IMO, makes it pretty worthless.
> What's odd is that when I start my app, at the first line in main,
> there are 6 threads running; once it gets up and running there are
> 9-10. When I ran it a few days ago, while it was running there were
> 2-3 (I didn't check threads when the program started). I have no idea
> what could cause that.
Not odd at all. The CLR runs threads to do things, plus many managed
objects spin up worker threads to do work without you explicitly asking for
a thread. 9-10 doesn't seem crazy to me for a large app, especially if it's
doing any async monitoring.
> I haven't used Kernel Tracker before, looks like it's part of Platform
> Builder. I'm working on a consumer SmartPhone device, is it still
> possible to use it?
It's also part of eVC, which is a much smaller download and footprint.
Should work fine with your device, though you'll have to use platman, not
corecon, for connectivity.
Scott Gifford
>> OK, yeah, it seems that's the case. I looked with Remote Process
>> Viewer and it agreed with ToolHelp, not with the debugger. Maybe the
>> debugger is only showing managed threads.
>
> That's my assumption, which IMO, makes it pretty worthless.
>
>> What's odd is that when I start my app, at the first line in main,
>> there are 6 threads running; once it gets up and running there are
>> 9-10. When I ran it a few days ago, while it was running there were
>> 2-3 (I didn't check threads when the program started). I have no idea
>> what could cause that.
>
> Not odd at all. The CLR runs threads to do things, plus many managed
> objects spin up worker threads to do work without you explicitly asking for
> a thread. 9-10 doesn't seem crazy to me for a large app, especially if it's
> doing any async monitoring.
What I thought was odd was the first time I ran it, it had 2-3
threads, but the next time it had 9-10. Today, I suddenly realized
what I suspect is the difference: between the two runs, I had set the
registry key which makes .NET applications run in "debug mode" so I
can attach the Visual Studio debugger once it is running (that didn't
work, but that's another story).
Now what's interesting is that since I have set that flag, my app has
been more stable than it's ever been. Before setting the flag, after
a few days of running, the network on the device will often cease to
function properly with no explanation; just DNS won't work anymore
until I reset the device, or at least disable/enable the interface.
Since I set that flag that hasn't happened. Very odd. If anybody has
suggestions of what that could mean, I'd appreciate it.
>> I haven't used Kernel Tracker before, looks like it's part of Platform
>> Builder. I'm working on a consumer SmartPhone device, is it still
>> possible to use it?
>
> It's also part of eVC, which is a much smaller download and footprint.
> Should work fine with your device, though you'll have to use platman, not
> corecon, for connectivity.
Thanks, I haven't looked at this yet, but I will next time I dig into
this problem.
----Scott.
Scott Gifford
>> OK, yeah, it seems that's the case. I looked with Remote Process
>> Viewer and it agreed with ToolHelp, not with the debugger. Maybe the
>> debugger is only showing managed threads.
>
> That's my assumption, which IMO, makes it pretty worthless.
>
>> What's odd is that when I start my app, at the first line in main,
>> there are 6 threads running; once it gets up and running there are
>> 9-10. When I ran it a few days ago, while it was running there were
>> 2-3 (I didn't check threads when the program started). I have no idea
>> what could cause that.
>
> Not odd at all. The CLR runs threads to do things, plus many managed
> objects spin up worker threads to do work without you explicitly asking for
> a thread. 9-10 doesn't seem crazy to me for a large app, especially if it's
> doing any async monitoring.
What I thought was odd was the first time I ran it, it had 2-3
threads, but the next time it had 9-10. Today, I suddenly realized
what I suspect is the difference: between the two runs, I had set the
registry key which makes .NET applications run in "debug mode" so I
can attach the Visual Studio debugger once it is running (that didn't
work, but that's another story).
Now what's interesting is that since I have set that flag, my app has
been more stable than it's ever been. Before setting the flag, after
a few days of running, the network on the device will often cease to
function properly with no explanation; just DNS won't work anymore
until I reset the device, or at least disable/enable the interface.
Since I set that flag that hasn't happened. Very odd. If anybody has
suggestions of what that could mean, I'd appreciate it.
>> I haven't used Kernel Tracker before, looks like it's part of Platform
>> Builder. I'm working on a consumer SmartPhone device, is it still
>> possible to use it?
>
> It's also part of eVC, which is a much smaller download and footprint.
> Should work fine with your device, though you'll have to use platman, not
> corecon, for connectivity.
Thanks, I haven't looked at this yet, but I will next time I dig into
this problem.
----Scott.
Scott Gifford
[...]
>> What's odd is that when I start my app, at the first line in main,
>> there are 6 threads running; once it gets up and running there are
>> 9-10. When I ran it a few days ago, while it was running there were
>> 2-3 (I didn't check threads when the program started). I have no idea
>> what could cause that.
>
> Not odd at all. The CLR runs threads to do things, plus many managed
> objects spin up worker threads to do work without you explicitly asking for
> a thread. 9-10 doesn't seem crazy to me for a large app, especially if it's
> doing any async monitoring.
What I thought was odd was the first time I ran it, it had 2-3
threads, but the next time it had 9-10. Today, I suddenly realized
what I suspect is the difference: between the two runs, I had set the
registry key which makes .NET applications run in "debug mode" so I
can attach the Visual Studio debugger once it is running (that didn't
work, but that's another story).
Now what's interesting is that since I have set that flag, my app has
been more stable than it's ever been. Before setting the flag, after
a few days of running, the network on the device will often cease to
function properly with no explanation; just DNS won't work anymore
until I reset the device, or at least disable/enable the interface.
Since I set that flag that hasn't happened. Very odd. If anybody has
suggestions of what that could mean, I'd appreciate it.
----Scott.
Scott Gifford
[...]
>> What's odd is that when I start my app, at the first line in main,
>> there are 6 threads running; once it gets up and running there are
>> 9-10. When I ran it a few days ago, while it was running there
>> were 2-3 (I didn't check threads when the program started). I have
>> no idea what could cause that.
>
> Not odd at all. The CLR runs threads to do things, plus many
> managed objects spin up worker threads to do work without you
> explicitly asking for a thread. 9-10 doesn't seem crazy to me for a
> large app, especially if it's doing any async monitoring.
What I thought was odd was the first time I ran it, it had 2-3
Scott Gifford
[...]
>> What's odd is that when I start my app, at the first line in main,
>> there are 6 threads running; once it gets up and running there are
>> 9-10. When I ran it a few days ago, while it was running there were
>> 2-3 (I didn't check threads when the program started). I have no idea
>> what could cause that.
>
> Not odd at all. The CLR runs threads to do things, plus many managed
> objects spin up worker threads to do work without you explicitly asking for
> a thread. 9-10 doesn't seem crazy to me for a large app, especially if it's
> doing any async monitoring.
What I thought was odd was the first time I ran it, it had 2-3
Scott Gifford
[...]
> What I thought was odd was the first time I ran it
[...]
Oops, sorry about all the reposts, my newsreader was telling me the
articles were rejected, but apparently they were posted anyways. :-(
----Scott.