Socket stuck in CLOSE_WAIT

  • Thread starter Thread starter Dennis
  • Start date Start date
D

Dennis

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?
 
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.
 
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?
 
Back
Top