Prev: change XML encoding
Next: ToUpper() vs UCase()
From: Dennis on 7 Nov 2009 18:52
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?

--

Dennis
From: Dennis on 7 Nov 2009 19:21
On Sat, 07 Nov 2009 18:52:13 -0500, Dennis <nobody(a)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.

--

Dennis
From: Dennis on 7 Nov 2009 19:42
On Sat, 07 Nov 2009 19:21:03 -0500, Dennis <nobody(a)nowhere.invalid>
wrote:

>On Sat, 07 Nov 2009 18:52:13 -0500, Dennis <nobody(a)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.

Now I have the 2nd of the dual cpu's pegged at close to 100% (and a TCP
connection stuck in CLOSE_WAIT). Here is the stack for the TCP
connection:

mswsock.dll+0x6a32
mswsock.dll+0x542d
WS2_32.dll!WSAConnect+0x5c
System.ni.dll+0x13f0ca
System.ni.dll+0x1408ad
mscorlib.ni.dll+0x1e842f
mscorlib.ni.dll+0x1e839b
mscorwks.dll+0x1b4c
mscorwks.dll!DllUnregisterServerInternal+0x619d
mscorwks.dll!DllUnregisterServerInternal+0x6803
mscorwks.dll!DllUnregisterServerInternal+0x6844

Any suggestions?

--

Dennis
 | 
Pages: 1
Prev: change XML encoding
Next: ToUpper() vs UCase()