I am trying to debug a service that I wrote that uses a
System.Threading.Timer to periodically fire off a handler that opens a
socket to a pop3 server and retrieves emails.

It works OK most of the time, but every so often I notice that one of
the dual cpu's pegs at 100% usage.

I used Process Explorer to look at the service and I am seeing that one
of the TCP/IP connections is stuck in CLOSE_WAIT. I don't know if this
is what is causing the cpu to peg, because Process Explorer eventually
shows that the CLOSE_WAIT connection disappears ... but the cpu stays
pegged at 100% until I stop the service.

I have attached the debugger and no exceptions appear to be thrown.

The CLOSE_WAIT business doesn't bother me so much. It is the cpu usage
that I am concerned about.

The cpu is pegged at 100% as I type. Any suggestions as to what I can
look at to track this behavior down?

On Sat, 07 Nov 2009 18:52:13 -0500, Dennis <nobody at (no spam) nowhere.invalid
wrote:

I am trying to debug a service that I wrote that uses a
System.Threading.Timer to periodically fire off a handler that opens a
socket to a pop3 server and retrieves emails.

It works OK most of the time, but every so often I notice that one of
the dual cpu's pegs at 100% usage.

I used Process Explorer to look at the service and I am seeing that one
of the TCP/IP connections is stuck in CLOSE_WAIT. I don't know if this
is what is causing the cpu to peg, because Process Explorer eventually
shows that the CLOSE_WAIT connection disappears ... but the cpu stays
pegged at 100% until I stop the service.

I have attached the debugger and no exceptions appear to be thrown.

The CLOSE_WAIT business doesn't bother me so much. It is the cpu usage
that I am concerned about.

The cpu is pegged at 100% as I type. Any suggestions as to what I can
look at to track this behavior down?

More info...

Process Explorer shows that a thread for
mscorwks.dll!CorExitProcess+0x21ef9 is the culprit. Here is the stack:

ntkrnlpa.exe!NtBuildNumber+0x93
ntkrnlpa.exe!MmIsDriverVerifying+0xbb8
hal.dll!HalClearSoftwareInterrupt+0x342
mscorwks.dll!CoUninitializeEE+0x5708
mscorwks.dll!CorExitProcess+0x3364e
mscorlib.ni.dll+0x20ebcd
mscorlib.ni.dll+0x229d83
mscorlib.ni.dll+0x229797
mscorlib.ni.dll+0x1e842f
mscorlib.ni.dll+0x1e839b
mscorwks.dll+0x1b4c
mscorwks.dll!DllUnregisterServerInternal+0x619d
mscorwks.dll!DllUnregisterServerInternal+0x6803
mscorwks.dll!DllUnregisterServerInternal+0x6844
mscorwks.dll!DllUnregisterServerInternal+0x68b5
mscorwks.dll!CreateAssemblyNameObject+0x240ea
mscorwks.dll!CoUninitializeEE+0x4e0b
mscorwks.dll!CoUninitializeEE+0x4da7
mscorwks.dll!CoUninitializeEE+0x4ccd
mscorwks.dll!CoUninitializeEE+0x4e59
mscorwks.dll!CreateAssemblyNameObject+0x23a79
mscorwks.dll!CreateAssemblyNameObject+0x2406a
mscorwks.dll!CreateAssemblyNameObject+0x24099
mscorwks.dll!CreateAssemblyNameObject+0x2413f
mscorwks.dll!CreateAssemblyNameObject+0x23e01
mscorwks.dll!CreateAssemblyNameObject+0x23713
mscorwks.dll!CorExitProcess+0x21f3f
KERNEL32.dll!GetModuleFileNameA+0x1ba

It appears that I have two identical threads for
mscorwks.dll!CorExitProcess+0x21ef9, but only one of them is sucking up
the cpu cycles.