/clr option creates multiple Win32 threads

[Guest]

Hi,

While debugging my application I have noticed that occasionally a message
saying "Win32 Thread xxxx exited with code 0 (0x0)" appearing in the debug
window. I investigated this some more and found that, according to the
threads window, there were four Win32 threads in my program! I had no idea
where these had come from, and was rather worried about what they were doing.

I found that the threads were only there in programs that used a certain
unmanaged DLL that we use for communications. To get the unmanaged DLL to be
linked correctly into our project we have to use the /clr compiler option, as
opposed to the /clrure option. After a bit more investigation I have found
that it was setting this option to /clr which seemed to create these extra
Win32 threads.

I've googled a lot about this, as well as searching these newsgroups, and
haven't found anything about this at all. Does anyone know why these threads
are created, what they do, and whether I can have (or need to have) any
control over them?

Cheers,

Robin

 

[SvenC]

Hi,

While debugging my application I have noticed that occasionally a
message saying "Win32 Thread xxxx exited with code 0 (0x0)" appearing
in the debug window. I investigated this some more and found that,
according to the threads window, there were four Win32 threads in my
program! I had no idea where these had come from, and was rather
worried about what they were doing.

I found that the threads were only there in programs that used a
certain unmanaged DLL that we use for communications. To get the
unmanaged DLL to be linked correctly into our project we have to use
the /clr compiler option, as opposed to the /clrure option. After a
bit more investigation I have found that it was setting this option
to /clr which seemed to create these extra Win32 threads.

I've googled a lot about this, as well as searching these newsgroups,
and haven't found anything about this at all. Does anyone know why
these threads are created, what they do, and whether I can have (or
need to have) any control over them?

There might be several runtime threads needed by the framework. An obvious
one would be the garbage collector.

Why do you worry? If you'd use COM you would see extra threads for DCOM and
cross apartment calls for objects not able to live in the apartment you
created them in. The OS (or some parts of the OS) has several situations
where additional threads are created.

 

[Guest]

Ok - I just wondered if I needed to worry about them.

I'll just assume they were all created by the CLR or the OS and not worry
about them then!

Thanks,

Robin

 

[Bruno van Dooren]

Ok - I just wondered if I needed to worry about them.

I'll just assume they were all created by the CLR or the OS and not worry
about them then!

The debugger also has 1 or more threads running when your application is
launched.
Threadpools also start and stop their own threads, so even if your app does
not start extra threads, it is very normal that multiple threads might be
running.