I’ve inherited a project consisting of three levels of code. The lowest layer is native C++ that interacts with hardware. This is mature, stable and well-tested. The intermediate level code is C++/CLI, which interacts with top-level C# code that contains the UI elements and some additional functionality. This C# code is incomplete and was rushed in development: it crashes frequently and is not fit for purpose. My task is debug it and complete it.
I’m using VS 2008 to step through the multithreaded code to understand where to start with this project. Simple question: in the Threads window, I have two named threads: a Worker thread which communicates with some of the underlying hardware (i.e. the C++ code) and a User Interface thread.
Stepping through the code, however, there are quite a few Worker Threads that have no name and no call stack associated with them, which appear seemingly randomly. They don’t have an entry in the Debug Location toolbar, and they don’t appear to be visible in the code when ‘Show threads in source’ is selected.
What are they, and should I be concerned about them? They don’t appear to be from the native code (as it uses Boost for threading and this is clear from the call stack). Freezing them or changing their priority seems to have no effect.
I’ve not debugged multi-threaded code of this complexity before so any advice much appreciated!
In addition to the threads of your application there are a few others in a .NET application. The runtime uses a dedicated thread for running finalizers. As driis points out you may see thread pool threads as well. The debugger also starts a thread as well. If you’re using the vshost you’ll get quite a bit of overhead an additional threads.