How to debug:looks like infinite loop somewhere in the guts of .Ne

  • Thread starter Thread starter Alex O
  • Start date Start date
A

Alex O

I have a .Net app running on one of my servers. Last night it went in a state
where it was no longer doing anything useful. Some debugging indicated that
one of the threads is spinning somewhere in the .Net framework code. I do not
have private symbols for the framework so I can't tell what it is doing
excactly. But I can see that it is not blocked or waiting for anything. And
!runaway shows that this thread has eaten 12hours of CPU time in last 13
hours of wall time.

Here is a top porition of my App's stack but I do not think it is relevant
to the problem.

0497f318 7936edbc
System.Collections.ArrayList+ArrayListEnumeratorSimple.MoveNext()
0497f324 7a5b0a99
System.Net.ConnectionGroup.FindConnection(System.Net.HttpWebRequest,
System.String)
0497f368 7a58b191
System.Net.ServicePoint.SubmitRequest(System.Net.HttpWebRequest,
System.String)
0497f3a0 7a57ef21
System.Net.HttpWebRequest.SubmitRequest(System.Net.ServicePoint)
0497f3d0 7a57c539
System.Net.HttpWebRequest.BeginGetResponse(System.AsyncCallback,
System.Object)

If I dump native call stack of the thread all I get is System_ni+huge offset.
Does anybody have any idea how to debug this issue any further? Or perhaps
somebody have encountered similar situation. In this case do you recall what
the culprit was?

Thanks
-Alex
 
You should see if you can reproduce the issue running under the debugger. If
you can, you can simply break into the debugger when the problem occurs. By
the way, the framework code is now available so you can actually step into
it however it is the same option basically as option 1.

I've seen those problems lots of times and I typically start with a code
review and some trace statements to get an idea of where the issue is.

--

Regards,
Alvin Bruney [MVP ASP.NET]

[Shameless Author plug]
The O.W.C. Black Book, 2nd Edition
Exclusively on www.lulu.com/owc $19.99
 
There are two solutions..
If you have the source code and the Visual studio IDE on the machine
where the problem has occured, you could attach the process to the
source code and then break the debuggin.g Looking the Thread watch
will proivde where the errant thread is ..

Alterantively you could take a process dump of the process using
windebug, and then drill down the thread's execution context.
 
Back
Top